Category: Regression

When trying to create a new group you just get a "working" message and a spinning gear wheel.
The create button does not illuminate. I left this running for several hours on one occasion.
For existing groups the same thing happens if you try to change properties / setting such as adding a homepage etc.
I did find that on one attempt out of about 20 i was able to add one group but it has not worked since.
I have since found that the function works most of the time if you clear the tiki cache files immediately before the attempt.
Sorry i can't work out how to find or work the show bug function

{syntax type="markdown" editor="plain"}
If I create a category with default text editing setting all is fine.

If I enable Markdown and create a category the name and the description will display the markdown syntax that will cause cascading problem as the browser tab may display this as the tab title.

Editing in the db and removing the content fixes the issue.

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

If you add a colon ":" in a category name it will return a 500 and broke the Tiki.
IE : "Archive : Pouf"

See the instance where I tried it : http://bsfez-11581-7962.show2.tikiwiki.org

{syntax type="tiki" editor="plain"}
When trying to log in using the top bar "Log in" module user gets CSRF error and is not logged in. Reproducible on tiki.org and dev.tiki.org. Not reproduced on doc.tiki.org. I feel it has something to do with the buggy cookie consent feature.

It does not happen when loggin in using the dev.tiki.org/login URL directly (instead of the top bar module).

You need to open new incognito window in Chrome/Firefox to "start fresh" and reproduce the issue.

Steps to reproduce in the attached screencast video.

https://dev.tiki.org/tiki-download_item_attachment.php?attId=514&display

A CSRF never ending loop happened to me earlier today, on dev.t.o.
I had logged in chromium-browser to dev.t.o as user "xavi" (no admin perms).

