Or the story of arcane nonsense.

Having soft launched my homepage I felt there was something that was still bothering me. I was doing my includes with jQuery. No one else seemed to notice that millisecond flash that is characteristic of client-side includes, but I sure did.

So I set about correcting that problem with some PHP includes! Sounds easy enough right? Alas!

 

After I was all done tearing apart my index files I fired up the site. To my annoyance, every single page had about 22 pixels of white space above the navigation bar.

To quote the Dude

“This aggression will not stand, Man”

After reviewing all my code looking for some rouge padding element or other mistake I was stumped. Some darker forces where clearly at play. So I headed over to Stack Overflow where I found this interesting answer.

Which led me to this bug report from over 10 years ago: https://bugs.php.net/bug.php?id=22108

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the first three bytes of the file (EF BB BF), PHP doesn't ignore these bytes when loading and compiling the file, but instead considers them output coming prior to the <?php. This causes incorrect display of the page and failure of any http header output.

It does this even when the internal character format is set in php.ini to be utf-8. 

Desired outcome:
PHP recognizes the utf-8 bom and disregards it.

Interesting right? So I cranked open Sublime Text and re-saved all my PHP files as UT8 (which I thought they already where) and sure enough, the issue was resolved.

I guess the moral of this story is, sometimes it is actually not a problem with your code (but most of the time it is)

seriously

 

 

 

 

 

 

 

 

 

 

 

 

Leave a Reply

Your email address will not be published.