Category: Usability

plugin snarf produces ugly output, with many empty lines within the output.
It's not usable for production.
Tired snarf'ing tiki sites with 2 columns, just one, and no lateral columns: similar ugly effect
Tried with html sites, same ugly effect of many empty lines everywhere...

The plugin survey is not displayed on the help plugin section of a wiki page.
I checked it was activated.

Plugin Tracker doesn't return feedback any more after inserting item if url param is provided

According to the documentation of Plugin Tracker ( https://doc.tiki.org/PluginTracker#Examples ), this should be working:
{CODE()}
{TRACKER(trackerId="1" fields="1:3:4" action="Send")}
!!! Thanks!
Thank for your contribution!
{TRACKER}
{CODE}

But if we send the user to a new page, the "thanks for your contribution" is not shown any more. And we could have some way to get the user see that feedack even when the user is sent to another page after inserting the item. Something could be added reusing the function that lindon added recently (months) to trunk to have a common way to display feedback to users after their actions.

Some discussion in the devel list can help elucidate how to handle this implementation.

Isse reproduced here in a 15.x instance as a reference:
http://xavi-9794-6059.show.tikiwiki.org/tiki-index.php?page=Bug_Tracker
u: admin
p: 12345

That used to work nicely in the past.

Plugin TrackerList & TrackerFilter have non-linked item fields display links to current page

even if param showlinks="n" (no change)

See it reproduced here:
http://xavi-9794-5935.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12
u: admin
p: 12345

Plugin TrackerStat has no easy replacement with Plugin List, as far as a I know.

When trackers are used to fill in questionaires, there are sometimes long phrases that are written in full in the description of the field, and the field name is just some short name to refer to it.

When the user fills in the form, the field descriptions can be shown below the field.

But when results are shown through PluginTrackerStat, no field description is shown, and in some cases, it's hard to understand the answers without the full text shown in the description of the field.

This could be solved with a param to optionally display the field descriptions in the Plugin TrackerStat.
-
See it reproduced here:
See it reproduced here:
http://xavi-9794-5637.show.tikiwiki.org/tiki-index.php#contentvotingsystem-2
u: admin
p: 12345

field: 12
How many days?
{CODE()}
1 1 %33.33 <->
1 10 %33.33 <->
1 2 %33.33 <->
{CODE}
How many days is almost meaningless here at result-display time. The description of the field needs to be shown also: "__How many days did you attend last year to the weeksly meetings of hte organization?__"

Plugin TrackerStat has no easy replacement with Plugin List, as far as a I know.

We need to have the answers to a question (tracker field) sorted with natural case sorting. For instance, if you ask in the question a radio button showing options from 1 to 24, you will get the answers sorted as something like (copied from a production site):

{CODE(ln="1")}
1 10 %3.12 <->
1 11 %3.12 <->
2 12 %6.25 <->
1 13 %3.12 <->
1 15 %3.12 <->
5 16 %15.62 <->
4 18 %12.50 <->
1 2 %3.12 <->
3 20 %9.38 <->
1 21 %3.12 <->
1 22 %3.12 <->
1 24 %3.12 <->
1 24 (Always) %3.12 <->
3 3 %9.38 <->
3 5 %9.38 <->
2 6 %6.25 <->
1 8 %3.12 <->
{CODE}

See it reproduced here:
http://xavi-9794-5637.show.tikiwiki.org/tiki-index.php#contentvotingsystem-2
u: admin
p: 12345

field: 12
How many days?
{CODE()}
1 1 %33.33 <->
1 10 %33.33 <->
1 2 %33.33 <->
{CODE}
Answer related to "10" should be after the one related to answer number "2"

PHP function natcasesort needs tobe used to sort answers.
http://php.net/manual/en/function.natcasesort.php

No UI checkbox for the following.

INSERT INTO `tiki_preferences` (`name`, `value`) VALUES
('wiki_validate_plugin', 'n');

The file description text is always present if the object name (stored name, not actual filename) is selected to be displayed. Selecting to display the object name automatically displays the description.

One of Tiki's biggest accessibility problems is buttons with just an icon and no text label. A solution for this is adding an aria-label attribute ([https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label]). The label doesn't display visually but is recognized by screen readers, etc. Buttons used in Smarty templates should have this and it should be used in every case. PluginButton should also have an input field for aria-label, marked "mandatory".

Plugin Convene should suggest by default the username of the user viewing the page as the one to be added.

With long lists of users, like in t.o, browser becomes slow due to the building of the long users list. It' would be way easier for most use cases if your own username was provided there as a suggestion (for logged in users) so that user just needed to click at "+" button.

PluginConvene UI doesn't allow editing date choices for a user anymore

Reproduced here:
https://tiki.org/Roundtable+Meeting+2016+11

Add a user, and then, attempt to edit the user choices: the dropdowns to choose from the options for each date are not shown, but same page is reloaded, with a very long url, etc.

PluginConvene UI doesn't display X number cells when casting choices after user added X number of new dates. Reproduced here:
https://tiki.org/tiki-pagehistory.php?page=201909+TAG+Meeting&newver=44&oldver=43

I added two new date options, and then, when I attempted to edit my choices through Convene UI, I was not able to add all my choices, 2 cells were missing. In fact, they were missing also at display time. Odd.
Gary reported some similar oddity in that page also:
https://tiki.org/tiki-pagehistory.php?page=201909+TAG+Meeting&newver=24&oldver=23

((doc:PluginConvene)) is pretty cool!

See image attached to this tracker item.

But once date is picked, unless a manual operation is done like this: https://tiki.org/tiki-pagehistory.php?page=Roundtable+Meeting+2021+10&newver=42&oldver=41&bothver_idx=22 the user is left wondering: when is the meeting?

((doc:PluginCountdown)) a great idea. But showing time to the seconds is not a good default.

Wish:
Make options; Days, Days & hours, etc

Should be an option as to how to handle once time is passed.

__x days since__ or __the event has happened__

And locate time has no effect here:
http://tikiwiki.org/TikiFestNY

{syntax type="tiki" editor="plain"}
PluginDBReport, when doing a report with mulitple rows, will take the last "CELL ...." and make all usage of CELL the same as the last call, even across rows an header/footers. So if you have:

TABLE
HEADER
CELL "FIRST"
CELL "LAST"
ROW
CELL "this is first"
CELL "THIS IS LAST"

It will come out as a 2x2 table, with everything saying "THIS IS LAST".
Obviously host information is useful too, this is a CentOS LAMP server with php 5.2.11 and apache 2.2.14 and mysql 5.0.86 .

{flash type="url" movie="display566" width="918" height="516"}

The wiki plugin, PluginFade, no longer fades out, but still fades in.
Observed in Tiki6 for IE 8 and Firefox 3.6


!!!!{FADE(label="Click to Reveal, Then to Hide")}

~~#F00:__Reveal works, but Hide Does not work__~~

~~#00C:Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus nec mollis erat. Morbi cursus nunc quis metus semper euismod. Ut facilisis est ligula, eget lacinia metus. Nulla tempor semper risus ut viverra. In faucibus purus et eros consequat pharetra. Fusce mattis arcu lorem, non hendrerit erat. Nulla eu mauris urna. Pellentesque nec velit mi, eu rutrum eros. Quisque nec leo enim, id rutrum metus. Mauris luctus sapien nec nulla scelerisque ultrices. Cras sodales, justo nec elementum imperdiet, elit nulla sagittis ante, at tempus ante risus ut nunc. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi nec risus eu ante pellentesque adipiscing vel eget risus. ~~

{FADE}

The iframe plugin page on tiki.org needs its own plugin approved:

http://doc.tiki.org/tiki-index.php?page=PluginIframe#Example

===Summary===
The plugin for inserting modules into a wiki page has a bug where it crashes whenever it encounters custom modules. The following JS applies some duct-tape to the issue, and prevents the crash. I didn't get too deep into the workings of it, just got it to work. Someone who has worked on it before probably has a better understanding of the whole system, and could determine if this was the way to do it or not (the change could have cascading effects on behavior of pluginModule and how it deals with custom modules?)

Note: crash outputs the following error in js console: -+Uncaught TypeError: Cannot read property 'params' of undefined tiki-js.js:1304+-

===Procedure===
To fix the issue, one can do the following:

Modify -+lib/tiki-js.js+- line 1303. Change the else statement to an else if, checking for the undefined object which would break things.

Note that the code in the examples below if from tiki 10, not 11, and may be a little bit different in 11, but the problem remains in 11 and the line changed is the same, and fixes it in 11 too.

So, in this block

{CODE()}//For PluginModule, add selected module parameters to the plugin edit form
if (type == 'module') {
//isolate the module parameter object so it will be shown first in the form
var onlymod = {"params":{"module": meta.params.module}};
//user has not changed the module selection since opening the form
if (typeof selectedMod == 'undefined') {
//pick up the parameters of the saved module parameter
if (typeof pluginArgs.module != 'undefined') {
//this orders the module parameter first, module related parameters second, other PluginModule parameters besides module last
meta.params = $.extend(onlymod.params, tiki_module_params[pluginArgs.module].params, meta.params);
//Use the module description
meta.params.module.description = tiki_module_params[pluginArgs.module].description;
//otherwise pick up the parameters of the first module option since that will be selected automatically
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[meta.params.module.options[0].value].params, meta.params);
meta.params.module.description = tiki_module_params[meta.params.module.options[0].value].description;
}
//user has selected another module while the form was open - pick up parameters for the selected module
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}
}{CODE}

