UTF-8 is hell. I have run into problems with UTF-8 before (see Migrating MySQL to UTF-8 encoding).

I moved a site that was displaying fine from an old Apache server to a new Apache2 server and quickly identified that the Apache2 server was displaying odd characters.

The site is running a PHP application with a MySQL backend. The MySQL database is using latin1_swedish_ci character encoding. The old site was displaying correctly. Both the new and old site are using the same database.

So what was going on?

I was running into an issue with a vserver where the disk space usage was at 23% but I was getting a 'No space left on device' error message. I run vserver with 12 virtual servers and none of the other servers exhibited the same behavior.

Recently I came into a situation where a former employee had used a gateway marshaling concept and created multiple directories with the same file names (eg. www/admin/index.php. www/admin_v2/index.php). Debugging the code became problematic due to long filenames when using __FILE__. The long file paths were polluting the debug output and making it difficult to read.

I wrote a little function to return the file path based on a root directory specification. For instance if the script filename (aka __FILE__) is '/really/long/and/hard/to/read/path/www/index.php' the function will return 'www/index.php'.

This is useful for debugging calls (I use PEAR::Log) when using techniques such as:

I have always had trouble reliably and dynamically finding what my application root was in PHP. There seemed no way to effectively determine what the application root was on the fly. I always keep my application root separate from my www root for security considerations. This knocks out using $_SERVER['DOCUMENT_ROOT'].

The Issue

Consider the following directory structure:

/path/to/domain.com
  --> app/
        --> includes/main.php        
  --> www/
        --> index.php
        --> admin/index.php