Category: Usability

{syntax type="tiki" editor="plain"}
When creating a tracker (see the attached MS Word document "Tracker - Attachment Field Type Bug.doc"), choosing the "attachment" field type results in the form displaying the directions/description for the "text area" field type. This mismatch occurs upon first creating the "attachment" field. Once this field is saved, the user can re-open it for editing, and then the correct description (describes parameters, etc.) for the "attachment" field type is finally displayed.

chosen lib prevents changing the sorted order display of fields from an items-list tracker field with the translation smarty system

Workaround: disable chosen lib temporarily, make your changes to the selection of fields to be displayed, and/or the sort order, save (and reindex if necessary), and you can enable chosen lib again later on.
At least this worked for me so far.

Yet, the regular mode works fine on my Android phone.

See show instance and screenshot

{syntax type="tiki" editor="plain"}
The symptoms are:
- backlinks work sometimes only
- when deleting a page it does not always become a wanted page
- others ???

The result is:
- unpredictable behavior
- negative impact on the user acceptance

The problem is, that the syntax of the links change:
Example:
1) Type "Page 1" in the WYSIWYG mode and save
-> "Page 1"
2) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1" title="Page 1">Page 1</a>~/np~
3) save again in WIKI mode
-> ~np~[tiki-index.php?page=Page+1|Page 1]~/np~
4) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1">Page 1</a>~/np~

This makes 3 1/2 different representations of a link to 'Page 1'

{syntax type="tiki" editor="plain"}
Since Tiki29 we have 4 switches on the cookies consent dialog:
* essential
* analytics
* marketing
* functional

If the usage for the "essential" cookies is clear and leave no choice, the other switches usages, except for their name, are very unclear to me. The tooltip doesn't add any useful information to help to understand more than the name of the switch. If this switches exist and are displayed, the admin should be able to find in the control panels what allow or enable them to be displayed.

Also, it seems they are displayed by default, no matter what has set the admin in his Tiki site.
In my use case I didn't set anything brand new Tiki. No analytics or marketing and the cookies consent for this Tiki shouldn't display anything about analytics and marketing. Not only it is not necessary but it can harm the image of a website where this tools are excluded.

Nothing also in the doc: https://doc.tiki.org/Tiki29

---

Additionally, the reliability of Analytics and Marketing seems to be = 0
I have Matomo tracking code in my Look&Feel -> Customization fields and they work even if the cookie Analytic switch is kept OFF.

Labels for forum administration options to link a Forum and mailing list are very obtuse. Suggested cleanup as made in the documentation would help users.

Trying to download an uploaded file through the diff view in a comment produces garbled data instead of downloading the file. The file can still be downloaded through a right-click and open in a new tab. But if clicking directly on the link, rather than downloading, it's opening the data of the file within the comment.

See following GIF that shows the downloading failing at first, with garbled data, and then the possible download through right-click:

https://cl.ly/e51ea86f0b21

I'm not familiar enough yet with the code to be able to narrow the issue. I dug until the `{trackeroutput}` custom smarty function and the `field_render_value` but I'm not sure where the issue is. For both cases where the link to download a file works and for when it doesn't work, the url (and whole html tag attributes) is the same, so I suspect it's javascript that is doing something but there's so many libs that I need some advice on where to look for.

See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

{img fileId="1397" thumb="box"}

when you click on the polls icon on the Admin Home page, you are taken to the polls comments admin page instead of the polls admin page. User should not have to make an additional click to start work.

Tested on https://doc.tiki.org when you click the cog icon in the top bar and then one of the control panel icons in Chrome it does nothing (does not go to the control panel).

{img fileId="312"}

When you close an old tracker item, it shows up again in the since_last_visit_new module as new tracker item.
This also seems to happen when you change the status to "pending".

It happens also in dev.tikiwiki.org to me (user xavi)
See this one for pending: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1946

And this one for closed:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2124&trackerId=5&show=view

I logged in Jan 16th, and they appeared as new to me (user xavi, at least).

---

UPDATE: Still present in 12.x. {sign user="xavi" datetime="2013-11-17T09:52:11+00:00"}

{syntax type="tiki" editor="plain"}
This bug is seen by our IE 8 clients. We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

Our users are editing in the CKEditor WYSIWYG and try the Code plugin from the toolbar. The Code window opens as expected and the users enter their code in the correct field. On pressing Insert (or Replace) the code plugin is added in the editor but there is no contents in the plugin. If I open the normal editor it displays as%%%~np~{code caption="MyCode.java"}~/np~%%% which is completely the wrong syntax.

If I try using the Code option in FF then it opens a new window and I can add the code just fine. I view from the normal editor and it reads%%%~np~{CODE( caption="MyCode.java")}public class MyCode {
//testing a point
}{CODE}~/np~%%% which is correct.