change this statement

{CODE()}
} else {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}

{CODE}

to
{CODE()}
} else if (typeof tiki_module_params[selectedMod] != 'undefined') {
meta.params = $.extend(onlymod.params, tiki_module_params[selectedMod].params, meta.params);
meta.params.module.description = tiki_module_params[selectedMod].description;
}
{CODE}

===Context===
The issue is caused because the module plugin tries to get the parameters for the object to display in the interface, but for custom modules there are none. The tiki_module_params object stores a parameters object for each module as the value for an attribute named after the module (e.g., -+tiki_module_params~np~[mymodule]~/np~+- would return the params object for -+~np~[mymodule]~/np~+-). The problem is that the if there are no parameters for the object, it sets the value for the module attribute to false, and the unmodified else statement above from -+lib/tiki-js.js+- will try to read the attribute .params from the false object, which will fail, and the js will crash.

Another possible solution to this issue could be to populate the value as an empty object instead of false, in -+tiki-jsmodule.php+-.

{syntax type="tiki" editor="plain"}
Using PluginRSS ([https://doc.tiki.org/PluginRSS]) to display information from an external Tiki calendar events RSS feed, the events display most distant (ex: October) first, then September, then August. It's more logical and more typical to display the nearest upcoming event first and the ones farther in the future after that. That's the way the display works in the Upcoming Events module, which makes sense.

I don't see a way to change the sorting of events when configuring the plugin. In particular, if I limit the number of events displayed to 1, I would like the next, upcoming event to display, not the one that's several months away. I don't see anything in the docs (Feeds, Calendar, etc.) or the feature interface about controlling this.

The order is correct (closest event is first) in https://tiki.org/tiki-calendars_rss.php But when I use PluginRSS in a local wiki page, the order is reversed (most distant event is first). This is what seems to need correcting, or at least a sorting order parameter added.

((doc:PluginSlider)) lost start/stop control after upgrade from 12.x to 15.x

See the problem reproduced in doc.t.o, where the param to build Start/stop is set (buildstartstop="y" ), but nothing is shown:
https://doc.tiki.org/PluginSlider#Example

(compare with the screenshots from Tiki9/Tiki12 sites in the doc page)

After submitting a tracker item using PluginTracker, the form doesn't show after the page refreshes. This is because of certain url parameters that are added when the page refreshes. For example the url upon refresh can be:
tiki-index.php?page=HomePage__&ok=y&iTRACKER=1#wikiplugin_tracker1__

The parameters in bold above cause the form to not show. If the following lines are commented out in wikiplugin_tracker.php (around line 986 in 12x) then the form will show:
{CODE()}
} else if (!empty($page)) {
$url = "tiki-index.php?page=".urlencode($page);
if (!empty($itemId)) {
$url .= "&itemId=".$itemId;
}
$url .= "&ok=y&iTRACKER=$iTRACKER";
$url .= "#wikiplugin_tracker$iTRACKER";
header("Location: $url");
exit;
{CODE}

I set the admin password for the show instance to 12345. See instructions for recreating on the home page of the show instance.

{syntax type="tiki" editor="plain"}
PluginTrackerItemField has rather limited expressive power.

Using Tiki 2.1, and tracker to make a survey. When using the ((doc:PluginVote)), the field type "header" is not shown properly when inserting tracker items. The header is shown as plain text, and at the end of the tracker, the headers all put all together, even if they were inserted between other fields of the same tracker.

Moreover, the text area field is not shown in the results (stats) part of the Plugin Vote, but only the title of the field (not the content, I mean)

---
In addition, if would be desirable (for usability purposes for new users) to set the tracker insertion form available as default (with a param at the Plugin Vote definition). New users may find it very hard to understand that they have to click on a tiny + sign to display the content of the form in order to fill the survey

----
item closed and marked as outdated (who knows whether this thing works in current versions, and I don't have time to test again: I'm not using this plugin any more for the time being)

When you are on a page of a wiki structure, you can click on the print icon, but you will only print that single page.

The icon and option to "__print this page and all the subpages__" (= in the the sub-structure) right from there (without going through all the clicks at "Wiki > multiprint > select structure > print") would be very welcome, since the base feature to rpint the full structure exists.

From the home of the structure, it would print the full structure (as it can be done with one click from a structure within a Workspace through ((doc:AulaWiki)) mod, or through many clicks as usual, as explained above).

If the user is on a subpage of the structure, that button would print that page and all subpages from the same structure.

Does it make sense?