After I upgraded multisite system from 3.5 to 3.5.1, I started having a weird encoding problem - all  
are rendered as  
. 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.
<meta>
is irrelevant, don’t use it. And what the server says will be overridden by PHP. So there is some PHP code withheader()
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.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 aheader()
call, but couldn't find any.