Category: 26.x

On the control panels, Editing, Plugins, right after installation, the GUI for the list plugin for several options and preferences has a "turn back" icon, "Reset to default value". (wrong as this is the default - thing was changed)

While it visually do the job (it reset the field or selector value) on Apply (Save) things are back to what they were.
Unchecking manually a checkbox seems to work.

Check the instance.
{mediaplayer src="display1939"}

On Tiki24 we have an admin "Print Setting" page : tiki-admin.php?page=print

If I want the generate a PDF from the action menu (first preferences on the admin page) this is what I see:
{img fileId="1714" thumb="box"}

Wiki print, the main feature to enable everything print, is somewhere at the bottom ? and PDF generation is at the top, preferences that rely on it are place above it... frankly it really look bad for Tiki to release such mess for users. We should use tab and reorder things.

Another example, the preference "Show Page title" is placed under "PDF settings" however it is applied to both (common preference)

In the Admin, if you search for "socnets" you will have results but nowhere to go as they are wrongly "not found in an admin panel".

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

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

May be temporary ?

This was tested on Tiki26 using Classic Bootstrap layout with Unified Admin Backend enable, fixed width enabled and a value for "Layout width" (1920px) wider than the available space in the admin display for a screen width.

IE: The site don't use a left column and is designed to use most, but not all, of the width available but in the admin view we have a 268px aside dropdown set.

In that case, the Tiki footer is under the left admin col.

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

On the Control Panels page there is a new remarksbox to encourage using the advanced mode switch.

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

No matter how many times I moved the switch to advanced saving or not (Apply) it is not effective and back to the initial position.

The switch from the Preferences Filter is working fine.

On a Tiki26 I searched for "payments" and this is the results displayed.

The feature payment is not yet activated (default).
Enabling the payment feature (Payment payment, features advanced) is the first step and a quite important step in the process (if not enabled, all the rest is not relevant)
However this preference is not the top result but buried somewhere in the middle of the results.

This is one example and I guess there may be worst case.

My results should have displayed the __Payment payment, features advanced__ checkbox at the top of the results.

---

Many too big "un-needed" warning are displayed and this added to the preference type (advanced in my screenshot) add confusion to the already dense Tiki preferences and admin options.

I mean, what is good for a big warning about "Exchange rate for types of credit to use" if the user won't use "Tiki user credits" and even "Payment" ?
If there were one warning from time to time on a page it would look important and relevant.
As there are too many warning displayed, it is just noise and people tend to skip them.

I'm not sure what should be the right solution, but I'd like something like a more discreet warning, the yellow warning icon - Requirements not met, and ONLY upon user action (mouseover, click, tooltip reveal, etc) to see the complete message. That way, the user is not submerged with warnings he doesn't need, and only when he need to see the verbose got the exact warning.

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

On a Tiki20 I can edit the default Wiki page, select text and create an external hyperlink using the toolbar button.

If I do that with "Ajax auto-save" enable (by default) all goes well.
If "Ajax auto-save" is disable I got the following alert;
{img fileId="1308" thumb="box"}

{syntax type="tiki" editor="plain"}
It would be really useful to be able to override the smarty templates used for email notifications (currently in -+templates/mail+- and -+templates/activity+-)

Probably a new pref -+mail_template_wiki_pages+- to look for pages "named exactly like the template files" (maybe starting with -+mail_+-?) with the correct -+tiki_p_use_as_template+- permission and if found, use that as a tplwiki resource instead of the tpl file.

Hopefully to be backported to 21.x when tested.

It's sometimes useful to allow anonymous or other users without full perspectives-related permissions to switch perspectives. For example, I want to demonstrate themes by using a link such as -+ tiki-switch_perspective.php?perspective=21 +- , in a dropdown menu, to switch to perspective 21. This perspective has preferences including a home page with info about the theme, using the theme itself, and so on, all set by the perspectives feature. The user continues to be in that perspective after leaving the page, so can see a blog or calendar or whatever using that theme, until switching to another perspective. This works fine for admin, who has all current perspectives permissions, but doesn't work at all for anonymous users. Visiting the page shows the theme set for the page but doesn't change the perspective.

I imagine there could be other scenarios where users would select a perspective and stay in it until they switch to another one.

There are now four permissions related to perspectives:
* Can admin perspectives (tiki_p_perspective_admin)
* Can view the perspective (tiki_p_perspective_view)
* Can edit the perspective (tiki_p_perspective_edit)
* Can create a perspective (tiki_p_perspective_create)
I propose that another permission be added:
* Can switch perspectives (tiki_p_perspective_switch)

Or whatever fix would be effective here. The "Users can change theme" option on tiki-admin.php?page=look serves the same purpose but seems to be set via that admin page rather than on tiki-objectpermissions.php.

