Category: Bug

{syntax type="tiki" editor="plain"}
I'm on Tiki Wiki 29 I enabled the Tiki Tags feature.
I'm using some tags on wiki page and I have set some tags.
But the keyword tags are not displayed in the head.

I went at tiki-admin.php?page=metatags (admin metatags).
I checked that "Include tags" is enabled. But I have also noticed I no Keywords set in the field Keywords.

As result I have no keyword on the page.
If I add just one keyword in the field, on the page i see this keyword but also all other missing keywords.

The condition for the elseif branch only triggers if either metatag_keywords or metatag_local_keywords is non-empty.

NOTE: I don't use forum so I didn't touch anything related to the way the forum fill its keywords. It may worth to have a look at it.

{syntax type="tiki" editor="plain"}
On an upgraded Tiki to version 29.1 I have articles using their own image and no "Image alternative text" was set as this is not mandatory.

However if I try to modify the content an old article on save the page reload no save and I don't see an error.
Only when I go to the "Image" tab of the edit article interface I can see an error message.

Add a value for the field "Image alternative text" solve the issue.

If a value is mandatory NOW, a red asterisk or something on the field should show it is mandatory.
If a user edit an article that was created BEFORE the change then the issue should be pointed inside or outside the tab Image so the user see what is the problem.

I posted a question on the forums, but got no answer:
https://tiki.org/forumthread73497-Cannot-delete-image-gallery?topics_offset=9
After some research I found a very old posting by someone who complained about the exact same behaviour on Tiki 3.2 (!);
https://tiki.org/forumthread35020-Cannot-delete-images-from-image-galleries

He also posted a workaround, that is to disable search engine friendly URLs. I tried that, but found that search-engine friendly URLs were already disabled, only option was enabled: tag for canonical (true) URLs. I disabled that too, but it does NOT do the trick. I cannot delete an image gallery I created. Not as the creator of the image gallery, not as admin. The creator has administrative rights to file galleries, admin of course also.

When the image gallery in question is opened, the list of gallery actions is completely empty. On the list of all image galleries, the screwdriver icon only has one option available: Object permissions. ALL other options are without links, and not link-coloured. There are no specific permissions set, global rights apply. And there all registered users have tiki_p_admin_galleries...

Thanks
Hman

On a site with image galleries, there is a button in page tiki-galleries.php which claims ''Migrate Images to File Gallery''

When I click on it, a new File gallery is created and named ''Migrated Image Galleries'' (that is perfect!)
For each image gallery, a file gallery with the same name as the image gallery is created as a child of ''Migrated Image Galleries'' (still perfect!)

__But__ no images are actually migrated to these new file galleries. The new file galleries are empty and the old image galleries are still there.

Using the command line version gives the same lack of result:

{CODE(theme="default")}php console.php gallery:migrate
All files migrated!
feedback: L'image a été réduite : %s x %s -> %s x %s
error: Duplicate file found as `Nouveau Fichier`. Upload rejected.
error: Duplicate file found as `Beatrice1.jpeg`. Upload rejected.
error: Duplicate file found as `kitty.jpg`. Upload rejected.
error: Duplicate file found as `160x55_INESSStccn.jpg`. Upload rejected.{CODE}
But nothing was actually migrated.

Files are stored on the file system, in case that makes a difference.

This prevents people from getting rid of deprecated ''image galleries'' feature.

