Category: Regression

{syntax type="tiki" editor="plain"}
If 'Display comments form by default' is checked, the comment button doesn't react. Comments works but you'll have to right click on the comment button and 'open in new window'.

{syntax type="tiki" editor="plain"}
Tiki 25 introduced an optional limit on comment indentation, so that replies to comments of level 5 or above are not more indented than their parents (for example, a reply to a reply to a reply to a reply to a reply to a reply to a root comment would only have 5 levels of indentation). [https://gitlab.com/tikiwiki/tiki/-/commit/4768f7a6b98eac7d83e51fef37ad8f09ed2c979d#bd7d97780b721291f95bdf13e9db86a1861f5bb1_26_26|In order to keep indicating threading (which is a comment's parent) even in these comments which reach the indentation limit, an excerpt of that parent's text was added].

Although the initial implementation was incorrect, it got much worse in Tiki 27. While the excerpt used to be the first 15 characters of the markup (source), [https://gitlab.com/tikiwiki/tiki/-/commit/0ff12dc0d1519e5b916ddf6bdbe971493073f211|it has now become the first 15 characters of the output (HTML)] (reportedly to fix a bug for Markdown).

Unfortunately, such a truncation is completely unsafe, and visibly breaks most of the time (although this may depend on the paragraph parsing preferences). Although this can cause all sorts of broken HTML and resulting weirdness, the typical effect is that truncation happens inside a paragraph, leaving a missing </p> tag, which causes browsers to ignore the closing </span> tag, effectively treating the reply itself as a part of the parent comment since the DOM's span contains too much.

Moreover, [https://gitlab.com/tikiwiki/tiki/-/merge_requests/6435|in November there was a puzzling attempt to fix this which moved the problem], making this way worse for Tiki 27.1. Now, instead of just breaking rare (highly nested) replies:
* level 1 comments display an irrelevant excerpt
* level 1 comments are therefore frequently broken
* level 5+ comments are missing an excerpt (but are therefore no longer badly broken).

Screenshot taken from https://dev.tiki.org/item7838-Installer-not-ready-for-PHP-7-4-in-Tiki-18-x

Reproduced in trunk and 16.x:

Inability to post a comment-Issue (due to highlighter)
Reproduced in trunk in:
* Login as admin in http://xavi-9794-3214.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

And in 16.x in:
http://xavi-9794-6132.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

It's currently also affecting https://dev.tiki.org bug tracker comments. {sign user="xavi" datetime="2016-10-14T10:17:35+00:00"}

When codemirror highlighter is on (desired behavior in some setups, and the one produced by the new profile "Bug_Tracker_15" by default) when you click at submit your comment, you get: "__content is empty__", so you need to disable the highlighting before you can safely submit your comment.

This feature works as expected in Tiki15.

Hello,

I replied to a comment using this link : https://dev.tiki.org/item8238-Wiki-page-Markdown-Carriage-return-are-not-displayed#mentioned-Bsfez-section-1

After saving the comment the author is Jonny instead of me.

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

Some things I remember about it;
* The page open all the day (I visited in the morning and the event occurred in the afternoon)
* I received a notification in my mail that my username was mentioned in a comment
* I refreshed the page to see the comment __OR__ I clicked the link from the notification https://dev.tiki.org/item8238-Wiki-page-Markdown-Carriage-return-are-not-displayed#mentioned-Bsfez-section-1
* I typed my reply and saved

On a fresh Tiki 24.0 install, I installed the Blogs profile and on the lowest part of the ''Members Home'' page, I get errors with a helpful message about installing the missing npm-asset/fullcalendar-scheduler package.

When I follow the link to -+ tiki-admin.php?page=packages +-, Tiki complains that temp/composer.phar is missing. It suggests I install composer in the ''Diagnose'' tab and that fails also.
* No reason is provided by Tiki, which is bad because users have no clue what to try next
* Nothing in apache error logs
* Tiki PHP error log at the page bottom does provide a hint:
^ERROR (E_WARNING): file_exists(): open_basedir restriction in effect. File(/usr/local/sbin/php) is not within the allowed path(s): (xxxxxxx)
At line 231 in lib/core/Tiki/Package/ComposerCli.php^

We should have a better, more secure way of installing composer.
If the above is not possible, we should have better feedback and suggest ways around the issue so it does not look like a Tiki bug.

Installing composer on the command line works, but Tiki does not mention this or how to do it.

Composer packages can't be installed successfully through the web control panel in Tiki 23. Reproduced in dev.t.o, and also in two other servers.
In dev.t.o, the triangle icon shows up inndicating that the install failed.
In the other 2 servers, I saw a message indicating that composer.lock file was missing (on brand new tiki23 git installs, and therefore those packages could not be installed.

In all cases, running in the console (server side) the command -+composer update+- as root fixed the issue.

HTH

((doc:Admin Wizard|Configuration wizard)) doesn't seem to save changed prefs. I've been recently warned about a new tiki admin unable to enable structures, that he needed for a knowledge base with tiki.

He was using the configuration wizard, going to wiki, tick "Structures", click at "Save and Continue", but when going back through the button "Back", or going to the control panel Wiki and review structures there, they where not enabled indeed.

I was able to reproduce this bug in recents (git based) Tiki 22, Tiki 23 and Tiki master. However, the feature seems to work as expected in Tiki 21 LTS.

It has been reproduced in branch master in a show instance:
Log in as admin here:
http://xavi-9794-7941.show2.tikiwiki.org/
u: admin
p: 12345

Visit:
http://xavi-9794-7941.show2.tikiwiki.org/tiki-wizard_admin.php?&stepNr=8&url=tiki-index.php

Click at "Structures" to (attempt to) enable teh feature.
Click as "Save and continue"
Click at "Back", you will that the structures feature is not enabled indeed yet.

You can confirm so visiting the Wiki control panel, at the section about Structures, here:
http://xavi-9794-7941.show2.tikiwiki.org/tiki-admin.php?page=wiki#contentadmin_wiki-2

I have "Require confirmation of an action if a possible CSRF is detected" set on tiki-admin.php?page=security. When I get the warning "Possible cross-site request forgery (CSRF, or "sea surfing") detected. Operation blocked.", and I click the "Click here to confirm your action" button, the same warning page redisplays instead of refreshing to the page where the admin action was made. This repeats as long as I keep clicking.

But the admin change does get made. If I input the admin page URL or go back in browser history to the admin page, I can see the change did take effect.

This is on my local wamp installation, so I'll need to make a show instance unless other people can reproduce this bug.

{syntax type="tiki" editor="plain"}
The registration email seems to give boxed char when mail templates are in french.

I had to add utf8_encode()
to LINE 2727 of lib/userslib.php
$mail_data = utf8_encode($smarty->fetch("mail/$mailTemplate.tpl"));
in order to correct the text display problem.


But when I debug with
$mail_data = mb_detect_encoding($smarty->fetch("mail/$mailTemplate.tpl"));

It return the tpl as already in UTF-8, but I had to utf-8 it again to correct it, can someone look into this?

Recently (since 21.x i think) the command -+php console.php c:c+- clears the cache files but then recreates several but using the current user (so -+root+- if using sudo to repair a previous issue).

Then when using the browser to clear all caches we get these sort of errors:
{CODE()} Cache file temp/templates_c/en_basic^c0a74c88a95913ac40aae6373020e7a6b2c0f1f9_0.file.cookie_consent.tpl.php is not writable
Error
Cache file temp/cache/1a11dae0a46d862cd81ddc7650f62cb8 is not writable
Error
Cache file temp/cache/container.php is not writable
Error
Cache file temp/cache/cd13e8c5df46647a6182a0cc858c8ed9 is not writable
{CODE}

Solution: console clear cache should not regenerate any cache files.

{CODE()}
php console.php i:r -p
[2023-06-22 09:51] Started rebuilding index...

Unified search
--------------

Engine: MySQL, version 10.5.19-MariaDB-0+deb11u2
Implicit conversion from float 5066.792011260986 to int loses precision on line 68 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
< 1 sec/< 1 sec [>---------------------------] -- Rebuilding...Implicit conversion from float 13.790607452392578 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
< 1 sec/< 1 sec [>---------------------------] -- Processing file gallery documentsImplicit conversion from float 13.790607452392578 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 13.790607452392578 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 13.790607452392578 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 15.047073364257812 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
Implicit conversion from float 2.9579798380533853 to int loses precision on line 332 of /home/stockgallery/public_html/vendor_bundled/vendor/symfony/console/Helper/ProgressBar.php
{CODE}

The index complete anyway.

Since recent console.php refactoring the --site parameter is no longer respected in (for instance) the database:update command.

When running -+php console.php --site=example.com database:update+- the code in -+\Installer::buildPatchList+- builds the patch list from the default db/local.php database, not the db/example.com/local.php.

---

I think related to this, even once i've done the database:update in the browser, i cannot rebuild the index, when i do:
-+php console.php --site=example.com index:rebuild+-
i get {sign user="jonnybradley" datetime="2020-03-05T11:11:59+00:00"}
{QUOTE()}Command not available at this stage.
The database needs to be updated. Solved by: php console.php database:update{QUOTE}

---
I think this commit was the source of the regression and i'm afraid i can't fix it {gitlab id="2ee93280"} {sign user="jonnybradley" datetime="2020-03-05T11:29:44+00:00"}

On a local setup and on Tiki25 I used hundreds of times the console with this command:

{CODE()}php console.php i:r -p --log{CODE}

Since a few days (I updated to the last bread) I have an error.
I believe extra-checks have been added or something has changed in the console process (because my configuration didn't changed) and it is causing all the process to fail if the log file cannot be written:

^
php console.php i:r -p --log
sh: tesseract: command not found
[2023-04-30 02:19] Started rebuilding index...
Logging to file(s):

* ../tmp/Search_Indexer_mysql_xxxxx_tiki25_console.log

Unified search
--------------

Engine: MySQL, version 5.7.39
< 1 sec/< 1 sec [>---------------------------] -- Rebuilding...sh: tesseract: command not found
1 sec/1 sec [============================] -- Rebuilding preferences indexerror: The search index could not be rebuilt.
__"../tmp/Search_Indexer_mysql_xxxx_tiki25_console.log" cannot be opened with mode "w"__


The search index could not be rebuilt. "../tmp/Search_Indexer_mysql_xxxx_tiki25_console.log" cannot be opened with mode "w"
^

I have re-re-run the setup.sh permissions setup.

Removing the "--log" allow the index:rebuilt to complete.

This is may be totally legit and true however, it should not stop the process. "index:rebuild" is critical today to keep freshness of data and correct Tiki behavior.
I suggest a warning to be displayed, but the process to keep on.

Tested in Tiki20x and Tiki21x.
Using php console.php files:check throws a notice on wiki attachment:

CODE()}
== Wiki Attachments ==
Configured to stores files in Database
Files in DB: 0
Files on Disk: 0
No Issues found

PHP Notice: Undefined index: f_use_db in /var/www/virtual/elyseavenue-paris15.fr/html/lib/core/Tiki/Files/CheckAttachmentGallery.php on line 105
PHP Notice: Undefined index: f_use_dir in /var/www/virtual/elyseavenue-paris15.fr/html/lib/core/Tiki/Files/CheckAttachmentGallery.php on line 116
{CODE}

I tested with Tiki19 I think (may be earlier) and it may be caused by PHP version change.

This is a regression introduced at some point I don't know exactly when) between Tiki6 or tiki9 and Tiki12 at least, and confirmed to be a regression still for Tiki14.

Content of text area fields can not be shown as parsed any more when displayed through PluginTrackerList, but only when displayed through the tracker interface itself. Ideally, there should be a param in plugin trackerlist to allow whoever needs that content not to be parsed in their sites. this currently breaks the display of comments provided to students on their wiki based reports.

This will hopefully be demonstrated in a tiki instance in the following days (probably after a ad-hoc profile is created to help reproducing this setup, linked to Pretty Trackers, etc, even if the issue is reproduced aside of the pretty trackers, just with standard display of the contents of that text-area field)

See the attachment

See https://dev.tiki.org/Git-and-SVN-combined-workflow for example

Convene plugin missplaces the counts in columns after the winning choice. See it reproduced in the screenshot below:

{img fileId="1093" thumb="box" width="600"}

In
https://tiki.org/Roundtable+Meeting+2016+09

After the count with the more votes (7, at the time of this writing), and the icon with the checkbox-like icon to indicate that this was the winning choice (Thu 15 Sep 2016 15:00 CEST), there is a button box in orange in the screenshot that should show a calendar icon, and that button allows to send that date to the pre-defined tiki calendar.
https://tiki.org/tiki-calendar_edit_item.php?todate=1473944400&calendarId=7

But no calendar icon is shown, and the count of votes for the next date (column in the table) is shown there instead ("3" instead of the calendar icon), and the next counts are also one column before where they should be.

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

The cookie consent form doesn't work properly in MS Edge - a modal saying "Sorry, cookie consent required" appears when you click "Continue" and reappears immediately after clicking "OK", so it's impossible to proceed at the site (dev.tiki.org for example). Edge uses chromium - I didn't check other chromium-based browsers.

Go on "List Wiki page".
Select any page, copy it (duplicate page).
Enter any name to save.

Once redirected to the new page it show a warning : You don’t have permission to edit tags.
Tested on a new Tiki without tags feature activated and tested on nextdev.

((RoadMap)) shows "Fatal error: Call to undefined method TikiDate::getDate() in /home/tiki/public_html/lib/wiki-plugins/wikiplugin_countdown.php on line 60". This happens when using the COUNTDOWN plugin on PHP 5.1 and later due to a missing definition of getDate() in the lib/tikidate-php5.php TikiDate. The old TikiDate (lib/tikidate-pear-date.php) declared that function (via inheritance).

This was introduced in r14129 and widely exposed in r20047 on lib/tikidate.php.

When I set my country in the user preferences dropdown and save, later on a subsequent visit to my preferences page it gets reset back to "Other" as if I did not select it before...

{syntax type="tiki" editor="plain"}
Hello,

On the user forum, when I send a new thread I have always the "crash" message :

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 1491648 bytes) in /var/www/tikiwiki.org/setup_smarty.php on line 172

I yet notice this but I don't received any answer.

This is generally caused by a too low allocated memory for php.

The message is nevertheless sent but I (we) need to reload it.

Best regards

Trebly