Character endoding : backend encoding is "locking" frontend encoding ?

Something I noticed a while ago : I am used to build websites using utf-8 rather than ISO encoding. When I started my first website with MODx I noticed no matter what character encoding I specified, the response headers was returning ISO-8859-1... I knew because it caused validation error : the encoding specified in the html head (<meta http-equiv="content-type" content="text/html; charset=utf-8"/>) did not match the servers headers.

Now my host (TextDrive) is in the US and default as utf-8, unless I edit php.ini it’s not ISO encoding. It meant MODx somehow had to be set up to have the frontend with same encoding as the backend/manager. I tried changing the encoding in the backend, and it worked... the only thing now is for me to have the french language file properly set for utf-8.

It’s no big deal, but we have to be clearer in the manager help you have :

Quote from: System

Please select which character encoding you wish to use in the manager. Please note that MODx has been tested with a number of these encodings, but not all of them. For most languages, the default setting of ISO-8859-1 suffices.

Is there something I am missing ? Was it intentionnally set up that way ?
Why not use utf-8 as default ?

It’s easiest to just use



(maybe someday that name can get changed...it’s pretty much only used in the frames for the manager)

Thanks Susan, that help character encoding to be consistent and not break validation, but it doesn’t explain why the backend encoding "forces" the frontend encoding with server headers...

document.parser.class.inc.php, line 415

Thank you david for this question

In my template I had hardcoded this :

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

It seems going. The codage in the database stay in latin1_general_ci obviously.
In my idea, the better is to select database codage since the install process. Someone can confirm or not? Perhaps a kicker MODx for the next 0.9.2?

Quote from: sottwell at Jan 26, 2006, 11:20 AM

document.parser.class.inc.php, line 415

Thanks a lot for this, helps me understand the logic

Quote from: MOZx at Jan 26, 2006, 11:55 AM

In my template I had hardcoded this :

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

It seems going. The codage in the database stay in latin1_general_ci obviously.
In my idea, the better is to select database codage since the install process. Someone can confirm or not? Perhaps a kicker MODx for the next 0.9.2?

MOZx , read the post again.
I have defined the charset in templates, but as I said it’s (as you might know) overriden by the servers headers.

Normally, the fix would be to add this directive in .htaccess

and modify php.ini


but Susan just explained why the frontend encoding has to be the same has the backend, given how it’s set in document.parser.class.inc.php.

It’s not a problem really, but it could help people who want to use utf-8 to set this properly.

And FYI, this has nothing to do with database encoding...

Sorry David, I badly understood your problem.
The question seems to be interesting. Could you explain this in french board please for more readability and no cross-posting? (or here as you want)

Bien amicalement, bonne journée.