nbi1

Thanks, I’ll check that out.

How do I check the plugin version in a scenario like this where the installer hasn’t completed yet? Can’t go to the WP dashboard because installation hasn’t finished. wp-cli can’t help because the dashboard isn’t available. Is your plugin version a string in one of the files?

Your workaround solves the problem, thank you. Now I’ve got other issues to deal with, but at least the collation check isn’t derailing the process.

Figured it out. My instincts about an incorrect check were on target – the installer is indeed performing an invalid check.

During the backup of the original you execute the above query to get the list of collations. That’s fine. But when you store the list in the installer you store utf8_general_ci when in fact utf8_general_ci does not appear in the query result! Why? Because you find utf8mb3_general_ci which is an alias for utf8_general_ci and you unalias before storing the list. So at the restore end of the operation the installer consults the list which includes utf8_general_ci and the validation fails because it’s not found in the server collation list. But it is there – as the alias utf8mb3_general_ci ! Actually the installer hints at this problem with its output – it should not be showing utf8_general_ci it should show utf8mb3_general_ci because the aliased form is used in newer versions of MariaDB (I didn’t know that until I researched this issue).

So the fix consists of 2 checks when backing up:
1. If the collation query returns utf8mb3_general_ci store that – do not store the unaliased utf8_general_ci.
2. If the collation query returns utf8_general_ci (old MariaDB) store the alias utf8mb3_general_ci instead.

These checks will ensure that with a newer (older doesn’t make sense) MariaDB the installer will properly try to match utf8mb3_general_ci in its list against utf8mb3_general_ci in the server collation list.

This fix will solve the problem for anyone going through the backup/restore cycle for the first time. It won’t help those like me who already have an installer backup set with utf8_general_ci instead of utf8mb3_general_ci. Couple of possible solutions for that: 1. a standalone tool/script that fixes the installer’s collation list, or 2. add installer option to handle this case (can’t just omit this validation because if utf8mb3_general_ci is missing from the server then there is a real problem). Manually hacking the installer list would probably work if I knew where it was buried, but I’m sure you don’t want the headaches resulting from asking users to do this.

My guess is that the bug consists of just looking for ‘utf8’ to infer which collations are needed. This wouldn’t be a problem with older versions of MariaDB (pre 10.6.4 ?) because these older server versions still included utf8/utf8_general_ci. So even if utf8 is erroneously flagged as needed it’ll still get past the installer because the server supports it. But the newer versions (10.6.4+) do not so the bug is exposed. Googling shows numerous reports about the MariaDB utf8 problem, this is typical: https://www.mail-archive.com/misc@openbsd.org/msg179329.html. If my guess is correct the fix should be simple – don’t look for ‘utf8’, look for ‘utf8mb4’.

WPematico supposedly can find images in source articles and set them to be the featured image, but that isn’t working. I just found one of your tutorials on featured image which seems to contain code for extracting the first found article image as the featured. I’ll give that a try.

Regarding the display of the image I may have misunderstood something in the docs. I took image_size=”thumbnail” to mean scale & display the featured image. It seemed to me that the presence of “image_size” would make include_image=”true” unnecessary since one wouldn’t use “image_size” unless the intent was to display the image. But based on your comment both are necessary if one wants to display a thumbnail?

I aggregate multiple feeds and I checked the page source of the feed items – they definitely contain images (). Yes, I had already looked at that article and used the recommended global settings.