Somewhat strangely, if I give anonymous the "Can create a perspective (tiki_p_perspective_create)" permission, then switch-perspective works for anonymous, who can see the list on tiki-edit_perspective.php and can input a perspective name but it doesn't appear in the list to be edited, etc. so this could be a hacky workaround but the clean solution of a new permission would be much better.

Articles do not have history. With wiki pages, there is always an undo (and multistage, and with comparison etc.). Articles don't have that, and I believe they should, and it shouldn't be hard to add... The revision system could be shared, or at least recycled, from the one wiki pages have.

You can use Tiki articles in multilingual website having article for several language.
The usual process is to create a main article (default language) then create other articles with different language and assign them as translation of the previous article.
Article => Edit => Advanced, Attach existing article ID as translation

You have to insert the ID of the article and that really not user friendly.

You should be able to retrieve articles by name in a select.

---

On second thought...

If wed really like to improve we could reuse the same interface/system we have with wiki pages (translation) as it is working fine is much better (proposing translation if missing and displaying set of translated documents) and will be better for UX (consistency).
I just wonder if it worth the investment.

''Reviewed with Tiki25''

--If the auto-assign is set to "Creator" and the admin edit an existing item with a null username (creator deleted, error with duplicate feature, etc), the admin username will be assigned and saved. This can happen even if admin doesn't see the field (if he use a modal to modify some preferences or part of the item).--
''Not able to reproduce anymore, may have been fixed''


If the admin duplicate an item that has a another user selected in a user selector field, the new item (the clone) will be saved with the admin for user.

{FADE(label="Instance")}
__Tiki show trunk and Tiki show 24 are not working as expected__ but I could reproduce the bug on a Tiki24 instance:
http://bsfez-11581-7751.show2.tiki.org/tiki-view_tracker.php?trackerId=1

If you want to reproduce you can log as admin/12345 go to the tracker a duplicate an item from a different user using:
http://bsfez-11581-7751.show2.tiki.org/tiki-tracker-clone_item?trackerId=1&itemId=1&modal=1
{FADE}
{img fileId="2021" thumb="box"}

When the wiki page contains HTML headings, autotoc fails to display. It doesn't matter if the HTML plugin is used, or if HTML is activated for the page (and the plugin not used), in both cases the content of the page will narrow to make space for the autotoc, but the autotoc doesn't appear. If there is a combination of wiki syntax headings and HTML headings, autotoc will not appear. If there are only wiki syntax headings, then autotoc displays normally.

We have a few boutons, menus and menu-items that are displayed in Tiki while there is nothing doable.

For example at : https://tiki.org/Donation

Some are just overloading the screen.
Some have a very little interest (informative)
Some have an informative value (but a button or an item menu is not the right way)

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

--

Another example is the structure menu displaying __only__ an item for the page I'm on and clicking on it just doesn't do anything but reloading the page. (check as anonymous)

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

It is not possible to change the image banner once one has been uploaded.
See : http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php?bannerId=1
Try to change the banner it shouldn't work.

There is an issue with the image upload.

I tried to understand if it was possible and how to use the tablesorter with tracker filter plugin.

The trackerfilter modal is NOT user-friendly.
Too long list of things the user may not necessarily needed (menu child accordions would definitely help reducing the tremendous amount of information visible there)
The explanation have been copied and pasted as is from another place and hardly make sense.
Fields are not grouped together, naming is not helping (table sorter is hardly if ever found in the options and parameters list or help)... It is a mess and it took me 30mn of test to make a sample visible here : https://doc.tiki.org/PluginTrackerFilter#Trackerfilter_with_table_sorter_setting_to_perform_calculations

We have in Tiki a way to submit and approval Wiki page revisions.
Unfortunately the naming and labelling of things make hard for new coming (and oder) to find documentation and the feature on the Tiki preferences;

Related
*https://tiki.org/forumthread77682-Information-Documentation-on-Tiki-wiki-staging-and-approval
*https://doc.tiki.org/Flagged-Revisions
*https://doc.tiki.org/Wiki-Page-Staging-and-Approval
*https://doc.tiki.org/Wiki+Page+Staging+and+Approval
*https://dev.tiki.org/Flagged%20revisions%20tab
*https://profiles.tiki.org/Staging_and_Approval
*https://doc.tiki.org/Staging-Approving-Group-Category-Permissions
*https://doc.tiki.org/tiki-searchindex.php?filter%7Econtent=staging

We should decide a name for this and use it everywhere.

Currently, the blog feature features only limited information, both for users and for admins.

For users, new blog entries should IMHO be listed in the since last visit module, currently they aren't.