See issue reproduced on: [http://jyhem-9952-7324.show2.tikiwiki.org/]
* Log in as admin
* Go to [http://jyhem-9952-7324.show2.tikiwiki.org/tiki-galleries.php] and click on ''Migrate Images to File Gallery''.
* See a new file gallery showed up in [http://jyhem-9952-7324.show2.tikiwiki.org/tiki-list_file_gallery.php] with sub-galleries with proper names. The new file galleries are empty instead of containing the migrated images.

This also creates the file galeries without migrating the files:
{CODE(theme="default")}root@seed22:/var/www/jyhem-9952-7324# php console.php gallery:migrate
Undefined index: show_filename on line 175 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined index: show_filename on line 177 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined offset: 31 on line 737 of /var/www/jyhem-9952-7324/lib/metadata/datatypes/exif.php
Undefined index: show_filename on line 175 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined index: show_filename on line 177 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined index: show_filename on line 175 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined index: show_filename on line 177 of /var/www/jyhem-9952-7324/lib/filegals/filegallib.php
Undefined offset: 31 on line 737 of /var/www/jyhem-9952-7324/lib/metadata/datatypes/exif.php
All files migrated!{CODE}

When using the image plugin to embed an image from the file gallery into content, I have found that certain images will not be zoomed to more than 100 percent. Regardless what you set for height=, it will __always__ display images at 100%.

So far I have not found what those images affected could have in common.

Reducing the size (values below 100%) is __never__ a problem, even on those images that cannot be zoomed to more than 100%, strangely enough...

When displaying an article, the exif rotation info is not read and used from the jpg file, the image is displayed with a wrong rotation.
When you click on the picture, the info is used and the picture is displayed properly.

When I insert images into a wiki page, as thumbs with default sizes, or as image heights equal such as both images with 220px height assigned they do not display as such. They display as different heights.
Please see show instance.

When you update an image that is already contained in the file gallery (via the 'upload new version' property) you have the choice of having it resized or not. Just like with any image upload.

But unlike a regular upload, you don't have the actual choice: Regardless of whether you uncheck the option "Use Gallery default resize settings for images (No resize)" and set max width and height to 0, which means "no limits" or whether you leave it checked and default to "no resize", the uploaded image _will_ be resized to the exact dimensions of the original image.

This means you cannot update with a higher resolution.

The size of the image, however, indicates that the image does not get resized upon upload, but rather upon display.

Thanks
Hman

There seems to be a bug in the process of creating new user groups. When you log in as Admin, and go to tiki-admingroups.php, you should be able to create a new group of users. There is a tab "Create group".

When you want to create a new group, obviously you have to give it a (new) name. So you enter that, and a description. For starters, you could have it inherit rights from Anonymous. If you don't need a registration tracker, you can leave this out (e.g. if you do not want that users can assign themselves. Example: You want to create a new group of "premium users" that will get additional rights to see some content not visible for others).

If membership shall not expire, there is no need for an expiration date.

If you do all that, you will get a confirmation dialog "Create the group GROUPNAME?". You click on Create and - get an error message

"Error
Group name cannot be empty".

But group name was NOT empty... Actually, the whole dialog "Create the group GROUPNAME?" would not make sense IF it would be able. So even if the error message "cannot be empty" would work correctly, which it doesn't, it would come too late, it should be before the confirmation dialog...

There is also a PHP error, which might (or might not) be unrelated:

"NOTICE (E_NOTICE): Undefined variable: groupcolor
At line 411 in tiki-admingroups.php"

In admin tracker list (tiki-view_trackers.php?trackerId=XX), if I filter on an itemLink field which is configured with pointing to the remote tracker's ID and displaying another value, I need to enter the value of the ID instead of the value which is displayed. This is counter-intuitive and hard to guess.

{syntax type="tiki" editor="plain"}
Checking the page with the browser inspector, I find the class -+dropdown-menu-bottom+- that wasn't there before. Two questions:

# Why is this applied to a vertical menu in a side column where there is plenty of vertical space for dropdowns to display normally? It would be appropriate in a menu in the footer module zone.
# Bootstrap already has a [https://getbootstrap.com/docs/5.3/components/dropdowns/#dropup|dropup] class. And Smartmenus already have a -+sm-navbar--drop-reverse-y+- class to provide "drop up" behavior. I usually have a horizontal system menu in the bottom zone and add this class when assigning the module. Unless I'm missing something, if the desired behavior is for dropdowns to drop upward, why not use these classes instead of reinventing the wheel with superfluous CSS?

IMO it's really important for all developers who work on the Tiki interface to be very familiar with the Bootstrap classes that are available, and to use these instead of increasing the size of Tiki stylesheets with new homegrown rules that do the same thing.

{syntax type="tiki" editor="plain"}
In Tiki 27, in a wiki page with Markdown editing, I tested PluginDIv to make (using two of the plugins, nested) a simple row and one-column layout. It works fine but when I open the edit screen to make a subsequent edit, I find this part of the page is duplicated, so I need to delete the second copy of the PluginDivs layout before doing any new editing of the page. If I don't delete it, it becomes part of the page content after saving.

Actually, the PluginDiv part of the page gets duplicated but the final div closing tag gets separated.

There seem to be more repetitions of the plugin section of the page in new edits. The ~np~{DIV(class="row")}~np~ is missing from the duplicate code, and the duplicated line of text is truncated to "This is new conte".

It seems to work ok in master. I made several edits to a page with the Markdown editor and PluginHTML and PluginDiv plus other text and the page content stays as it should, no duplication.

{syntax type="tiki" editor="plain"}
On a fresh Tiki27 => Trackers

{img fileId="3082"}

On the -+tiki-user_information.php+- -> text "__My Info__" is constructed from two strings: "Info" - which is loaded from -+language.php+- (this is OK) and with string "My", which is untraslatable.
Word "My" doesn't load from -+language.php+- (looks as constant).

{syntax type="tiki" editor="plain"}
Probably also a problem here but the server seems to be having trouble (really really slow!)

I tried with this syntax

{CODE()}
This is some -+inline code+- syntax.
{DIV()}This is some -+inline code+- syntax inside a plugin which looks fine in the preview.
{DIV}
{CODE}

Like this:
This is some -+inline code+- syntax.
{DIV()}This is some -+inline code+- syntax inside a plugin which looks fine in the preview.
{DIV}

Hello,
I have a scenario I cannot get working in Tiki15, but I managed to let it work in 14.2.
It is about plugin tracker inline editing.
Whereas I managed to activate inline editing, it just does not work when clicking on the small icon. On one case, I see a lock icon and the page returns to its initial stage.
Did I forget something in the activation?
In the attached images, you can see the small icon next to the field. When I click on it in Tiki 14.2, the field is replace with an editable field, in Tiki 15, nothing happens.
Thanks,
hubert

{syntax type="tiki" editor="plain"}
The style= attribute passed to {DIV} and other wiki plugins is silently dropped.
I believe (I'm not pro understanding git) it comes from here: https://gitlab.com/tikiwiki/tiki/-/commit/7b9d81b6f30c7532bee770079ddeead22838a3f1

In lib/wiki-plugins/wikiplugin_div.php, the function wikiplugin_div() initializes $style = '' before calling extract($params, EXTR_SKIP). Because EXTR_SKIP skips extraction when a variable already exists, the style parameter from $params never overwrites the empty $style variable.

At lib/wiki-plugins/wikiplugin_div.php
I changed :
{CODE()}
function wikiplugin_div($content, $params)
{
$style = '';
extract($params, EXTR_SKIP);
{CODE}

For

{CODE()}
function wikiplugin_div($content, $params)
{
extract($params, EXTR_SKIP);
$style = $style ?? '';
{CODE}

refreshed the cache en the issue was fixed.

When you enter text into an article, or when you edit an article's content, there might come a situation where you want to use a character that is not readily on your keyboard.

Unfortunately, in standard setting, you cannot enter it's unicode address directly with ampersand hash.

That is the time to use the edit feature 'special characters', represented by a keyboard symbol. Clicking this opens a pop-up window containing several special chars, among them are some greek characters.

Btw, strangely there is a greek uppercase chi, but I did not see a lowercase one. The font (currently I use EB Garamond) not only carries all greek chars, but even accented greek and diacritic greek...

This is what happened:
But I just needed an uppercase chi, and it was there, so I clicked it to insert that into the text. It was inserted, the text looked okay, so I clicked on Save. Result: ALL text after the chi was gone, and instead of a chi there was just a ]6.

I was lucky, there were just two sentences after the chi, which I could reproduce. I tried to replay the scenario, and it could be replicated. Each and every time the text gets truncated at the chi. And because articles do not have a history (I'll have to open a feature request to have that added, it's dearly needed) this leads to immediate loss of data (once again, that is not available as a bug classification).

Installed a Tiki from git 836e12ee and ran Composer.
Got some warnings:

{CODE()}
Could not scan for classes inside "vendor/adodb/adodb-php/" which does not appear to be a file nor a folder
Could not scan for classes inside "vendor/h5p/h5p-core" which does not appear to be a file nor a folder
Could not scan for classes inside "vendor/h5p/h5p-editor" which does not appear to be a file nor a folder
Could not scan for classes inside "vendor/pear/xml_rpc" which does not appear to be a file nor a folder
Could not scan for classes inside "vendor/smarty/smarty/libs/sysplugins/smarty_security.php" which does not appear to be a file nor a folder
{CODE}

{CODE()}
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package montefuscolo/xmpp is abandoned, you should avoid using it. No replacement was suggested.
Package symfony/inflector is abandoned, you should avoid using it. Use EnglishInflector from the String component instead.
Package zendframework/zend-version is abandoned, you should avoid using it. Use ocramius/package-versions instead.
Package zendframework/zendservice-akismet is abandoned, you should avoid using it. No replacement was suggested.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Package sensiolabs/security-checker is abandoned, you should avoid using it. Use https://github.com/fabpot/local-php-security-checker instead.
{CODE}

May be it could be cleaned ?

When upgrading my trusty old installation of 12.14, which seemingly went through without errors, after it was completed, there is a mentioning in the installation wizard that sometimes the ability to log-in as admin might be lost.

This has struck here. Unfortunately, once you dismiss this information and proceed to log-in (with or without locking the installer) you'll never see this text (and the help offered therein) again...

After finishing the installer, I could not log-in as admin to unlock the site. And, as I wrote, the info is never shown again...

So I went to the database and I think I found the culprit.

In the table users_users I see that the record containing the admin carries a new password. According to my backup, the PW should be starting with "$1$9", but it is "$2y$10$".

According to PHP documentation the first characters before the dollar signs merely indicate the cryptographic method used for hashing. And it should be normal that from time to time PW will be re-encrypted by new methods like blowfish, or key lenghts. PHP docs even recommend automating this.

But due to the one-way nature of hashing it is impossible to re-encrypt passwords without help from the user, here the admin. The PW has to be entered fresh and then encrypted with the new method. It's impossible to decipher and re-crypt.

So if in the short time-span between the backup I drew and the run of the installer, the PW changes in the DB and changes cryptographic method, it must have been tampered with!

One more nail in Tikis coffin for me.

I installed a new Tiki26 from git on my local computer.
When I updated the DB using the Tiki installer front this was the output;

{CODE()}
Fatal error: Uncaught Error: Call to a member function writeLn() on null in /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php:41 Stack trace: #0 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php(13): applyAlterForTable(Object(Tiki\\Installer\\Installer), 'tiki\_actionlog\_...', 'DROP PRIMARY KE...') #1 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/Installer.php(186): upgrade\_20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki(Object(Tiki\\Installer\\Installer)) #2 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/Installer.php(141): Tiki\\Installer\\Installer->installPatch('20231008\_fix\_pr...') #3 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/tiki-installer.php(511): Tiki\\Installer\\Installer->update() #4 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/tiki-install.php(137): include\_once('/Users/bernards...') #5 {main} thrown in /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php on line 41
{CODE}

Using SSH I ran the update through the console -+php console.php database:u+-
It completed and I could re-run the installer.

I also installed on a Debian remote server and had the same issue.

{syntax type="tiki" editor="plain"}
Apparently it is not possible to create a multi selection field in a tracker "Unterstützungsmeldungen" with the option "Mit einem regelmäßigen Foerderbeitrag".

This results in a permanent name unterstuetzungsmeldungenMitEinemRegelmassigenForderbeitrag, which will produce multiple (seven!) errors when a user fills in the form.

There seems to be a constraint on the length which is not monitored upon creation of the tracker. It should not be possible to create tracker and field names and options that will, as a result, make the tracker fail!

Also, the exact numerical limit is intransparently unknown. I will have to look into the DB to find out...

For some use cases, the arguments for multi selection or checkboxes MUST be quite long. It is legally not sufficient to just record "user has checked a checkbox" when this in effect leads to a contract. The full text of the option, as displayed to the user, must be recorded. This is especially important for options where a user entitels the org running the Tiki to make repeated SEPA withdrawals from bank accounts!

InterTiki stopped working on this site properly. Users and the groups are not being replicated anymore. When someone registers on tiki.org, the user does not appear here. For example on tiki.org there is registered validated user samymwamba, but if you check here the user is not found on https://dev.tiki.org/tiki-adminusers.php

{syntax type="tiki" editor="plain"}
We have now, when we use multilingual, an hreflang tag that is added to display alternates pages.
This is it should work;
Every page in a multilingual set should:
* List itself with its own hreflang.
* List all other language/region versions.

Ensure all those other pages return the favor.

But in Tiki, it create ONLY the code for the alternative pages.
IE:
I have 3 page for en, fr and de.
There should 3 alternate rel link, one for each language.
However, when I'm on the de (German language) page, I see only:

<link rel="alternate" href="tiki-index.php?page=Community Members HomePage" hreflang="en">
<link rel="alternate" href="tiki-index.php?page=Bonjour" hreflang="fr">

This leads to error on website checkers.

{img fileId="3141"}

{syntax type="tiki" editor="plain"}
When I compile a Tiki27 or 28 or 29 from git I have a warning about the "chunkSizeWarningLimit" that is limited to 500.

To fix it I edited src/js/vite.config.mjs and added;

{CODE(caption="line 159, after: target: "es2022")}
chunkSizeWarningLimit: 2500,
{CODE}

{CODE(caption="line 197, after: //preserveModulesRoot: 'src/js/',)}
manualChunks(id) {
if (id.includes("node_modules")) {
if (id.includes("jspdf") || id.includes("html2canvas")) {
return "vendor-pdf";
}
if (id.includes("element-plus")) {
return "vendor-element-plus";
}
return "vendor";
}
},
{CODE}


May be this could be of some help ?