Category: Bug

On Firefox and Safari OSX on the congratulation install page I set the slideshow plugin it worked just fine.

Then I add the SlideShowSlide plugin at some point it stopped to work.
Sometimes I only see a black background (the default slide) and the slideshow cog icon.
Sometimes all the slides are displayed together and the setting (cogs) menu ne s'ouvre pas.
And more...

I updated the Tiki, re-run setup.sh, cleared Tiki cache, restart the browser, cleared the history (cookies), force refresh, use new tab, use incognito tab, etc.
I create a new page and copy a different slideshow working on the show instance.

Not working anymore.

I rolled-back and recreated a new page with a new slideshow on the 2 browsers I was experimenting the page. Nothing work anymore.

If I open a third browser that never saw the page it is working back. ?

SlideShowSlide is not working and at some point it broke reveal.js.
Something is stored/stuck somewhere and it forbid me to use the slideshow plugin.

In the console I can see the following.
{CODE()}
Uncaught InternalError: too much recursion
dispatchEvent https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:1995
layout https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:2333
onWindowResize https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:5681
dispatchEvent https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:1995
layout https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:2333
onWindowResize https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:5681
dispatchEvent https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:1995
layout https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:2333
onWindowResize https://www.bernardsfez.com/vendor_bundled/vendor/npm-asset/reveal.js/js/reveal.js:5681
{CODE}

I updated, re-run setup.sh, cleared Tiki cache, restart the browser, cleared the history (cookies)...
Nothing.

Instance coming...

Instance is coming

Using the Tracker properties I can define several fields that will be displayed in a popover when hovering over the title of a trackeritem.

This work also when using the plugin List, setting the ouput table column parameter to raw {CODE()}mode="raw"{CODE} and adding to the format of the field {CODE()}format="trackerrender"{CODE}.

With the same settings when using a wiki plugin customSearch that doesn't work.
The code is there but hovering over the title doesn't display the popup.

See the video screenshot
{mediaplayer src="display2130"}

See the instance.

Currently the Wishlist reports just 2 bug reports (TWO) that are open. Very hard to believe, unless some closed thousands of bug reports...?!

Or has the Wishlist lost contact to some external data storage?

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

I created a database from the installer (first time) with an ===existing user=== and I got a feedback that a ===user was created===.



To reproduce:
Install a new Tiki22
On the database stage, fill the fields, use an existing database user, add admin db credential and create a new database.

This Page: https://tiki.org/SingleSignOn contains a link to LDAP in the "category links" but it links to https://tiki.org/19 and not to https://tiki.org/LDAP. The link is generated so I cant change it and it mostlikely affects other areas too.

{CODE(caption="WikiPlugin" theme="default")}{CATEGORY(id=>9,sub=>true)}
{CATEGORY}{CODE}

On the page tiki-user_information.php -> check button "Send Me a message" - why contain word "Me" ?
When I select __other__ user profile and use user information page, I will send the message to HIM (not for Me).
I propose to change string to "''Send a message''".

{syntax type="tiki" editor="plain"}
I installed a Tiki 30 from git using an existing DB to be upgraded.

On DB validation I had a white screen and this is the error log:

{CODE()}
[23-May-2026 06:17:12 UTC] PHP Warning: Undefined array key "feature_fixed_width" in /blabla.bsfez.com_tiki30/installer/schema/20260312_change_fixed_width_default_tiki.php on line 18
[23-May-2026 06:17:12 UTC] PHP Fatal error: Uncaught Exception: Found 1 unsupported mail queue entries (serialized in old Laminas/Zend format). These entries cannot be processed. WARNING: These entries will be DELETED if you proceed with --auto-register, and queued email data will be lost. To delete them and continue, rerun:<info> php console.php database:update --auto-register</info> in /blabla.bsfez.com_tiki30/installer/schema/20260430_remove_unsupported_mail_queue_entries_tiki.php:42
Stack trace:
#0 /blabla.bsfez.com_tiki30/installer/Installer.php(192): upgrade_20260430_remove_unsupported_mail_queue_entries_tiki(Object(Tiki\Installer\Installer))
#1 /blabla.bsfez.com_tiki30/installer/Installer.php(143): Tiki\Installer\Installer->installPatch('20260430_remove...')
#2 /blabla.bsfez.com_tiki30/installer/tiki-installer.php(562): Tiki\Installer\Installer->update()
#3 /blabla.bsfez.com_tiki30/tiki-install.php(132): include_once('/Users/bernards...')
#4 {main}
thrown in /blabla.bsfez.com_tiki30/installer/schema/20260430_remove_unsupported_mail_queue_entries_tiki.php on line 42
xxxxx htdocs %
{CODE}

