Category: Easy for Newbie Dev

Because I keep finding bugs where translation is impossible due to missing tra(), tr() or tr in curly braces, I opened this new umbrella bug report.

Here I will add only newly found bugs, I will not integrate the already existing bug reports into this!

/lib/prefs/calendar.php has this on line 78:

{CODE(Colors="Tiki")}
'description' => 'Interval to show between minutes on time selectors',
{CODE}

Without tra(), the description cannot be translated into any language...

{syntax type="tiki" editor="plain"}
At https://dev.tiki.org/Wishlist if you try to sort by "last modified" then to display "all" status.
It showed an error.

Demo during the team dev session of wednesday 20251126.

It took me some time to find out why I could not translate a particular string in /lib/prefs/freetags.php, and this is it:

{CODE(Colors="Tiki")}
'freetags_normalized_valid_chars' => [
'name' => tra('Valid characters pattern'),
'description' => tra('Click on the links below to set or clear a pattern to limit characters accepted in tags. '),
'type' => 'text',
'size' => '30',
'hint' => 'Useful to eliminate characters such as “,” which users can enter by mistake instead of a space.',
'default' => '',
],
{CODE}

This looks decent, it also carries calls to the tra() subroutine. But I could not catch it with this entry in custom.php:
{CODE(Colors="Tiki")}
"Useful to eliminate characters such as “,” which users can enter by mistake instead of a space." => "Nützlich, um Zeichen zu eliminieren wie Kommata, die Benutzer anstelle von Leeerzeichen eingeben können",
{CODE}

The string for pattern matching is exactly identical to it's declaration in the source code, but it was not caught. Until finally I pumped the string into GHex, to look at its real composition.

{CODE(Colors="Tiki")}
echo -n "Useful to eliminate characters such as “,” which users can enter by mistake instead of a space." | od -A n -t x1
55 73 65 66 75 6c 20 74 6f 20 65 6c 69 6d 69 6e
61 74 65 20 63 68 61 72 61 63 74 65 72 73 20 73
75 63 68 20 61 73 20 e2 80 9c 2c e2 80 9d 20 77
68 69 63 68 20 75 73 65 72 73 20 63 61 6e 20 65
6e 74 65 72 20 62 79 20 6d 69 73 74 61 6b 65 20
69 6e 73 74 65 61 64 20 6f 66 20 61 20 73 70 61
63 65 2e
{CODE}

So what's looking decent are actually Unicode characters

{CODE(Colors="Tiki")}
e2 80 9c 2c e2 80 9d
{CODE}

I have absolutely no idea how to escape that so PHP will find it in pattern matching... Devs, please do not use Unicode unless really really necessary...

The page describing tracker fields hasn't been updated since Tiki 9.x, so several types are missing.

So either manually update ((Tracker Field Types)), or (even better) write a small wiki plugin to automatically generate that list.

If you change a listing, like on the Wishlist, and change sorting order, the URL gets an additional mention of the sort order.

But it's reversed, compared to the actual setting. So if you want to sort the Wishlist by modification date, descending (which IMHO should be the default), so the latest are listed at the top, the URL states

{CODE(Colors="Tiki")}
https://dev.tiki.org/Wishlist#sort_mode=modification_date_asc
{CODE}

ASC=Ascending. If you change sorting to ascending, the URL states _desc...

We have a few places where with placeholders and help text for link that shows "http://".
They should display more modern link usage: "https://".

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

When a user is registering on a tiki, within the default template, if there is an error, it is no longer obvious that there is an error. The errors use to be highlighted, but now they are black text that looks like field descriptions.

{syntax type="tiki" editor="plain"}
User wizard (accessible via -+/tiki-wizard_user.php+- ) needs some love to get harmonized consistent look and feel (UX) with the Admin Wizard ( -+tiki-wizard_admin.php+- ).

It has some old ugly icons (they should be replaced by FontAwesome icons) and broken GIF image references when you go through the steps of the wizard.

