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.

  • 2
    <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.
    – fuxia
    Commented Apr 16, 2013 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.
    – gregoltsov
    Commented Apr 16, 2013 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.
    – fuxia
    Commented Apr 16, 2013 at 14:55

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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