Loading...
 
Skip to main content

Category: 27.x

27.x
Show subcategories objects

Name Type
CardDAV button link is wrong (hardcoded to webmail)
{syntax type="tiki" editor="plain"}
Hello,

when I press "CardDAV" button in ../tiki-contacts.php, it leads/maps to

[CardDAV](https://mydomain/tiki-carddav.php/addressbooks/admin/webmail)

which does not exist (if webmail is not activated) and does produce:

<d:error>
<s:sabredav-version>4.4.0</s:sabredav-version>
<s:exception>Sabre\DAV\Exception\NotFound</s:exception>
<s:message>Addressbook with name 'webmail' could not be found</s:message>
</d:error>

However, if I change the link to:

https://mydomain/tiki-carddav.php/addressbooks/admin/

I can see two entries under Nodes:

* gour
* system

The first one was the *.vcf which I did upload, but the problem is that its contacts are not visible at:

https://mydomain/tiki-contacts.php

So, the question is whether it is possible to upload CardDAV addressbook (*.vcf) file and have its contacts visible within Tiki and possibly sync them with desktop/mobile clients?


Sincerely,
Gour


tracker item
Categories, adding page should be easier and the field that display the pages expandable
At tiki-admin_categories.php?parentId=2&cookietab=3#content_admin_categories1-5, Add objects, you have a selector field that display all the pages available for categorization (the pages that are not in this category). It show only 5 pages and it make the user action quite uncomfortable.

https://ibb.co/yWDWL67

It should be possible to expand this selector and display more pages.

tracker item
Codemirror and heavy scripts
{syntax type="tiki" editor="plain"}
Hi, as explained here : [https://tiki.org/forumthread79604|https://tiki.org/forumthread79604] ,
heavy scripts such as codemirror (1.2 MB) are always loaded (tiki 21, 24, 27), even when not in use, resulting in unnecessarily long loading times for visitors. Is there a way of loading heavy scripts only for pages that use them?

thx
--
mb
tracker item
"Replied to" comments content displayed with broken layout (vertical/horizontal)
{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
tracker item
Improve consistency of the wiki templates parameter and syntax in Tiki tools, plugins and syntax
It Tiki we can use Smarty or Wiki templates (wiki pages).

For the Wiki pages there no consistency between tools in Tiki.

-=The template parameter=-
For customSearch plugin the parameter is "wiki=" - https://doc.tiki.org/PluginCustomSearch
For the List plugin the parameter is "tplwiki=" - https://doc.tiki.org/PluginList-output-control-block
For the Plugin IncludeTpl the parameter is "filename="wiki:" - https://doc.tiki.org/PluginIncludeTpl
... There could be more...

All the parameter to call a template from a wiki page the parameter should be the same anywhere.
"tplwiki=" seems to me to most understandable and precise.

-=The Wiki syntax require to use the template=-
* Plugin List: a wiki template can be use as is (you just paste your HTML)
* Plugin customSearch: your html need to be enclosed between literal tags ({literal} HTML {/literal}

It should be just consistent for the end user (not power user) experience.
tracker item
Custom theme favicons don't work properly
{syntax type="tiki" editor="plain"}
Faicons only work if they're in the -+themes/yourtheme/favicons+- dir, if they are in the theme dir inside -+_custom+- they don't get picked up.

I think (assume) this is only in 27.x but can't check now.
tracker item
Customsearch searchonload stopped working on Tiki27.x when minifying javascript is enabled
{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"}


tracker item
Date picker background colors don't correctly match the theme (especially custom themes)
{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.

tracker item
Date selectors on tracker items are broken after update to Tiki27.5 under certain conditions
{syntax type="tiki" editor="plain"}
I've updated a Tiki27.x (after the Tiki 25.7 release) and now the date and time selectors are broken.
It is visual and forbid entering a date. I found a workaround, see below.

This is an old Tiki (started in Tiki9x) that was updated years after years.
I couldn't reproduce on demo.

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

I don't see errors on the console on Brave.

On chrome:
{CODE()}
min_main_235ae2033a9c3fb4320e739db2fbcd55.js:137 JQMIGRATE: Migrate is installed, version 3.5.2
injected.js:3 [Detection] Sign in with intersection observer was watching an unacceptable node.
WI @ injected.js:3
injected.js:3 [Detection] Sign in with intersection observer was watching an unacceptable node.
WI @ injected.js:3
{CODE}

{CODE()}
if (!No(o)) {
console.error("[Detection]", "Sign in with intersection observer was watching an unacceptable node.") || logger.report(["Sign in with intersection observer was watching an unacceptable node."], {
severity: "error",
fileName: "js/b5x/ui/inline/frame-manager/src/sign-in-with/detection/manager.ts",
lineNumber: 230,
prefix: "[Detection]",
highlight: !1
}),
t.unobserve(o);
continue
}
{CODE}
tracker item
Double slash when loading pdfjs
{syntax type="tiki" editor="plain"}
found a weirdness in my apache access logs. A double slash. (related to pdfjs package)
I'm not sure on how to report such thing I just believe it should be a single slash:

```
xxx.xxx.xxx.xxx - - [27/Oct/2025:13:37:59 +0100] "GET /vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/images/loading.svg HTTP/2.0" 200 558 "https://dddd.ccc/vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/viewer.css" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
xxx.xxx.xxx.xxx - - [27/Oct/2025:13:37:59 +0100] "GET /vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/images/loading-icon.gif HTTP/2.0" 200 2583 "https://dddd.ccc/vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/viewer.css" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
xxx.xxx.xxx.xxx - - [27/Oct/2025:13:37:59 +0100] "GET /vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/images/shadow.png HTTP/2.0" 200 330 "https://dddd.ccc/vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/viewer.css" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
xxx.xxx.xxx.xxx - - [27/Oct/2025:13:37:58 +0100] "GET /display60 HTTP/2.0" 200 1818150 "https://dddd.ccc/vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/viewer.html?file=https://dddd.ccc/display60" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
xxx.xxx.xxx.xxx - - [27/Oct/2025:13:37:58 +0100] "GET /vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/build/pdf.worker.js HTTP/2.0" 200 283175 "https://dddd.ccc/vendor//npm-asset/pdfjs-dist-viewer-min/build/minified/web/viewer.html?file=https://wiki.is-il.org.il/display60" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
```
tracker item
Editing Wiki Plugin removes language definition from Page, removes Page Description
{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']);?>^
tracker item
Error in a Tiki27 Unified Index rebuild (MySQL) Undefined array key "is_html"
{syntax type="tiki" editor="plain"}
On a Tiki 27.x (updated after Tiki27.5 release) I had multiple errors while rebuilding the Unified Index.

{CODE()}
2026-02-09T09:46:45+00:00 INFO (6): addDocument forum post 1 {"memoryUsage":"42.5 MiB","memoryAvail":"-1 B"}
2026-02-09T09:46:45+00:00 ERR (3): WARNING: Undefined array key "is_html" {"code":2,"file":"/home/domain/public_html/lib/tikilib.php","line":6477}
2026-02-09T09:46:45+00:00 INFO (6): addDocument forum post 4 {"memoryUsage":"42.5 MiB","memoryAvail":"-1 B"}
.../...
{CODE}

See solution for the fix I used.
tracker item
Error in unified-index for par page that don't have an approved version
{syntax type="tiki" editor="plain"}
On a Tiki27 I use Stagged and Approval.
I see this in my refresh-index log (MySQL Search) for each page that exist but don't have an approved version yet.


```
2025-07-04T06:11:50+00:00 INFO (6): addDocument wiki page blabla {"memoryUsage":"56.1 MiB","memoryAvail":"719.5 MiB"}
2025-07-04T06:11:51+00:00 ERR (3): WARNING: Trying to access array offset on value of type bool {"code":2,"file":"/var/www/vhosts/blabla.org/httpdocs/lib/core/Search/ContentSource/WikiSource.php","line":102}
2025-07-04T06:11:51+00:00 ERR (3): WARNING: Trying to access array offset on value of type bool {"code":2,"file":"/var/www/vhosts/blabla.org/httpdocs/lib/core/Search/ContentSource/WikiSource.php","line":103}
```
tracker item
Error: ENOSPC: System limit for number of file watchers reached while using npm run watch
{syntax type="tiki" editor="plain"}
While creating a themed Tiki27 it is the second time (I have 2 Tiki27 🤗) I hit this error while running "npm run watch".

Error: ENOSPC: System limit for number of file watchers reached

May be it is possible to address this on our System Builder ?
tracker item
Fatal error updating a wiki page at themes.tiki.org
{syntax type="tiki" editor="plain"}
{syntax type="tiki" editor="plain"}
This error displayed today when I tried to update a wiki page's content:
Fatal error: Uncaught Error: Class "Tiki\Lib\wiki\Tikilib" not found in /home/tiki-themes/public_html/lib/wiki/WikiPaginationUtils.php:30 Stack trace: #0 /home/tiki-themes/public_html/lib/wiki/renderlib.php(396): Tiki\Lib\wiki\WikiPaginationUtils::getNumberOfPages() #1 /home/tiki-themes/public_html/lib/wiki/renderlib.php(96): WikiRenderer->setupPage() #2 /home/tiki-themes/public_html/tiki-index.php(715): WikiRenderer->runSetups() #3 /home/tiki-themes/public_html/route.php(373): include('...') #4 {main} thrown in /home/tiki-themes/public_html/lib/wiki/WikiPaginationUtils.php on line 30


Git information: 27.x:bf6f6e1d from 05:15 GMT-0000
tracker item
Fatal error when changing banner type or creating a new banner zone
{syntax type="tiki" editor="plain"}
I configured a banner a while back and set the "Use image" method. When I changed it to the "Use text" method and saved, this error message displayed:

"Fatal error: Uncaught Error: Call to a member function uploaded_file_error() on null in . . . \tiki-edit_banner.php:279 Stack trace: #0 {main} thrown in . . . \tiki-edit_banner.php on line 279"

I deleted the original banner zone and created a new one. After clicking the "Create a new Zone" button, I got the error again.
tracker item
Fatal error when trying to roll back a wiki page version
I get this error when trying to roll back a wiki page edit:
{CODE()}
Fatal error rendering template resource tiki.tpl

Error: Too late to modify javascript footer. Footer already sent by output_js() called at [C:\laragon\www\G\master\temp\templates_c\en_social^5ad1c2788b40256924d5b0e0334524beedd0bac1_0.file.ajax.tpl.php:42] in C:\laragon\www\G\master\lib\headerlib.php:167
Stack trace:
#0 C:\laragon\www\G\master\lib\headerlib.php(390): HeaderLib->throwIfJSFooterAlreadyOutput()
#1 C:\laragon\www\G\master\lib\smarty_tiki\function.listfilter.php(157): HeaderLib->add_jq_onready('\n$('#listfilter...')
#2 C:\laragon\www\G\master\temp\templates_c\en_social^3267c1be8f241585572fb44c82888efc29024a34_0.file.footer.tpl.php(122): smarty_function_listfilter(Array, Object(Smarty_Internal_Template))
#3 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_resource_base.php(123): content_6499a458d554e6_06980054(Object(Smarty_Internal_Template))
#4 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#5 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#6 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(386): Smarty_Internal_Template->render()
#7 C:\laragon\www\G\master\temp\templates_c\en_social^55f5a4bc7540f72b398327967e73f7fc22487a02_0.file.layout_view.tpl.php(306): Smarty_Internal_Template->_subTemplateRender('file:footer.tpl', NULL, 'en--social', 0, 3600, Array, 0, false)
#8 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_resource_base.php(123): content_6499a4585434e2_93248584(Object(Smarty_Internal_Template))
#9 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#10 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#11 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(386): Smarty_Internal_Template->render()
#12 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_runtime_inheritance.php(116): Smarty_Internal_Template->_subTemplateRender('layout_view.tpl', NULL, 'en--social', 0, 3600, Array, 2, false, NULL, NULL)
#13 C:\laragon\www\G\master\temp\templates_c\en_social^8e0607d454bf2d78c1a972d6c03de2de9f840094_0.file.tiki.tpl.php(38): Smarty_Internal_Runtime_Inheritance->endChild(Object(Smarty_Internal_Template), 'layout_view.tpl')
#14 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_resource_base.php(123): content_6499a4584bf5d4_86088514(Object(Smarty_Internal_Template))
#15 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#16 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#17 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_templatebase.php(238): Smarty_Internal_Template->render(false, 1)
#18 C:\laragon\www\G\master\vendor_bundled\vendor\smarty\smarty\libs\sysplugins\smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute(Object(Smarty_Internal_Template), NULL, NULL, NULL, 1)
#19 C:\laragon\www\G\master\lib\init\smarty.php(482): Smarty_Internal_TemplateBase->display('tiki.tpl', NULL, NULL)
#20 C:\laragon\www\G\master\lib\tikiaccesslib.php(798): Smarty_Tiki->display('tiki.tpl')
#21 C:\laragon\www\G\master\lib\tikiaccesslib.php(487): TikiAccessLib->confirmRedirect('Are you sure yo...', 'session')
#22 C:\laragon\www\G\master\tiki-rollback.php(49): TikiAccessLib->checkCsrf(true)
#23 {main}
{CODE}
tracker item
File gallery 'Download zip version' option not working
{syntax type="tiki" editor="plain"}
When listing a File Gallery you can select a number of files and use the "Select action to perform with checked ..." drop down list below the listing to select the "Download zip version' which will then download a .zip file with all the selected files inside.

This works OK in 24.6 but just produces a 'white screen' in 27.0

tracker item
File gallery archived number of files setting not being respected
{syntax type="tiki" editor="plain"}
File galleries have an edit setting that limits the number of file versions that are held as 'archive' but this limit does not seem to be respected in T27.x as the number of archived files exceeds this value.
tracker item
Forum; Images from wiki plugin img in post are not displayed when viewing the thread
{syntax type="tiki" editor="plain"}
At https://tiki.org/forumthread79408-Convert-between-file-storage-methods#threadId79409 I replied to a post inserting a image using the wiki plugin img. (toolbar insertion)

On save the image is not displayed.
If I edit the page, the image is visible on the preview.
I tried on different browsers

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

{img fileId="2140" thumb="box"}
tracker item
Forums in "threaded" style sorting by "newest first" should show the newest posts first
{syntax type="tiki" editor="plain"}
Forums listed by "newest first" order in "threaded" style don't show the newsiest posts first, but ordered by the first reply's post date (which might have been 3 years ago!)

A work-around for now is to use "plain" style, quite disappointing.
tracker item
Freetag search results should be placed in a way user see them
{syntax type="tiki" editor="plain"}
At https://doc.tiki.org/tiki-browse_freetags.php you can click on any tag and it will initiate the search (after it as been fixed with https://dev.tiki.org/item7924)

However the results are "hidden" from the user eyes down at the bottom of the page.
If the user doesn't catch the quick refresh of the page he will have the impression noting happened (no search) as it will see the same list of tags in front of his eyes. True on Desktop, super-true on mobile.

The results should be visible right away after a search is done for a better UX.
tracker item
Grouping metatags and SEO related fields on a wiki page properties
{syntax type="tiki" editor="plain"}
We have now a new option to set the "Content of the tag title" on the properties of a Wiki page.

We had a previous metatags field, "Page Description (used for metatags)" that can be enabled at tiki-admin.php?page=metatags

Enabling it add a field "Description (used for metatags)" to the properties of a Wiki page.

We have also "Will be added to the sitemap".

While these fields are related they are not grouped in the wiki page properties and all options seems mixed without any consideration as you can see in this example.

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

Note: This is just an example other option, preferences and parameters based on admin settings should checked.

Anyway, these should be grouped in a more logical way having in mind the user experience.
tracker item
Headings now have d-flex justify-content-start classes and this breaks some page styling
{syntax type="tiki" editor="plain"}
Using wiki syntax for headings and no other styling or classes, now h2 has classes "d-flex justify-content-start". This is new in Tiki 27. It's messing up one page of mine where everything is centered, so now everything is centered except the headings, which are left justified. Sometimes headings are centered, but now apparently this isn't possible without resorting to HTML instead of wiki syntax (I didn't check if Markdown in Tiki also adds these classes.)

I don't know what problem adding these classes to all the heading sizes was meant to solve but hope there is another way to solve it and these classes can be removed from headings.
tracker item
Highlighted forum post has contrast problem in dark mode
{syntax type="tiki" editor="plain"}
In dark color mode, the page background is dark and foreground text is a light color, but when a new post is added in Tiki's forums, it is highlighted like this:

-+ <article class="card post commentStyle_plain mb-3" id="threadId11" style="background-color: rgb(255, 255, 255);"> +-

That inline CSS produces a white background, making it impossible to read the light-colored text in the post. Instead of inline CSS, a class or a CSS variable, like

-+style="background-color: var(--bs-primary-bg-subtle);"+-

should be used, so the color will be appropriate in light or dark (or other) color mode.
tracker item
Show PHP error messages