Category: 26.x

Instance is coming

Module execution failed if the visitor is anonymous.
Anonymous can't see listpages.php even if they have Wiki admin permissions

This filter is no longer work if the user is anonymous

{CODE()}
{filter field="title" content="~np~{~/np~{page}}"}
{CODE}
Instance coming... (not reproducible with default settings... more tomorrow)

If you do not load a specific bug tracker (e.g. by a bookmark), but insted start on the search page for bugs and feature requests, the whish list, under

https://dev.tiki.org/Wishlist

you simply get a 503 ("Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.")...

Thanks
hman

With Codemirror enabled or toggled Admins can't edit text-area field on doc.t.o.

Go to doc.tiki.org, log as admin(s), go to look & feel, go to customization try to edit the code in the HTML head tag with or without codemirror enabled.

''Enable to upload a file on dev.t.o so I copied it somewehre else.''
https://streamable.com/e/asi284?loop=0

There is a regression when choosing values from the multiselect fields (the Select feature must be enabled?) the forms input fields do not behave correctly when typing the suggestions. Also the pink rectangle looks a bit ugly. It was blank (same color as the background) before when you started typing in it?

See the video below:
{mediaplayer src="display1800"}

(This is also to test if the RTC video recording works properly ;))

Wouldn't it be great if a wiki link (the standard [] syntax) would check whether the current user has rights to the page that it links to? THat way we could turn off the hyperlink if the user cannot open the page anyway...THat would add some processing overhead, but I am sure that would be manageable.

Don't know where to begin, though, I do not really understand the wiki processing in Tiki...

When the calendar is in year view, all 365 days are displayed in one horizontal row. A look at the page source shows -+ tbody role="presentation" +- contains -+ tr role="row" +-, which contains many, many instances of -+ td class="fc-daygrid-day fc-day fc-day-sat fc-day-past" +- , not just seven instances for the seven days of the week as is done in the semester view.

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.