I'm glad to see that the upcoming PR8 explicitly defines a uniform character set in both the frontend and the admin - this was one of the major obstacles in getting full UTF-8 support for a store I'm currently upgrading from 4.x to 5.5. There is, however, another problem that wasn't mentioned in the changlelog, which is the MySQL connection and client encoding.
The nice thing about MySQL is that it's easily able to work with different database, server and client encodings at the same time and convert between them on the fly. The bad thing about this functionality is that things go totally bonkers when any single part of the system misreports the encoding it intends to use, which includes depending on a possibly unknown default value. This might be the case with a MySQL connection made my Miva for certain server configurations. Now, if at this point anyone reading this thinks something along the lines of "well, just ask the admin to change it", I'm afraid that's not a proper solution, or any solution at all for that matter, if the store is using shared hosting - the store owner cannot expect the hosting provider to change a server default just for them when it might break things for other users of the database server.
Instead, the correct solution provided and recommended by MySQL is to issue the SET NAMES and SET CHARACTER SET statements [1] immediately after establishing the connection to the MySQL server. This is the only way to be sure that things will work properly regardless of the server configuraion.
For now, I just downloaded the MMLSK, added two MvQUERY calls to DB_Open and DB_Open_PrivateKey in lib/dbapi_mysql.mv, recompiled it and replaced the release mvc file with the new one. It works and things are, hopefully, not going down in flames, but it's a horrible hack that will break as soon as I upgrade to a new version and the file gets overwritten by a Miva-provided one. And I'm still not sure if it's not going to combust spontaneously as soon as I look the other way.
Instead, Merchant should issue those statements out of the box, with the encoding configurable in some way - another field in merchdb.dat, or whatever will be used for the charset header in admin? Or, if you're actually opting for hardcoded UTF-8 (not a bad choice in 2011, the US-based ASCII users won't see a difference anyway), just hardcode it there, too.
Anyway, I'd be glad to see this on the way to a future update. I guess it's too late for such a change in PR8, but I'd be even more glad to be proven wrong here.
[1] http://dev.mysql.com/doc/refman/5.0/...onnection.html
Regards,
The nice thing about MySQL is that it's easily able to work with different database, server and client encodings at the same time and convert between them on the fly. The bad thing about this functionality is that things go totally bonkers when any single part of the system misreports the encoding it intends to use, which includes depending on a possibly unknown default value. This might be the case with a MySQL connection made my Miva for certain server configurations. Now, if at this point anyone reading this thinks something along the lines of "well, just ask the admin to change it", I'm afraid that's not a proper solution, or any solution at all for that matter, if the store is using shared hosting - the store owner cannot expect the hosting provider to change a server default just for them when it might break things for other users of the database server.
Instead, the correct solution provided and recommended by MySQL is to issue the SET NAMES and SET CHARACTER SET statements [1] immediately after establishing the connection to the MySQL server. This is the only way to be sure that things will work properly regardless of the server configuraion.
For now, I just downloaded the MMLSK, added two MvQUERY calls to DB_Open and DB_Open_PrivateKey in lib/dbapi_mysql.mv, recompiled it and replaced the release mvc file with the new one. It works and things are, hopefully, not going down in flames, but it's a horrible hack that will break as soon as I upgrade to a new version and the file gets overwritten by a Miva-provided one. And I'm still not sure if it's not going to combust spontaneously as soon as I look the other way.
Instead, Merchant should issue those statements out of the box, with the encoding configurable in some way - another field in merchdb.dat, or whatever will be used for the charset header in admin? Or, if you're actually opting for hardcoded UTF-8 (not a bad choice in 2011, the US-based ASCII users won't see a difference anyway), just hardcode it there, too.
Anyway, I'd be glad to see this on the way to a future update. I guess it's too late for such a change in PR8, but I'd be even more glad to be proven wrong here.
[1] http://dev.mysql.com/doc/refman/5.0/...onnection.html
Regards,
Comment