You you have any 3rd party extensions which have own smart search plugins?

And the update from 3.10, has that worked without any problems?

In Joomla 4 all database tables should have utf8mb4_unicode_ci collation.

So either there went something wrong with the update from 3.10 so the finder tanlrs haven’t been changed to that collation, or some tables from a 3rd party component with a smart search plugin still have utf8mb4 _general_ci.

What you list in the description as collation is the database collation. This is only used if nothing else is given in the create table statement. But Joomla’s core specifies the character set and collation when creating tables, so the database collation doesn’t apply. If however there are 3rd party extensions which don’t do that, their tables are created with the default character set and collation of the database.

Maybe it helps if you change these tables to utf8mb4 _unicode_ci.

In any case you should report that to the extension developers, too.

if you report back which tables don’t have the right utf8mb4 _unicode_ci we can maybe help to find out to which e du ensign they might belong to.

One candidate could be an old version of an extension named “word cloud”, that made such trouble in past.

Hi Richard, thanks for your reply - very helpful!

I do have Hikashop (4.0.4), which should be utf8mb4_unicode_ci, but looking at the tables, they are still the old utf8_unicode_ci.

So that might be the issue?

I will do a backup and change them manually.

Is that safe to do them manually?

Should be safe to do it manually, but take care: If there are single columns which have utf8mb4_binary collation, they should remain like that.

To make sure that this doesn't happen in future with other extensions being installed or updated, change the database collation to utf8mb4_unicode_ci. As said, this will not change character set and collation of existing tables, it will only make sure that new tables in future are created with the right character set and collation when the create table statement doesn't specify them.

Are you using Hikashop 4.0.4 like you wrote? Or was that a typo and it’s 4.4.0? As far as I understand this page here, 4.4.0 was the first version for Joomla 4: https://www.hikashop.com/home/blog/464-hikashop-4-4-0.html .

Have you checked the pre-update check in Joomla Update component before updating from 3.10? What did it say about your Hikashop extensions?

Yes, I have installed 4.0.4 (just this morning), but looking at the hikashop tables, they are still old collation.

Yes, I did the whole pre-update check.

Looking at the tables which need changing, do the columns within each table also need to be changed? There are certainly a lot 😄

If you only change character set and collation for the table, only new columns added to that table get the new character set and collation. To change characeter set and collation of existing columns in a table at once, you have to do an “ALTER TABLE … CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci” statement, with “…” being the table name. This converts all existing columns of that table. But as I said, check before doing that if there are columns having utf8mb4_bin collation. If there are some, they are not many. Those you have to change to utf8mb4_bin after the above conversion.

Let us know if it helped or not.

But again: You wrote you use Hikashop 4.0.4, but the first version which says it is compatible with Joomla 4 is Hikashop 4.4.0, so you might have to update Hikashop to make it work. You can do that after having made the above fix.

Yes, sorry, it is Hikashop 4.4.4

Ok... getting through them, BUT I am getting a couple of errors:

Query error: #1071 - Specified key was too long; max key length is 1000 bytes

You can google for that .. am sure you find a solution. I go sleep for today.

No problem, thanks Richard, appreciate it!

@RedDustSnow I don’t have much knowledge on Hikashop, and I don’t know how much data you already have for that. But maybe the easiest fix would be to export data of that shop either with methods of that shop if there are such, or with PhpMyAdmin, uninstall that shop, set database collation right and install it again, and after that import the data, in case of PhpMyAdmin only content but not structure.

P.S.: Let is know when your issue is solved and no other issues have appeared after that, so we can close it here, or close it yourself when it’s clear that there is no issue with the CMS core. Thanks in advance.

Hi Richard, I was thinking a similar thing, but have gone one step further
by creating a Dev site with new j4 install, added all the extentions I have
on current site, then import the raw dBASE data from active site. That
should eliminate any erroneous tables.
I will report later today (AU time).

On Sat, 6 Nov 2021, 22:58 Richard Fath, @.***> wrote:

P.S.: Let is know when your issue is solved and no other issues have
appeared after that, so we can close it here, or close it yourself when
it’s clear that there is no issue with the CMS core. Thanks in advance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35976 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQKIRXGVOXW36BDLSTHLMODUKUKAFANCNFSM5HO2WNGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Ok, I have got smart-search to work (yay), there were some erroneous remnants.

Here is what I have done...

1. created a new J4 site (Dev) and installed all extensions I use on the main site.
2. From the dBase, exported 'structure only' and added to new 'test' database.
3. Exported 'Data only' from the live site database (only that which mapped to above tables), and imported that data into 'test dbase.
4. Used the test database for the Dev site.

I can go to Smart-Search index and no errors. I can see all the articles indexed, I can even see pages and even hikashop from the front BUT...

Looking at the Categories, they are all perfect, showing the number of articles in each, but if I go to articles, there are none there.

I have looked at the raw data and all seems to be ok - hence being accounted for in Category view - but just not displaying.

I even created a new article and I can see that in the article manager, but none other. Is there a backend asset that has been missed or is mismatched?

Simon

Is there a backend asset that has been missed or is mismatched?

@RedDustSnow No idea since I don't know your data.

It seems to be not an issue with the CMS core but with your site's data, so I would suggest you ask in the support forum and you or we close this issue here, since here is only for bugs or other kinds of errors of the CMS core.

Hi Richard, yes, I too think it is a data issue. I have, previously, used an article import/export extension and that may have created the glitch. But obviously not detected with upgrade/migration.

The production site runs perfectly, except for the indexing. I will redress down the track.

Thanks again for your input, greatly appreciated.

Simon B

Closing as not a core issue.