If have two Tikis running on 18.8 (before anyone asks: I cannot go to 21.x, because 21.x breaks my CSS layout...). As I discussed in the Forums before I started this bug report, one (the older) just recently stopped searching. Only when logged in as Admin I could see the reason behind that: A COLLATE clash...
Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' Die Abfrage war: SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits` The built query was likely: SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits`
This older Tiki began YEARS ago (on 2.something?) and went through numerous updates, so far with no problems. The newer one started on 18 (or 12).
Interestingly, both databases have default collation set to utf8_general_ci.
When checking collation with
SHOW TABLE STATUS
I found that almost all tables were set to utf8_unicode_ci, but some were not (galaxia_workitems,index_628bfa7e573fa,index_pref_de,tiki_activity_stream_rules,tiki_addon_profiles,tiki_credits_usage,tiki_galleries_scales,tiki_goal_events,tiki_h5p_contents,tiki_h5p_contents_libraries,tiki_hp5_libraries,tiki_h5_libaries_cachedassets,tiki_h5_libraries_hub_cache,tiki_h5_libraries_languages,tiki_h5_libraries_libraries (!),tiki_hp5_results,tiki_h5p_tmpfiles,tiki_object_scores,tiki_output,tiki_scheduler,tiki_scheduler_run,tiki_search_queries (!),tiki_stats,tiki_tabular_formats,tiki_user_monitors).
Now that looks like a bug in one of the upgrader scripts.
However, a look at the tables of the newer Tiki showed that there was only one table that used the same collation as the database's default: index_pref_de. All others were set to utf8_unicode_ci! Now that would then be a bug in the installation procedure...
I am not a SQL expert, but I would like to recommend that Tiki sets the default collation to whatever Tiki shall use in the future and then leaves the default (i.e. not declare individual collation). Any individual collation definition is prone to be a future source of trouble...
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show.tikiwiki.org instance. To start, simply select a version and click on "Create show.tikiwiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show.tikiwiki.org.