Please have a look at TPL files of tiki-wizard_admin.php for example how it should be done and harmonize.

{syntax type="tiki" editor="plain"}
On a Tiki29.x (tested before and after Tiki29.1 release) when I use the Wiki page, Action, Edit icons nothing happens.

On a Tiki Wiki 29, when I try to edit a plugin using the plugin edit icon it doesn't open the dialog.

In the console I see it create a 500.

I see in the PHP error logs:
{CODE()}
[Sun Feb 08 20:34:34.809307 2026] [proxy_fcgi:error] [pid 3852014:tid 140443887073024] [client 127.0.0.1:53564] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function TikiLib::safeFileExistsInPath(), 1 passed in /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Edit/PluginController.php on line 273 and exactly 2 expected in /var/www/vhosts/mydomain.org/httpdocs/lib/tikilib.php:7314\nStack trace:\n#0 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Edit/PluginController.php(273): TikiLib->safeFileExistsInPath()\n#1 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Broker.php(140): Services_Edit_PluginController->action_edit()\n#2 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Broker.php(27): Services_Broker->attemptProcess()\n#3 /var/www/vhosts/mydomain.org/httpdocs/tiki-ajax_services.php(53): Services_Broker->process()\n#4 /var/www/vhosts/mydomain.org/httpdocs/route.php(400): include('...')\n#5 {main}\n thrown in /var/www/vhosts/mydomain.org/httpdocs/lib/tikilib.php on line 7314', referer: https://mydomain.org/Mypage
{CODE}

I checked PluginController.php, safeFileExistsInPath.

The function safeFileExistsInPath() requires two parameters: the file and the directory to check it against. But in PluginController.php, it's only being called with one parameter.

{syntax type="tiki" editor="plain"}
On my multilingual Tikis when I access the control panel I often see;

{CODE()}
You have the following unused indexes:

index_pref_en
index_pref_he

If you don't need them (for debugging), run the following command:

php console.php index:cleanup
{CODE}

False warning or... ?

{syntax type="tiki" editor="plain"}
We have now 2 new switches that are added at the bottom of an item:
* add comment
* notify to

The UI should be improved

{syntax type="tiki" editor="plain"}
To reproduce, on a Tiki30 on a wiki page add a new plugin.

~np~Near the bottom you will see: 0="[object Object]"~/np~

If a package is missing the help/warning information displays a link to the external missing package repository.

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

It is __important to note__ that we have already a similar mechanism when looking to a page (not the admin control panels) that display a message for admins (I hope for admins only ?)

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

---

At http://bsfez-11581-7999.show2.tikiwiki.org/tiki-admin.php?page=fgal&cookietab=6&highlight=feature_docs, enable "Use PDF.js".

It will display an alert (red background):

The first link "Missing tiki package :" with a link to : tiki-admin.php?page=packages

Then "npm-asset/pdfjs-dist-viewer-min" with a link to :https://asset-packagist.org/package/npm-asset/pdfjs-dist-viewer-min

It should display:
"A Tiki package is missing: Install mpdf/mpdf"
"Install mpdf/mpdf" should be a link to : tiki-admin.php?page=packages

1. Tells the user of a problem
2. Explain what is the problem
3. Suggest the user a way to solve the issue
4. Give the user the direction/action to solve the issue

That's the way a missing package should handled, anywhere.

I added "anywhere" because it seems we have different behaviours.
IE: Go to http://bsfez-11581-7999.show2.tikiwiki.org/tiki-admin.php?page=print
For the "PDF from URL" dropdown, select mPDF. The "PDF Orientation" error will show
"Missing tiki package: mpdf/mpdf" with parts with the same link. (not needed)

{file type="gallery" fileId="1771" showicon="y"}

{syntax type="tiki" editor="plain"}
With Element Plus enable, but Element Plus Autocomplete disable.

When editing a Wiki page, using the "wiki link" button on the toolbar you can set a "wiki link" on the page with a title and the page you want to link to.

