Category: 31.x (future, currently trunk)

{syntax type="tiki" editor="plain"}
On tiki-list_file_gallery.php?view=page (standard gallery display, not elFinder), the fgalexplorer_open icon doesn't open the tree navigation. It works normally on view=list.

Also, view=admin doesn't have a tree navigation at all. Seems like it should.

{syntax type="tiki" editor="plain"}
Ordered lists by default are numbering the list sub-items incorrectly, I believe. But when the admin option "Multilevel style numbering for ordered lists" is activated, then the numbering is correct. I believe the numbering that the admin option provides should actually be the default, so there might be no need for the option. I suggest removing the option and making its numbering method the default. That is, all ordered list elements in wiki text should have -+list-style-type: decimal+- . Or if the admin option is retained, it could have a selector of other -+ol list-style-type+-s.

Also, when this option is activated currently, a class is added to the body tag that gives the ''body'' a left margin of 2rem. There is no reason for this class on the body tag, as far as I know, and we for sure don't want it to be adding a new margin to the whole body of the page.

See the discussion with screenshots here: https://matrix.to/#/!SLEgqpTNTlGYAhzNvK:gitter.im/$jVZB_SGxWolFLB9xOaCuzPIX50EfJqpipaNStGchSKw?via=gitter.im&via=matrix.org&via=sans-nuage.fr

{syntax type="tiki" editor="plain"}
Please rename the start button of the wizards.

The reason is that the translation function tra() is completely ignorant of context. And at least in German the problem arises that the imperative of starting, that "start" means, is different from the noun that marks the beginning of a calendar event. In English both are "start", but not in German.

In German that is "Beginn" (as with all nouns with upper case 'b'), while the imperative of starting would be "beginne" (as with all verbs with lower case 'b'), or in the preferred more professional looking passive construction "beginnen". The verb "starten" also exists, with that it would either be "starten" or "starte", but this arises the problem that if I rename one, I must as a consequence also rename the other. It is not possible to correctly translate both!

Because tra() is igorant of context... So I have to make a decision which wrong translation does lesser damage... So please find a different string for "Start". Preferrably, since it might take aeons before tra() becomes context sensitive, one that carries the context inside the string itself, like "start wizard". This should be a recommendation FOR ALL STRINGS throughout Tiki...

{syntax type="tiki" editor="plain"}
Wow, toolbars are seriously messed up ((File a big|here))... what isn't broken in 30.x?

Anyway, on doc.tiki.org and all my v29+ tikis the plugin help has disappeared from the help popup. Here however it has appeared as a separate {icon name=plugin} icon, so presumably whoever broke this hasn't done an upgrade script (that works)

Also no preview on this text area? Wow...

