Category: 29.x

{syntax type="tiki" editor="plain"}
I updated recently a Tiki 29.x (14/02/2026) and since then on creation of an item in a tracker I have this error:

^
Error
Field _sort does not exist in the current index. If this is a tracker field, the proper syntax is tracker_field__sort.
^

It comes from using a relations tracker field with a filter using this "_sort" parameter.
-+type=trackeritem&tracker_id=2&_sort=tracker_field_actionsDate_desc+-

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


The code is at : templates/trackerinput/relation.tpl

{CODE()}
{object_selector_multi _name=$field.ins_id|cat:'[objects]' _value=$data.existing _filter=$data.filter _format=$data.format _parent=$data.parent _parentkey=$data.parentkey _sort=$data.sort}
{CODE}

{syntax type="tiki" editor="plain"}
I upgraded my site to 29.0 and I get an Apache2 500 Internal Server Error when accessing tiki-admin-modules.php
From error.log
[Wed Jan 28 22:09:54.193144 2026] [php:error] [pid 4623] [client 192.168.1.5:40646] PHP Fatal error: Uncaught TypeError: Unsupported operand types: string + int in /var/www/html/nmhv5-tiki29.0/tiki-admin_modules.php:638\nStack trace:\n#0 {main}\n thrown in /var/www/html/nmhv5-tiki29.0/tiki-admin_modules.php on line 638, referer: http://192.168.1.10/nmhv5-tiki29.0/tiki-admin.php?page=module

the offending line in the code (638) is:

$smarty->assign('theme_navbar_fixed_topbar_offset', $prefs["theme_navbar_fixed_topbar_offset"] + 35);

After I remove the integer, the website works again.

I'm unable to determine what in my configuration triggers this error, it's not present in the default config.

{syntax type="tiki" editor="plain"}
https://ibb.co/tTWCXJmM