Before Tiki29, the label contained the selected text for the wiki link and when starting to type in the "Page" field autocompleted and proposed existing Wiki pages.
This is not working anymore on Tiki29, the label stays empty.

{syntax type="tiki" editor="plain"}
On a Tiki 29x (updated today, after Tiki29.1) where I'm using markdown, I create an article and use the sign < in the content. I have other content after the sign. On save, the sign and all the content after it is deleted.

I can't find it on re-editing.

{mediaplayer src="https://dev.tiki.org/dl3234" type="mp4" mediatype="video"}

{syntax type="tiki" editor="plain"}
You can set "0" as a value for the ALTERNATE parameter in a plugin list.

-+{ALTERNATE()}0{ALTERNATE}+-

Won't display anything.

If you use the plugin as counter of things that's a problem.

When adding an URL that is already present in the Directory (not even just in the category), you get a message: "URL already added to the directory. Duplicate site?" - and aren't even allowed to duplicate the site..

When you use re captcha the Privacy Terms panel overlap (right) element of the page.
You can always scroll to see what is under unless you are at the bottom of the page where the footer and bottom_modules elements are under it.

When recaptcha is enable we should add a margin-bottom so it is always possible to see the footer content.

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

{syntax type="tiki" editor="plain"}
On a Tiki29 if one of these are enable
* Element Plus
* Element Plus Autocomplete
* Element Plus Select

When you edit a wiki page you can't select a wiki page using the toolbar button, add a wiki page.

It seems that happens when "Element Plus Select" is disable, NOT "Autocomplete".
The documentation or the tooltips about this should be clear and consistent.

{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"}
It is impossible to delete a wiki page. It doesn't matter whether you go to list wiki pages and select delete from the context menu of that page, or go to orphan pages and select delete from the context menu, or whether you check the checkbox in those to lists and then choose "delete selected".

A dialog pops up that asks whether you really want to delete that page. In this dialog, the page for deletion is correctly stated, so a page HAS been correctly selected.

But after confirmation you always get the error message "no page selected" and "one or more pages should be selected"...

Using Plugin Web Doc Viewer (https://doc.tiki.org/PluginWebDocViewer) I can embed in a Wiki page a PDF from a Tiki file gallery or an external URL (if it end with .PDF from my test) or a Google doc file (documents, spreadsheet, etc) from a Google drive.

Using the plugin Plugin Google Doc (https://doc.tiki.org/PluginGoogleDoc) I can embed a Google doc file (documents, spreadsheet, etc) on a Wiki page.

However I couldn't find a way to embed on a Wiki page a PDF file stored on a Google drive.
It just failed.

{syntax type="tiki" editor="plain"}
On a Tiki23, I can activate the "Revision approval" feature for Wiki Pages at -+tiki-admin.php?page=wiki#contentadmin_wiki-3+-
Admin => Wiki page => Flagged Revision => Revision approval

This function then requires the user to select the categories that will be governed by this feature using the field "Revision approval categories".

This is workable if you have a few categories (like 10 or 20). However, if you have many categories and subcategories, it becomes very complicated and hard to understand how to manage them.

To add to the confusion, there is an "invisible" limit on the number of categories that will be displayed. By default, you will see only 50 category results because of the setting:
Look&Feel => Navigation => Limits => Maximum number of records in listings: 50

It is very hard to understand why you don't see all the categories if you are not a super power user.

Update: The img plugin insert action will automatically select the mediaplayer plugin if a video is detected. (not well documented)
---
Still:
It is possible using the plugins img or files to select or upload directly a file from the Tiki File Galleries. It would be nice in 2023 to have also this select functionality in the media player plugins.

Using the wiki plugins mediaplayer, webdocviewer or googleDoc we can display PDF and documents from many sources.
Almost everything BUT not PDF document stored on a google drive.

We need to add an option in one of our plugins to allow user to do so.