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
Aaaand: the plugin was not last in the line. I fixed the order manually, and voilà ...
Code: Select all
case 'backend_plugins_new_instance': // This hook will always push the entryproperties plugin as last in queue.