Since IE is our corp standard our users need to be able to add files using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

Thanks,
Tim

{syntax type="tiki" editor="plain"}
Adding any type of code such as PHP or SMARTY saves fine but adding actual HTML code inside the CODE plugin generates some funky results.

This means that it would be impossible to create a wiki page that demonstrates on to write HTML.

Show username / password

user: admin
pass: 12345

{flash type="url" movie="display315" width="1193" height="1040"}

When you use the code plugin, the page width formatting is thrown off. Instead of seeing both left/right colums, the right column gets shoved off the screen and I have to scroll. This is with scroll bars already setup on the code plugin itself.

--
Chealer :
This happens when nowrap was not set.

Gary (chibaguy):
In my checking (trunk version, but same relevant CSS as in Tiki 3 and $), almost all browsers respect the overflow:auto rule for the code plugin and don't cause the page to widen. I put a long unbroken line of text in the code plugin, and in Opera, IE, Safari (Windows), and SRWare Iron (Chromium - webkit), even this unbroken line was broken to impose a scrollbar on the code area and avoid a scrollbar on the window. Firefox was the only browser that failed at this.

If the current rules - overflow:auto, and 90% width in some themes - then all browsers will allow the long line to display unbroken and create the page-bottom scrollbar, pushing the right column out of view. As I understand it, this is the behavior reported as a bug here.

It is weird and no idea how to reproduce but on the page https://doc.tiki.org/Changelog-1.8?page_ref_id=4088 the CODE plugin is ignored like if it was not enabled at all.

When page content is too large, the browser is way too large or some content is truncated/hidden:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=Hello%20World&preview=73

This is the good behavior in Firefox but not IE6:
http://www.wikicreole.org/wiki/TikiWikiCMSGroupware

Maybe CODE plugin should have wrap=1 by default, but with the horizontal scroll, it'll be OK.

{syntax type="tiki" editor="plain"}
Hi, as explained here : [https://tiki.org/forumthread79604|https://tiki.org/forumthread79604] ,
heavy scripts such as codemirror (1.2 MB) are always loaded (tiki 21, 24, 27), even when not in use, resulting in unnecessarily long loading times for visitors. Is there a way of loading heavy scripts only for pages that use them?

thx
--
mb

Codemirror is not showing links to switch the highlighter even if the preference is correctly set to do so.

Tried using firefox and chrome, with my user "xavi" (no admin rights) and "xavidp" (admin rights): same effect.

The preference is still set as
Configuration Wizard > Set up Text Area > Syntax highlighter (CodeMirror) Theme > "Off (but switchable)"

Codemirror: button to switch it on is hidden when first the editor is set to fullscreen

This was working in Tiki9.

To reproduce:
* Set codemirror feature to on, and mode to "Off (but switchable)"
* edit one wiki page with the plain text editor
+ notice that the button to "switch highlighter" is shown below the textarea. Do not click on it yet.
* click at full screen icon in the toolbar
+ notice that the button to "switch highlighter" is gone from the textarea surroundings

{flash type="url" movie="display683" width="778" height="654"}

----
Issue Still present on 06 February, 2014 15:02:50 CET- REV 49772. {sign user="xavi" datetime="2014-02-07T09:21:05+00:00"}

Colorbox in mobile 12.x LTS doesn't show up properly (empty black screen with a encircled cross in the middle)

To reproduce, see show.t.o instance:
u: admin
p: 12345

Load the homepage, switch to mobile, and click at the link in the homepage: "wiki syntax"

When the 'rel="shadowbox"' parameter is used with a wiki image, the popup expands to the full size of the original image, so scrolling is needed to see all of the image. Previously, the popup size was limited to some percentage of the viewport size.

Also, the "prev/next" links are missing when 'rel="shadowbox[[gallery]' is used; this is also a regression from before.

This inlcludes more specific information about a previous bug posting:
(http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=508&trackerId=5)

This bug affects Trackers when mirrortables are turned ON. It occurs with explicit names on or off.

Column headings in trackers disappear in tiki-view_tracker after a few columns when user has non-administrative permissions. This means any privs that are less than tracker-admin. The column headings table is drawn succesfully for a few columns, but then disappears, along with the column names, in the rightmost columns.

When editing a page on dev.tw.o, I will have proper grammar and punctuation, but after I save it, it appears that all of my commas "," are stripped out in the display. When I go to edit (or even a preview from an edit), the commas also disappear from the edit window.

While not really a high priority, bad, this will crash the app bug, I think it's pretty important for someone who typed in text with proper grammar to have that show up.

*** Also noticing in the tracker, that when I submitted this ticket I had selected something in the Data Type, Feature, and Version sections, but they didn't save, as well as Area and Related Project. ****