I needed to log in with my other user "xavidp" (the one with admin perms), so that I opened a private browsing window of chromium-browser. I went to visit the same page I had visited with the standard user where I had to fix some perms of that wiki page ( https://dev.tiki.org/Wish%20Report%20Tpl ). Clicked at "login" link at the top bar, which sent me to https://dev.tiki.org/login , provided the credentials, and then I got the message about CSRF at the url https://dev.tiki.org/tiki-login.php :
{QUOTE()}Error
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

Every time I tried (F5, visiting somewhere else within dev.t.o) and attempting to log in, I got the same CSRF error message reproduced, and I couldn't log in as user "xavidp".

I had to open a new browser (Firefox, in this case), and login as "xavidp" was successful.

I wonder what was happening.

I tried again, at the time of reporting this issue, and I got the issue reproduced again.

FYI: I had seen other weird CSRF false positives in other contexts in a 20.x tiki I use at work (behind a firewall). I 'll keep an eye open to add more details when I hit this bug again in other use cases. But there is something wrong still in the code in 20.x.

Sometimes after editing and saving the tracker item here I get a CSRF confirmation warning and when I confirm that I see an error on top of the form which says something like:

{CODE()}
The following mandatory fields are missing :
Category
{CODE}

Even though the category field is there filled with correct category values!

__Please note the edited form contains your values but it is not saved yet!__ Only after another "Save" button click attempt it gets saved normally then...

I'm trying to add menu options and successfully added several, but trying to add another one I get a CSRF message and have to reload the page without the menu option being saved. So I can't make the complete menu.

You can see the issue on hovering the "Slider doesn't work" issue title on https://dev.tiki.org/Wishlist+Search+Page?default%5Bcontent%5D=Slider

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

The new feature n 18.x "[https://doc.tiki.org/tiki18#Multilevel_style_numbering_for_ordered_lists|Multilevel style numbering for ordered lists]" is broken (not working) in 19.x and trunk...
I suspect some CSS/classes have changed.

{syntax type="tiki" editor="plain"}
The custom translation strings feature does not seem to work.

The recipe for reproducing this bug can be found here:

* Setup: [http://profiles.tikiwiki.org/Multilingual_Wiki#Setting_up_the_site_for_testing]
* Reproducing this particular bug: [http://profiles.tikiwiki.org/Multilingual_Wiki#Testing_custom_translated_strings]

{syntax type="tiki" editor="plain"}
On a Tiki27.x updated the customsearch plugin stopped to automatically load the page load results.
{CODE()}
{CUSTOMSEARCH(tpl="featuredFaq_customsearch.tpl" id="faqCustomSearch" recalllastsearch="0" searchonload="1" requireinput="0" customsearchjs="1")}
{CODE}

I can see an error in the DOM

{CODE()}
min_main_635f6700bf01c878afa54f2ab788dacc.js:108
Uncaught ReferenceError: jQuery is not defined at min_main_635f6700bf01c878afa54f2ab788dacc.js:108:98
min_main_abcaaa9d363b26f17986183396fe6829.js:43
Uncaught ReferenceError: jQuery is not defined at min_main_abcaaa9d363b26f17986183396fe6829.js:43:37
wikipage:499
Uncaught ReferenceError: $ is not defined at trackeritemtitle:499:1
wikipage:596 Uncaught ReferenceError: $ is not defined at wikipage:596:1
wikipage:1
{CODE}

In the Settings -> Performances admin panel
Minify JavaScript
Minify late JavaScript
Are enable.

If I disabled them both, the searchonload work again

On demo Tiki29 we can see an error feedback.

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

Database error as follows:

#
Context:
#
File tiki-editpage.php
#
Url tiki-editpage.php
#
Query:
#
insert into `tiki_objects`(`type`,`itemId`,`description`,`name`,`href`,`created`,`hits`,`comments_locked`) values(?,?,?,?,?,?,?,?)
Message:
#
Unknown column 'comments_locked' in 'field list'

installer/schema/20090205_forum_and_comments_locking_tiki.sql appears not to be run on fresh install. This file was introduced in:

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=rev&revision=17801

Shouldn't the filename be 20090405....? Is this the problem?

Also, is this related to http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=rev&revision=17919

When the session_storage preference is set to Database, some requests can misbehave due to a critical section in tikisession-pdo.php. This happens during concurrent requests, when one request is in the middle of a call to Session::write(). write() executes 2 queries, one which deletes the session (if it exists), and one which (re)creates the session. When write() is blocked between these 2 requests, 2 critical race conditions can occur. Assuming a first request is in between these 2 queries:
#If request #2 concurrently reads the sessions table, it will fail to find the session, causing Zend\Session\Container::getDefaultManager()->start() (in tiki-setup_base.php) to start a new session instead of resuming the session. This will cause:
## A multiplication of entries in the sessions table
## PHPSESSID to change unduly
## A loss of session data (in practice)
## The message "session cookie validation failed" to be logged in the system log.
# If the first race condition does not occur, but request #2 executes the DELETE in write() before request #1 has re-inserted the row, then whichever request finishes write() last will fail, due to an attempt to insert an existing row (the message will look like "Duplicate entry 'glmk0tl75dmi9rrkdfbgt7mr47' for key 'PRIMARY'").

! Symptoms

!! Images not displaying
This can be seen easily in a custom blog based on a wiki page in our Foncierpedia website. That page uses the LIST plugin to display posts with the author's avatar. Each time the page is loaded, there is one request to tiki-show_user_avatar.php per author, which redirects via HTTP 302 to tiki-download_file.php. The page currently has posts from 6 authors, so each load causes at least 6 requests using tiki-setup_base.php approximately simultaneously. In this context, the bug is very often visible, roughly 1 load every 5. To make it even more obvious, the critical section can be lengthened by calling sleep(2) between the 2 SQL queries in write(). With that, we see the bug [almost] on each load of the wiki page. The main symptom is that some images fail to display, due to race condition #2. This is very easy to reproduce with Tiki 15, since avatars are not cached, but in Tiki 18, tiki-show_user_avatar.php can return a 304 Not Modified, so if this doesn't reproduce on the first attempt, a full reload will be needed (Ctrl+F5 in Firefox).

This can also be reproduced with a wiki page which simply calls the IMG plugin. I used the following:
{CODE()}
{img src="tiki-download_file.php?fileId=6818&display=y" width="100px"} {img src="tiki-download_file.php?fileId=5810&display=y" width="100px"} {img src="tiki-download_file.php?fileId=5152&display=y" width="100px"} {img src="tiki-download_file.php?fileId=6974&display=y" width="100px"}
{img src="tiki-download_file.php?fileId=5800&display=y" width="100px"} {img src="tiki-download_file.php?fileId=6889&display=y" width="100px"} {img src="tiki-download_file.php?fileId=7052&display=y" width="100px"}
{CODE}

!! Other
We are also experiencing abnormal user disconnections on the site. These are harder to reproduce, but likely related.
Related commit: {commit id=45249}

!! Logs
There are multiple messages in the actionlog. A query like the following can help see the pattern:
{CODE()}SELECT FROM_UNIXTIME(lastModif), `tiki_actionlog`.* FROM `tiki_actionlog` ORDER BY ip, lastModif{CODE}
Related commit: {commit id=56775}

! Source
This is a regression from {commit id=24568}.

Errors on database update after a brand new trunk install Revision: 63992

{CODE()}
Macintosh-2:trunk Bernard$ php console.php d:u

Warning: Illegal string offset 'galleryId' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20101126_fgal_add_gallerie_user_tiki.php on line 30

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
4.1942 24906584 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
4.1947 24912832 9. upgrade_20101126_fgal_add_gallerie_user_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:174


Warning: Illegal string offset 'galleryId' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20101210_fgal_add_wiki_attachments_tiki.php on line 30

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
4.3763 24925600 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
4.3768 24931912 9. upgrade_20101210_fgal_add_wiki_attachments_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:174


Warning: PDOStatement::execute(): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lang' in 'where clause' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php on line 77

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
5.1030 25058928 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
5.1038 25087912 9. pre_20110727_tracker_multilingual_convert_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:180
5.1051 25094912 10. TikiDb_Table->deleteMultiple() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20110727_tracker_multilingual_convert_tiki.php:46
5.1051 25095488 11. TikiDb->queryException() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Table.php:109
5.1051 25095664 12. TikiDb_Pdo->query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb.php:72
5.1051 25095664 13. TikiDb_Pdo->_query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:118
5.1051 25097632 14. PDOStatement->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:77



[TikiDb_Exception]
Unknown column 'lang' in 'where clause'


database:update [--auto-register]
{CODE}

I re ran it and it changed for

{CODE()}Macintosh-2:trunk Bernard$ php console.php d:u

Warning: PDOStatement::execute(): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lang' in 'where clause' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php on line 77

Call Stack:
0.0029 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3364 23818896 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3489 24112240 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3492 24113544 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3492 24114144 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3504 24127280 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3532 24128192 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
1.1695 24643456 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
1.1703 24672440 9. pre_20110727_tracker_multilingual_convert_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:180
1.1719 24679376 10. TikiDb_Table->deleteMultiple() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20110727_tracker_multilingual_convert_tiki.php:46
1.1720 24679952 11. TikiDb->queryException() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Table.php:109
1.1720 24680128 12. TikiDb_Pdo->query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb.php:72
1.1720 24680128 13. TikiDb_Pdo->_query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:118
1.1721 24682096 14. PDOStatement->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:77



[TikiDb_Exception]
Unknown column 'lang' in 'where clause'


database:update [--auto-register]
{CODE}

On a Tiki25 freshly updated after "ec7baa4a7a5852584de95ed133ba3b2a078b3c81": https://gitlab.com/tikiwiki/tiki/-/commit/ec7baa4a7a5852584de95ed133ba3b2a078b3c81

I cannot complete anymore the console command -+database:u+-

This is a Debian11 server (updated) using last Virtualmin version using:
PHP 7.4.33
Database MariaDB 10.5.15-MariaDB-0+deb11u1
Tiki Version 25.1

I tested on my OSX local where the command completes:
 PHP  7.4.26
 Database  MySQL 5.7.34
 Tiki Version  25.1

{syntax type="tiki" editor="plain"}
Several problems with the date and time (picker) have made him unuseable on mobile.
* touching it move it to a very hard to see position
* It is not possible to use the sliders to set the time
* The inner modal covers the manual input field making correction impossible

At google search console (https://search.google.com/search-console/sitemaps) my sitemap (using https://bernardsfez.com/storage/public/sitemap-index.xml) is submitted via the console.php command (using the Tiki scheduler).

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

If I click on the corresponding row it open a detailed table where I see that Google fetched 2 XML and that fetching my articles XML it produce 1 error.

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

When I click on it to see the details I see error about the lasted date.

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

And when I look at https://bernardsfez.com/storage/public/articles.xml the dates are all wrong.
It seems to prevent Google to index my articles.
When I index one by one articles using https://search.google.com/search-console/inspect (when a page is not indexed I have an option to index it) It work just fine with the right date.

I also checked at tiki.org and I see the same errors: https://tiki.org/storage/public/articles.xml

{FADE(label="XML where we can see the date errors" icon="y")}

<!-- Generated by https://git.io/phpseo -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/%25D7%25AA%25D7%2595%25D7%259B%25D7%25A0%25D7%2594-%25D7%259E%25D7%25A7%25D7%2595%25D7%2595%25D7%259F-%25D7%259C%25D7%25A0%25D7%2599%25D7%2594%25D7%2595%25D7%259C-%25D7%25A6%25D7%2594%25D7%25A8%25D7%2595%25D7%259F-%25D7%2597%25D7%2595%25D7%2592%25D7%2599%25D7%259D-%25D7%2595%25D7%2592%25D7%25A0%25D7%2599-%25D7%2599%25D7%259C%25D7%2593%25D7%2599%25D7%259D</loc>
<priority>0.6</priority>
<changefreq>weekly</changefreq>
~~#F00:<lastmod>6773-12-06T16:34:41+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>5887-12-06T16:05:59+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>

{FADE}

{syntax type="tiki" editor="plain"}
The styles of the "button" of the date picker (or whatever it's called - the place you click to display the selector for the date and time) such as the font and colors are set dynamically to match the theme being used. This works for the themes in the themes directory, but this doesn't work completely for custom themes.

For example, I have a custom light-on-dark theme with a body background color of #0c0d16 (almost black) and a .form-control background color of #343a40 (also very dark), but the background color of the date picker's "button" (~np~div.dp__main dp__theme_light~/np~) is very light so clearly isn't getting the background color information correctly from the theme stylesheet. In a non-custom dark theme like Slate, I can see the button display with a light background for an instant and then get the correct dark background color to match the Slate theme, but for custom themes this switch doesn't happen, in my experience.

On the other hand, the date picker is using the right font, as specified by the custom theme, so there's partial success here.

I tested with the Switch Color Mode not active and with it active and set to both light and dark and the date picker button background was never correct. A workaround would be to add a CSS rule to the custom theme to correct the background color, but it would be nice if it worked automatically as it does for the themes in the themes directory.

Actually, now that I look again, it appears that the background color for the popup (with date and time selectors) isn't correct for non-custom themes, either. Using the Slate theme, which has a dark background color, the date picker popup has a light background with light text. This bad contrast is maybe due to the correct text color but wrong background color being used.

Also, the selector and popup backgrounds aren't sensitive to Color Mode switching.

Hopefully the same fix for these issues will work for both custom and standard themes.

The date picker is supposed to use the site styles (font, colors, etc.)
There is a difference of style when you see today's date and other dates (has been fixed recently)

Both are present in Tiki25 and gone in TIki26rc.

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

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

{syntax type="tiki" editor="plain"}
The datepicker modal in master has its own CSS and doesn't respect the properties of themes or color modes. I tried

{CODE()}
[data-bs-theme=dark] {
.dp__theme_light {
--dp-background-color: var(--bs-body-bg) !important;
--dp-text-color: var(--bs-body-color) !important;
}
}
{CODE}

for example in a theme's _css-variables.scss file had it had no effect. The datepicker's CSS always was used instead.

Similarly, because the datepicker uses different classes, the theme's Bootstrap class properties have no effect. Is there a way to systematically map the datepicker styles to the themes' styles? It seems to be harder to override the datepicker's CSS rules with Tiki CSS rules simply by making the Tiki rules stronger (giving the selector more specificity) the way that jquery-ui rules could be overridden.

Enabled and clicking the menu item the debugger no longer appears. Nothing in FF Firebug console...

This was working in previous versions of Tiki (maybe oldish ones: 6.x, etc, afaik). I couldn't check when the regression was introduced.

Default Duration length in calendar events misscalculated (2h while times were from 18h to 19h)

See it reproduced:
http://xavi-9794-5901.show.tikiwiki.org/tiki-calendar_edit_item.php
u: admin
p: 12345

At posting time, the times where shown (depending on where you click to add the event) either as from 0:00 to 1:00, from 18 to 19h, or from (in my last case) 10:41 to 11:41h.
But you you click at "Show Duration", they display 2h in both cases, even if they should display 1h.

Default pref allowMsgs set to y but not set to new users

On a Tiki 21.x using the "new" and hardly documented option to add action to items from an item list I set a page that using a plugin List displays items (names) and an edit icon (I create a custom template with this icon on the 2020-10-05):

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

This is not working anymore on my website.
However the show instance show it right in the tracker and in the plugin list.

NOTE : I remember why now I tried to design it with a custom template as it is not a successful display. ;-)

The forum doesn’t know where to go when deleting a thread.
2 remarksbox:

Success
The following topic has been deleted:
Testing post in the forum from IOS

Question Error
Incorrect thread

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