{syntax type="tiki" editor="plain"}
The FiveAlive-Lite Raspberry theme’s intended burgundy header background (#A30D3A) is being overridden by a dark gray (#212529)

Probable regression from:
-https://gitlab.com/tikiwiki/tiki/-/merge_requests/9092
-https://gitlab.com/tikiwiki/tiki/-/merge_requests/9117

{syntax type="tiki" editor="plain"}
Uploading a file on tiki-upload_file.php shows an error when uploading anything:
-+UploadAjaxError: fail to POST tiki-ajax_services.php?controller=file&action=upload 500+-

This happens in -+\Services_File_Controller::action_upload+- on the line that runs -+updateDeleteAfter+- (210 in master currently), and it is because the values -+$input->deleteAfter+-0 and -+$input->deleteAfter_unit+- are now jitFilter objects, and not integers any more.

Also, the "Automatic upload" checkbox has gone missing, and from what i can tell, it is unzipping active files automatically and i need it not to currently.

{syntax type="tiki" editor="plain"}
When SmartMenus pref is enabled the __vertical menu__ items arrows should not point always down but left/right (depending on the RTL language) and they should not overflow from the modules in the left/right zone columns.

This is how it looks on "iPad Mini" (1024x768) sized screen:
{img fileId="3235" thumb="box"}

This is how it looks on branch 29.x (notice the correct arrows):
{img fileId="3236" thumb="box"}

Steps to reproduce:
# Make sure you have jquery_smartmenus_enable preference enabled
# Check the vertical menu module assigned in the left or right column

{syntax type="tiki" editor="plain"}
When the feature is opened, the spreadsheet grid shows but there's no way to edit it. When I click "Spreadsheet help", this error message displays in the modal:

"Too late to modify headers. Headers already sent by output_headers() called at [/home/tiki-doc/public_html/temp/templates_c/en_social^c65dbf08b2e2cbfd6ac5170dcabfe3af12708efa_0.file_header.tpl.php:441])"

{syntax type="tiki" editor="plain"}
Screenshot here: https://matrix.to/#/!SLEgqpTNTlGYAhzNvK:gitter.im/$lGdaEU57JgMoRiZO4C1Z0RK37MPiQSdOTzkRUP0z2yM?via=gitter.im&via=matrix.org&via=sans-nuage.fr

RecordRTC must be enabled to reproduce the issue
Preference name: fgal_use_record_rtc_screen

There is conflicting rule on line 96 of -+themes/base_files/feature_css/recordrtc.css+-:
{CODE()}
@media (max-width: 640px) {
button[id^="btn-"] {
width: 100% !important;
min-height: 48px !important;
font-size: 16px !important;
}
}
{CODE}

The tracker fields table's ''overflow-x: hidden'' property isn't working because the table doesn't have a property ''"display: block"'' (or ''inline-block'' or ''flex''). This is noticeable when fixed-width is activated or when the browser viewport isn't wide.

As of Mar 8, 2026, the tracker fields table does display now . . . because the side columns have been removed along with all the pagetop navigation, etc. What was the plan here? If the original layout of the page could be restored and the display property of the table added, that issue would have been fixed.

I added this issue to the "Release Blocker" category because trackers are commonly used and the UI shouldn't be this broken.

{syntax type="tiki" editor="plain"}
Clicking the format on -+tiki-tabular-edit?tabularId=42+- brings up the edit format dialog correctly, but it add a duplicate field instead of editing the one you clicked.

{syntax type="tiki" editor="plain"}
When clicking the usual edit icon {icon name=edit} the field no longer edits in place - why?

Secondly when clicking "ok" in the tiny dialog that appears i get a "following mandatory fields are missing: login" error, but that field does have a value for that item (showing in a different column).

Curiously, it works here, so maybe it's the field type that's the problem. Mine is a UserSelector (it's a user tracker)

Still a regression in terms of UX though, imho

{syntax type="tiki" editor="plain"}
When writing a blog post in master currently, trying to preview it causes a 500 error. Edge browser says "This page isn’t working right now - localhost can't currently handle this request."

{syntax type="tiki" editor="plain"}
Currently in master, on Unified Admin Backend pages, modals are opening behind the top navbar. This can be seen at tiki-objectpermissions.php by clicking the "Assign" button. The modal has a z-index value of 1055 and the navbar's z-index value is 9999. Considering the default Bootstrap z-index values that range from 1000 to 1090 (https://getbootstrap.com/docs/5.3/layout/z-index/), and Tiki's global fixed-top navbar z-index of 1050, the UAB navbar's z-index does seem to be quite a bit out of line and should be made the same as the global navbars unless there's a reason for it to be higher.

{syntax type="tiki" editor="plain"}
When upgrading Cartograf from Tiki 21.x (possibly 24.x?) to 27.x we found that "[https://gitlab.com/tikiwiki/tiki/-/merge_requests/2170|duplicate cascade]" wasn't set on the child trackers to duplicate features when a map is duplicated.

This used to happen always before this option was added but it would be nice, espescially if "Cascade actions" is set to "All" on the ItemLink fields, then -+duplicateCascade+- should be set to "Yes" (1).

{syntax type="tiki" editor="plain"}
When you hover a user name the user avatar is always missing now

{syntax type="tiki" editor="plain"}
Trying to select users with user selector is not working at all

{syntax type="tiki" editor="plain"}
The first problem is that even when the admin preference to display the page title is turned off, there is still an empty h1 tag and heading link in the page. This takes up vertical space and the link icon is visible if the space is hovered over. Turning off the page title display should also "turn off" the heading and link code in the template. When the pref to display the page title is activated, the page title text that displays does have an h1 tag but it has no link code or icon.

The second problem is that the preference option "Display page name as page title" causes the page title to be displayed ''above'' the ''main'' element. This is not good HTML or DOM structure, not good for accessibility, etc.

The third problem is that the preference option "Display the page name inside the page content" doesn't actually cause the page name to be displayed inside div class="content". It's not clear to me why this div was added when there was already an article element and a div id="page-data" (or why the "content" class wasn't added to the div id="page-data"), but IMO the preference name and HTML should be consistent. (Usually there's no visible difference, but a theme might give the page content a different style than the rest of the page, so in this case it's a significant distinction.) The h1 heading tag and link icon that has no text, described in the first paragraph, is actually located correctly, inside div class="content", IMO.

Comparing to versions 27 and 28, it looks like to me that the admin handling of the wiki page title display hasn't been good for a while now so I can understand the motivation to make some changes but there appears to be more work to do.

{syntax type="tiki" editor="plain"}
In case we have "Wiki page edit buttons location" set (Preference name: wiki_actions_bar) to "Both" (shows buttons on top and bottom) the bottom "Cancel edit" is not working.