Page encoding can stop the PHP parser
The main PHP Class file of The Music Tank stopped loading altogether yesterday. After scanning lines after lines of code trying to guess what what generating an error I still hadn’t found the problem until late last night. What made it nebulous was that instead of having a message from PHP saying a known error like ” ‘)’ expected on line 64 “, I was triggering an Internal Server Error on Apache when loading the website and outputting multi-linguistic garbage when I tried to load the class directly from the browser (instead of nothing at all because I don’t print data right from the class).
I have to admit I could have been a bit keener on the issue just by looking a the garbage the file was making. It turns out that my code editor, TextWrangler, had changed the encoding type of the file from UTF-8 to the Macintosh charset when I inserted the © character straight in the document without using it’s HTML counterpart ©.
This change of charset and/or the use of special characters in the source code stopped the PHP parser. I can’t explain why as I don’t have much access to the configuration files to my server’s PHP version nor do I know how PHP reads the .php files, but I think it was due to the use of multiple charsets. For instance the main class was using the Mac charset while the subclasses it was importing used UTF-8 encoding.
The frustrating part is really how this whole deal was created out of laziness. Apple offers a wide selection of special characters by doing a [alt + most keys] combination. I thought I’d save some time by using their copyright sign instead of putting my experience with HTML to use and stick with ©.
At least, this episode forced me into cleaning the quote quite a lot by splitting my pages into modules which reflect the content’s architecture. The Tank should show a light performance boost now. Very light though, hehehe.