WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After I upgraded multisite system from 3.5 to 3.5.1, I started having a weird encoding problem - all &nbsp are rendered as Â&nbsp. All of my pages (as well as the DB entries) are UTF-8 encoded. All the meta tags on the pages are (automatically) set to

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

However, when I view the page, some of the characters are incorrectly displayed. Upon further examination of the request headers, it turned out that the server is setting the encoding to ISO-8859-1.

The problem seems to be that on the base website (www.blabla.com), my

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

has no effect on the browser, even with AddDefaultCharset utf-8 set in .htaccess - the response header still says

Content-Type:text/html; charset=iso-8859-1

However, on the very same install and with the same settings, my sub-directory website (www.blabla.com/sub) gets the response header as

Content-Type:text/html; charset=UTF-8

Changing to a different theme (TwentyTwelve) temporarily, switching off all the plugins does not solve the issue.

share|improve this question
<meta> is irrelevant, don’t use it. And what the server says will be overridden by PHP. So there is some PHP code with header() sending the wrong charset. Make sure to disable mu-plugins too. Also, enable debug notices; maybe there is a notice sent before WordPress can send the correct header. – toscho Apr 16 '13 at 12:58
Unfortunately, I don't think I'm using any mu-plugins, as there is no mu-plugins folder anywhere in my installation. I did enable the debug mode, and got a bunch of "attribute_escape deprecated" and undefined indices warnings, but would they really interfere with the encoding? I also grepped through the code, looking for a hardcoded call to iso in a header() call, but couldn't find any. – Gregory Goltsov Apr 16 '13 at 14:33
These notices tell me at least there is still some third-party code active. They don’t happen in a regular WordPress installation. – toscho Apr 16 '13 at 14:55
up vote 0 down vote accepted

I pinpointed the bug to the User Access Manager 1.2.2 (network-wide) - once disabled, everything went back to normal. I'm still not sure what exactly was causing the problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.