etomite_charset

Might we not want to change that (also in the database) to $system_charset or something equally neutral? I know that it’s mostly used in the Manager, which is getting a major overhaul, but it’s also useful in the HTML head of templates:



instead of

Dont know deeply about it, but I think, you should consider to change ETOMITE to MODx or whatever up-coming.

Just my few cents

It’s already corrected in TP4

Has this been changed in the SVN?

Quote from: Mark at Aug 15, 2006, 05:38 PM

Has this been changed in the SVN?

This isn’t something that should just change. We should probably switch it to default_charset but then have the manager update both the etomite_charset value and default_charset value until the next release at least, so folks won’t be freaked out if no charset is set for their pages if we just remove it.

Can we just loose "etomite"? I don’t care to what...

Quote from: rthrash at Aug 15, 2006, 06:37 PM

Can we just loose "etomite"? I don’t care to what...

The whole point is that people have this in their templates, and potentially in their snippets, deployed in live sites. If we remove or change etomite_charset, an upgrade will cause their templates to have no value passed for the character encoding, which is bad, uummmkaaaayyyy? If we change the configuration name in the manager to just say Default Charset, add a duplicate system setting called default_charset, and maintain both the value of default_charset and the existing etomite_charset in sync from the manager value provided, everything will still work, and we can give users an entire release cycle to start using the new value. This is comparable to an API function being deprecated, which means it will be removed in a future version so change it as soon as you get a chance.

Quote from: OpenGeek at Aug 15, 2006, 07:46 PM

If we change the configuration name in the manager to just say Default Charset, add a duplicate system setting called default_charset, and maintain both the value of default_charset and the existing etomite_charset in sync from the manager value provided, everything will still work, and we can give users an entire release cycle to start using the new value. This is comparable to an API function being deprecated, which means it will be removed in a future version so change it as soon as you get a chance.

Which would mean that there was just *one* etomite_charset reference in the 0.9.5 distribution rather than in every template, and the one reference would be somewhere people are unlikely to look, so that would please everyone.

It would be nice to be able to define this per-template or per-language. Especially for multi-lingual sites!

Well, if you want to define it per template, you just hard-wire it in... or you could pull this from a TV.