Profiles using -+[[ value1, value2, value3 ]+- syntax for array values for preferences now cause a fatal error and usually WSoD.

In a Tiki 21.4 I get a WSOD (white screen of death / blank page) when I save a newly created page.

The page is created anyway and usable. The WSOD disappears when the browser is sent one page back or the site/page is loaded manually.

The bug __only__ occurs while __saving__ a newly created page for the __first time__.

After editing a previously existing wiki page, there is no WSOD after saving.

I did not yet test the behaviour for other versions, but I will add versions accordingly.

Tested in show instances:

Tiki 23.1vcs
http://bsfez-11581-7912.show2.tikiwiki.org
success - could not reproduce

Tiki 21.5vcs
http://torsten-11143-7928.show2.tikiwiki.org
success - could not reproduce

{syntax type="tiki" editor="plain"}
Please see 2 images
# https://dev.tiki.org/item8645
# https://dev.tiki.org/tiki-tracker_view_history.php?itemId=8645

When using WYSIWYG in HTML mode (wysiwyg_htmltowiki disabled), the WYSIWYG help available by clicking the blue question mark at the right assumes that the wysiwyg_wiki_parsed preference is enabled:
# The first tab claims that "Wiki plugins can be used and edited in WYSIWYG mode" since r30245.
# The second tab offers adding plugin calls, as if they would be interpreted.

In fact, it is known that the implementation "is not designed to work best" when wysiwyg_wiki_parsed is disabled (even though [https://tiki.org/tiki-view_forum_thread.php?comments_parentId=67421|the idea behind wysiwyg_wiki_parsed is unrelated to WYSIWYG]). The first tab contains:
{QUOTE()}
This new implementation is designed to work best with some site preferences set in a certain way. These can all be found on the WYSIWYG admin page. A profile to set these up correctly can be found on profiles.tiki.org which can be applied using the profiles admin page.
{QUOTE}
The WYSIWYG_6x profile enables wysiwyg_wiki_parsed.

The WYSIWYG editor removes some syntax from the page. Such as "~126~~110~~112~~126~...~126~~47~~110~~112~~126~". It also converts characters, which are specified with the "~NNN~" syntax to ordinary characters.

To reproduce:

- Create a new page with the non-WYSIWYG editor.
- Enter "~126~~110~~112~~126~! XX~126~~47~~110~~112~~126~"
- Save the page. It shows up as intended: "! XX"
- Open the page and switch to the WYSIWYG editor.
- Click on "Save". Now the "XX" shows up as a heading.
- Open the page again and switch to the non-WYSIWYG editor. The "~126~~110~~112~~126~" and "~126~~47~~110~~112~~126~" parts have vanished.

With quoted characters, such as "~126~033~126~" it's similar. They get converted to non-quoted characters when the page is opened in the WYSIWYG editor and are saved that way when the page is saved.

This bug makes the WYSIWYG editor next to unusable.

When you double click a link in the WYSIWYG editor the dialog says square bracket "mailto" links are wiki pages (with no page filled in) and wiki page links are external ones.

{syntax type="tiki" editor="plain"}
I upgraded an instance from version 27 to 29.1. When I open the WYSIWYG editor, the buttons that are supposed to open dialogs don't work. The following error is displayed in the console in the browser:
createCustomButton.js:9 Uncaught TypeError: Cannot read properties of undefined (reading 'call')
at HTMLButtonElement.click (createCustomButton.js:9:52)
at HTMLButtonElement.dispatch (jquery.js:5145:27)
at HTMLButtonElement.<anonymous> (jquery.js:4949:28)

The User favorites feature (enabled by preference user_favorites and [https://doc.tiki.org/Favorites|documented]) allows users to define favorites, but does not let them view the favorites they have defined.

A controller similar tiki tiki-user_watches.php could be added so that users can actually use the feature.

Hi

When using the ~np~{maketoc}~/np~ plugin, an ampersand in a heading is rendered as "~np~&amp;~/np~" in the generated table of contents, under certain circumstances.

This will exhibit the faulty behaviour:
~np~! Foo&Bar~/np~

Whereas this won't (notice the white space):
~np~! Foo & Bar~/np~

When choosing to "edit" an "Item Link" type tracker field, saving will always convert the Item Link type field to a "Relations" tracker field.

The reason for this can be seen - in the "Advanced" part of the edit popup, the only option in the "Field Type" dropdown is "Relations".

I realise that an Item link may just be a kind of relation in the "backend", however the interface for both configuring and using an item link is much better than the relations field, and any paramaters entered in to the item link do not trafer to the new "relations" field.

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

Tiki 18.01 running on Ubuntu 16.04 LTS

Getting errors when running composer install:
{CODE()} - Installing jcbrand/converse.js (v4.2.0): Loading from cache
- Applying patches for jcbrand/converse.js
../installer/composer-patches/jcbrand-conversejs_remove-native-javascript-for-bootstrap.patch (Remove native javascript for bootstrap)
Could not apply patch! Skipping. The error was: Cannot apply patch ../installer/composer-patches/jcbrand-conversejs_remove-native-javascript-for-bootstrap.patch
{CODE}

When you define workspace areas, there is no mechanism to delete them. They can be edited, but not deleted.

This can be viewed both as a bug report or a feature request:

The logic for article images breaks standard Tiki admin logic in that you cannot (!) use images from the file galleries. You have to upload them separately into where ever they get stored (unknown), stripping users of the ability to centralize image storage and scaling images by demand. This also means that the user must use a local image manipulation tool for scaling...

This is true for both standard images (by topic) and for user images!

{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__.

After the creation of an article, it can be observed that the number of readings of this article does not change, even when changing users or the access permissions of a user. The number always remains at __(0 Reads)__.
I was using Chrome Version 75.0 and Opera Version:60.0