Fakey

You know what, I just tested disabling all plugins on our live server (instead of the development serer), and I found that the https redirect bug is in the wordpress core, not due to your plugin.

I apologize.

That actually does help. I changed it a bit, though. I used ^example.com/$ (with my domain, obviously).

Thanks.

Change the header template file. Also, you should check the other parts of the template to make sure they don’t have BOMs. If they do they will further corrupt the output. (e.g. a BOM on the top of the footer template would actually be added near the bottom of the generated output.)

The BOM is at the beginning of the file. (see https://unicode.org/faq/utf_bom.html#29 )

Yes the BOM can be removed. If you’re on Windows just use Notepad++ and click “Format > Convert to UTF-8 without BOM”. Otherwise you’ll have to open the file with a hex editor and remove the first three bytes (0xEF 0xBB 0xBF).

Just to clarify on my last post: supercache was working fine with my UTF-8 with BOM files prior to wordpress 2.6.1.

Is wordpress now using the php “header” function that it wasn’t using before? If so then the BOM (byte order mark) will be written before the ‘header’ function can be called, thus throwing a wrench in the whole process.

It’s just a guess. I haven’t studied the changes.

I’ve found the solution: if your pages are encoded in UTF-8 with the BOM the grabled text shows up. If you encode the page in UTF-8 without the BOM the page is displayed correctly.