For admins, blogs AND blog entries should be part of the statistics page, currently both aren't, so as admin, you only see the total number of blog page views, and have no clue, which of your blogs is more popular, and inside blogs, which entries generated the biggest audience...

When you enter dto's preferences and want to set your location in your profile, you can no longer search for your town. Doing so yields this error message:

REQUEST_DENIED: You must use an API key to authenticate each request to Google Maps Platform APIs. For additional information, please refer to http://g.co/dev/maps-no-account

Looks like the code for that no longer interfaces correctly with Google...

At tiki-directory_browse.php, instead of the normal directory content, this error is displayed:

{CODE()}
Fatal error rendering template file ...\master\templates\tiki-directory_browse.tpl

TypeError: Cannot access offset of type string on string in ...\master\temp\templates_c\en_basic^9afc4689a26161c5d3d505286984c3b17c2bc523_0.file.tiki-directory_browse.tpl.php:63
Stack trace:
#0 ...\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_resource_base.php(123): content_647f08437715c5_90536580(Object(Smarty_Internal_Template))
#1 ...\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#2 ...\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#3 ...\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_templatebase.php(238): Smarty_Internal_Template->render(false, 0)
#4 ...\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_templatebase.php(116): Smarty_Internal_TemplateBase->_execute(Object(Smarty_Internal_Template), NULL, NULL, NULL, 0)
#5 ...\master\lib\init\smarty.php(296): Smarty_Internal_TemplateBase->fetch('C:\\laragon\\www\\...', NULL, NULL, NULL)
#6 ...\master\lib\init\smarty.php(529): Smarty_Tiki->fetch('C:\\laragon\\www\\...', NULL, NULL, NULL)
#7 ...\master\lib\init\smarty.php(473): Smarty_Tiki->assign_layout_sections('tiki.tpl', NULL, NULL, NULL)
#8 ...\master\tiki-directory_browse.php(113): Smarty_Tiki->display('tiki.tpl')
#9 ...\master\route.php(348): include('C:\\laragon\\www\\...')
#10 {main}
{CODE}

Is it a bug or a feature, that truncates the output of strings after a pipe symbol?
Example to illustrate: /lib/prefs/feature, line 2425:
{CODE(Colors="Tiki")}
'feature_wiki_argvariable' => [
'name' => tra('Wiki argument variables'),
'description' => tra('Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}'),
'type' => 'flag',
'help' => 'Advanced+Wiki+Syntax+usage+examples',
'default' => 'n',
'keywords' => 'arg var vars',
],
{CODE}

The output of this descriptions stops at the pipe symbol between paramname and default, supposedly in all languages, including English. I cannot translate into German with this entry in custom.php:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname|standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
but when I replace the pipe with a slash, all is well:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname/standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
So please check whether this is a bug or a feature of tra(), and depending on this check either fix it or change in English this description, to use text without a pipe.

Side remark: The pipe doesn't show here, just as the the arguments in double curly braces! Although I enclosed my code sample in CODE tags! ({sign user="Jyhem" datetime="2022-03-03T14:30:00+00:00"} Arguments are interpreted first before anything else. That's what ~np~~~/np~np~nonparsed~np~~~/np~/np~ is for)

The calendar event "tentative/confirmed/cancelled" status display is broken. The admin can select one, and the radio button indicates that it is selected, but on the saved event page, all three options are displayed.

https://matrix.to/#/!SLEgqpTNTlGYAhzNvK:gitter.im/$oQIbW8GUQp2nQZEG34-hpHp2N9UQSEnk89a1nXcKd8A?via=gitter.im&via=matrix.org&via=coeus.ca

In Tiki 26 this is the bottom of : https://tiki.org/tiki-calendar-edit_item?calitemId=243

{img fileId="2109"}

From my point of view;
* "Preview" and "Copy to a new event" seems the prevalent actions (they are not) and they look alike
* The "Save" action (the prevalent action) is kind of dimmed (text/bg contrast doesn't help) and between the 2 action above)
* The "Delete event" look also like a prevalent action and lost its danger attributes (all buttons look redish/orangish)
* The "Export Event as Ical" is the same colors as the save button.

Added to this, some terms in buttons are Capitalized some are not.

On mobile...
{img fileId="2110" thumb="box"}

Admin can set the days displayed in Tiki calendar.

It can be set from the calendar admin panel : tiki-admin.php?page=calendar#Calendar
{img fileId="1807" thumb="box"}

It can be set from each calendar edit settings (wrench => edit) : tiki-admin_calendars.php
{img fileId="1808" thumb="box"}

However the days are displayed in the calendar
{img fileId="1809" thumb="box"}


By extension they will be seen as "existing" days for a calendar event created/used with tracker field calendar item.