Database collation - Multilingual plugin [SOLVED - more or less]

Found a bug? Tell us!!
Post Reply
Posts: 22
Joined: Sat Nov 25, 2017 12:08 am

Database collation - Multilingual plugin [SOLVED - more or less]

Post by stephanbrunker » Sat Aug 04, 2018 11:29 pm

I don't know if this is a bug or not. At first, I had the database configuration "set names" on NO, wrote my articles and they were displayed correct. But as I checked directly into the database for backup purposes, all the German ä,ö,ü etc. were coded wrong in the database if I want to pull all the articles out of the db wouldn't give the correct encoding. I could fix that by changing the "set names" option to YES and manually correct all the wrong encodings in the database. Everything is now fine, correctly displayed in the blog and on the database (phpMyAdmin). But now if I edit an article, the option "change article language" is missing. Any idea why? And if I have an multilingual blog, wouldn't be utf-8 a better choice than latin1german2 for the encoding? Now that all the content is correctly encoded, the SQL change encoding functions also would work correctly. If possible, I would avoid having utf-8 encoded characters in a file marked as latin.

PS: in the configuration, the encoding is given as UTF-8, but why is it otherwise in the database?

PPS: if i change the configuration "set names" to no and the encoding to "national", the display stays correct and the language selector is active. But … the article is not in the editor. That is also not a solution.

PPPS: As i searched around in the source code, it is really strange for an outsider. [s]The multilingual plugin doesn't even exist[/s] and I didn't found the line where the entryproperties should display the language selector in the editor. Basically, the selector disappears if dbNames or dbCharset variables are set which in itself is very, very strange because these variables doesn't appear anywhere else. I have to decide if i roll everything back to the last backup, which means converting all higher chars (asc > 127) to ghibberish in the database and proceed with dbNames = false. Or I can pray for a solution (please help!) and just insert the translation in the entryproperties table manually with phpMyAdmin which is now possible because the encoding for the database is now correct and I can edit the db. I can think also of a third option, but this seems to be very risky, means dbnames = false and changing all the database tables to utf8, because it looks like the entries are written in utf8 in a latin1 charset.

PPPPS: I could fix it. The hint was the line

Code: Select all

case 'backend_plugins_new_instance':
                    // This hook will always push the entryproperties plugin as last in queue.
Aaaand: the plugin was not last in the line. I fixed the order manually, and voilà ...

Post Reply