MODX Staff
I’m sorry, but the current versions of MODx work wonderfully with a lot of various encodings. Any shortcomings are generally in a specific component that was developed by third-parties, configurations issues, or in the version of PHP itself.
With the old MODx I had a lot of problems with the character encoding, so I wonder wether this will be better in revo.
At the current time though, Revo ONLY supports utf-8 encodings.
Can I install the current Alpha using utf-8 as a charset in the db and in the html output? And if not, do you plan to make this possible in the final version?
And I suggest you not forget that usernames/passwords should work with utf8 either.
And don’t forget, that also things like usernames/passwords etc. should work with uft8 chars then.
MODX Staff
Why would you setup a database with that collation for use with utf8 content? Either let the installer create the database (it will create it with the selected collation) or create it with the correct collation in the first place, before installing the tables into it.
the problems with 9.6 weren’t with the newest version. I read that it schould be better now.
I took a closer look at my test-installation of revo now. In the "system info", the charset is utf8 which I chose at the installation. The database is in latin1 (collation: latin1_swedish_ci). The output seems to be utf8 (according to ff). What confuses me is the db collation.
MODX Staff
No, modx is designed to install using the collation specified for the database container, and will create the database with the proper collation if you provide a user with the privileges to do so. Having a database with the latin1 collation and using different collations on the tables/columns will cause massive problems with modx now, as the default technique used to properly connect PHP to the database (i.e. SET CHARACTER SET) rely on the database collation matching the tables. It is very important that this is the case, or you will likely encounter problems. Using SET NAMES can be a workaround for this, but it can be lossful as it depends on conversion (in the MySQL client) between character sets.
i think this is an easy mistake to make - in fact, i’ve just done exactly the same thing. i created a new db first, and didn’t notice it had used latin1.
shouldn’t modx force the creation of utf8 columns if that’s what’s selected during installation? the server variables for collation settings are only defaults anyway, and some users might not be able to change the global variables on their dbs...