[(modx_charset)] is gone in latest Evo svn

And that is why I was of the opinion that the default value should remain. It is just one less thing that users need to keep track of when using third-party add-ons and templates. If they need multiple values, then they’ll have to do something about it anyway. Plugins and manager override by user configuration would make that possible.

The MODxHost template in the demo site uses it, by the way.

I have used it in MaxiGallery too.. and I guess that many other 3rd party snippets use it.

This isn’t so much about requiring all third-party add-ons and templates that use it needing to be edited, it is that the add-ons at least would need an extra parameter that the user would need to set. If it’s a site-wide default, then they don’t have to worry about it once they set their preference (if it’s not the default install value of utf-8) in the main site configuration. It would not be possible to hard-code it in snippets and templates.

Sounds like I’ll be making sure it goes back in.

Quote from: rthrash at Jul 13, 2009, 02:13 PM

Sounds like I’ll be making sure it goes back in.

Yep, but I think we can make it "deprecated" if we want and put it in the release notes. So new stuff doesn’t use it while preserving it for the older stuff.

Quote from: zi at Jul 13, 2009, 04:24 PM

Quote from: rthrash at Jul 13, 2009, 02:13 PM

Sounds like I’ll be making sure it goes back in.

Yep, but I think we can make it "deprecated" if we want and put it in the release notes. So new stuff doesn’t use it while preserving it for the older stuff.

Absolutely not!

[[modx_charset]] is entirely tied to the database content character set, and should be respected by every component ever written for MODx. This is a critical system setting.

Of course, if you want to make multi-lingual sites or use multiple languages in the backend even, you should be using UTF-8 anyway, as you cannot simply change the charset for part of the site unless you have custom code in place to transform data to a specific charset (though that solution would probably really suffer in the performance category and would not be entirely lossless).

To date the [(modx_charset)] has only affected displays and never had anything to do with the database connection. Granted it should match, but there’s a lot of legacy baggage that needs to be sorted there.