{syntax type="tiki" editor="plain"}
Admin warning about the scheduler (that didn't ran) shouldn't be displayed when the scheduler is not used.

{syntax type="tiki" editor="plain"}
Popup occasionally remains visible when hovering over tracker items, until the user refreshes the page or hovers again over the same item.

{syntax type="tiki" editor="plain"}
On different area of a Tiki29x updated after the last 29.1 release images have a height of 2px or width of 2px.

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

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

{syntax type="tiki" editor="plain"}
If Tiki is going to have System Menu item icons by default in new installations, probably all menu items should have one. Why only "Categories" in the system menu dropdown?

The same items in the admin pages aside menu have icons, so it should be just a matter of adding them to the system menu. Note: be sure these are added in a vendor-neutral way so that if the admin switches from Font Awesome to Bootstrap icons (or another icon set), they will still display.

{syntax type="tiki" editor="plain"}
The Manticore server doesn't find words of length 2, when used by Tiki. It looks very much like only words of length 3 (or even 4) are indexed.

This depends on the configuration used when the __tables are created__ inside of Manticore. It looks like Tiki specifies the "min_word_len" setting to be 3 (or even 4) when creating the "tiki_main_..." table inside Manticore. The SQL command in question is "CREATE TABLE tiki_main_... (...) min_word_len='3';"

I've searched the Tiki settings in the "Search" Control panel and couldn't find a setting for the minimum word length of Manticore.

The minimum __can't__ be configured in manticore.conf, because it is set (so it seems) at table creation time, which is the time when Tiki rebuilds the search index.

This isn't about stopwords. I've tried with 2-letter-word which aren't.

When performing a search which only includes one 2-letter-word, I get the following error message:
{INDENT()}Malformed search query: SQLSTATE[42000]: Syntax error or access violation: 1064 table tiki_main_69a052d856213: P08: syntax error, unexpected ')' near ' ) | (@title )'{INDENT}

{syntax type="tiki" editor="plain"}
When tiki_p_admin_trackers is granted at the per-tracker level (tracker-specific permission), the REST API returns 403.

The same permission granted at the global level works correctly.

Steps to reproduce:
Create a user and generate an API token
Assign tiki_p_admin_trackers to the user's group only for tracker ID 1 (per-tracker permission)
Call:

curl -X 'GET' \
'https://wiki.is-il.org.il/api/trackers/1' \
-H 'accept: application/json' \
-H 'Authorization: Bearer TOKEN_HERE'

Response: {"code":403,"errortitle":"Reserved for tracker administrators"}

If you set tiki_p_admin_trackers as a global permission instead of per-tracker for the same user group and you use the same tracker it work as expected.
{"trackerId":1,"offset":-1,"maxRecords":-1,"result":[{"itemId":4...

{syntax type="tiki" editor="plain"}
As seen in the video attached to this item. (demo tiki)
The own image article is lost if the classification (topic or type) of an article is changed.

To reproduce;
In the Tiki Articles I create an article and set his own image.
I save, the image is displayed.

I edit the article change the topic or the type of the article and save.
The image is gone.
It was working fine, __this is a regression on Tiki 29__.

{syntax type="tiki" editor="plain"}
I just sent a newsletter to 26 users using Tiki29.

While sending I received messages that the Newsletter was succefully sent.
One row per email + a counter so if I believe Tiki feedback.
26 emails received 26 newsletter.

BUT one the address was one I control at Gmail and I didn't received the newsletter.
It was not in the spam.
I didn't received an error on my sending email.

That a terrible failure because now I don't if ANY of my newsletter was really sent and I have no real course of action.
I'm against sending the newsletter several times as this is not professional + can lead to blacklist my email.

Feedback tool MUST be reliable.

{syntax type="tiki" editor="plain"}
On Tiki29x from update I have several trackers.
A tracker field text is set as the tracker item title.
This work just fine.

On this tiki multilingual is enable and I use en and fr, so later I enabled the multilingual option of the text field and I added a french value for the title field. Now I see the database value for the trackeritem and not one title based on the language selected:

{CODE()}{"en":"The Wiki syntax in Tiki","fr":"La syntaxe Wiki dans Tiki"}{CODE}

{syntax type="tiki" editor="plain"}
The number count in a password is rated using this piece of code in lib/tiki-js.js:

// Numbers
var nNumberCount = countContain(strPassword, m_strNumber);
// -- 1 number
if (nNumberCount == 1)
{
nScore += 10;
}
// -- 3 or more numbers
if (nNumberCount >= 3)
{
nScore += 20;
}

This causes a password with 1 number to get 10 points extra, a password with 2 numbers extra points, and a password with 3 or more numbers 20 extra points.

EDIT @joel.magene 2026/06/02:
Current master still miscalculates password number scoring, but differently from the original report.

In lib/tiki-js.js, the current fallback branch gives +10 points when nNumberCount is less than 3, including when it is 0. This means passwords with no digits are overrated.

Expected:
0 digits = +0
1-2 digits = +10
3+ digits = +20

Fix: only apply the +10 fallback when nNumberCount > 0.

{syntax type="tiki" editor="plain"}
When I create a button using Tiki29 several parameters (not all) are duplicated in the plugin syntax.

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

{syntax type="tiki" editor="plain"}
When Full WYSIWYG editor is activated we cannot create or edit wiki pages after upgrading to 29.1 from 27.5.

{syntax type="tiki" editor="plain"}
At tiki-admin.php?page=login admin can set "CAPTCHA questions and answers".

A question with a single answer.
If I use -+1,3,5,7,?= :9+- it will work.

If I use a text string like -+What is the capital of France ? :Paris+- it won't work as it was previously.

{syntax type="tiki" editor="plain"}
Since Tiki29 we have 4 switches on the cookies consent dialog:
* essential
* analytics
* marketing
* functional

If the usage for the "essential" cookies is clear and leave no choice, the other switches usages, except for their name, are very unclear to me. The tooltip doesn't add any useful information to help to understand more than the name of the switch. If this switches exist and are displayed, the admin should be able to find in the control panels what allow or enable them to be displayed.

Also, it seems they are displayed by default, no matter what has set the admin in his Tiki site.
In my use case I didn't set anything brand new Tiki. No analytics or marketing and the cookies consent for this Tiki shouldn't display anything about analytics and marketing. Not only it is not necessary but it can harm the image of a website where this tools are excluded.

Nothing also in the doc: https://doc.tiki.org/Tiki29

---

Additionally, the reliability of Analytics and Marketing seems to be = 0
I have Matomo tracking code in my Look&Feel -> Customization fields and they work even if the cookie Analytic switch is kept OFF.

{syntax type="tiki" editor="plain"}
When editing a Wiki Page (properties) or an Article (classification), if you use the Tiki tags (freetags) you will see a "Tags" field with the list of the most popular or last used tags.

Normally when you click on a tag, it is added to the field.
This is not working anymore.

{syntax type="tiki" editor="plain"}
Tiki.org, just updated to branch 29, is now also showing the cookie message and dark backdrop on every page load like dev.t.o is showing, not for very long but still this is an unacceptable visual glitch IMO. This pops up even if you have accepted cookies.

{syntax type="tiki" editor="plain"}
Recently at dev.tiki.org, the cookie consent form displays on every page load, even though I have consented to the default and selected "save preference". The form only displays for a few seconds but it shouldn't show at all for a user who has consented to cookies.

{syntax type="tiki" editor="plain"}
On my Tiki29.x constantly updated I can see a commit that was made to show the code to insert a file on a wiki page after the upload. It was broken and fixed recently.

At https://29x.demo.tiki.org/tiki-upload_file.php?galleryId=1 the fix is not displayed.

I also checked the git information module that says this Tiki was updated today.

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

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

{syntax type="tiki" editor="plain"}
I added this ticket as feature request as in reality it could have been considered as a sort of regression.

Before Tiki29 when you were uploading a file or several, you could see the success message __and the fileID.__
This allowed the user to grab that ID and use the file id anywhere (on a wiki page for exemple) right away.

Since Tiki29, with a very nice improvement on the interface, after the upload the user can see the download was successful but the fileID is not displayed anymore. It forces the user to return to browse the file gallery, to find the one or the several files he uploaded and to grab the fileID.

See: https://ibb.co/Kpszss3L

It would be nice to have it back, avoiding these extra steps and time.

Update: The issue happen when you upload a single file (in the modal) and not when you upload several files.

{syntax type="tiki" editor="plain"}
Since Tiki29 we have (for those where it work ;-) ) icons for each menu items.

This is nice and ok on the system menu where we have space around the menu items.
When you deploy a sub-menu it really start to be a lot of things in front of the eyes.

Overall the actuel implementation (not collapsable see related item) doesn't add a lot for the user experience.
By that I mean the following and this is my opinion (wearing glasses 🤓);

1. Does it make easier to find the right item the user is looking for in System Menu (one of the goal of having an icon instead of text) on desktop:
* Discutable, but let's say it improve a bit for the System menu so a little +.

2. Does it make easier to find the right item the user is looking for in the Settings Menu on desktop:
* Not really, the menu look really crowded without enough spacing and adding icons just make it harder to read.

3. Does it make easier to find the right item the user is looking for in other features sub-menu items on desktop:
* Not really, these are 3 to 8 menu-items adding icons just make it harder to read.

4. On Mobile...I could not test at https://29x.demo.tiki.org/tiki-index.php the menu is broken on mobile.

5. Does this help reclaiming space (another purpose of having icons is to display a little understanble visual small element instead of text): No, the collapsable option has been removed from the UAB. (😳)

6. Does this help with translations (another purpose of having icons is to display a little understanble visual small element instead of text): Yes icons help in a certain way. I'm not convinced as so far I still need to read the text to know where witll lead my clicking on a link.

At this point, where it is just nice to have icons, I think that having icons in ALL the menus should be optional... as it should have been in the first place.

See: https://ibb.co/Ps8YBhtb, https://ibb.co/4w5STNJW

{syntax type="tiki" editor="plain"}
After upgrade to 27.5 (I have not observer this in 27.2), edits made to Wiki Plugins on any given Wiki Page cause PHP errors related to missing language definition.
# Assigned language of the Wiki Page is removed (causing a PHP error, and "No language assigned" message)
# Page Description is removed
The above can be reverted using History, but it's practically impossible to edit Plugins without causing data loss (description).
User is forced to manually re-assign language (which fixes PHP errors), and insert new Page Description.
Tested on fresh install of 27.5

PHP errors shown on affected page are related to translated-lang.tpl (missing language)
^<?php echo $_smarty_tpl->getSmarty()->getModifierCallback('escape')($_smarty_tpl->getValue('trads')[0]['langName']);?>
(<?php echo $_smarty_tpl->getSmarty()->getModifierCallback('escape')($_smarty_tpl->getValue('trads')[0]['lang']);?>^

{syntax type="tiki" editor="plain"}
When I click the emoji icon on the toolbar in master, nothing happens.