Recently I was attempting to create some cron jobs to run PHP scripts on a DV server or at MediaTemple, with PHP installed as an Apache module (rather than CGI). I was able to execute the php file, however all of my include and require statements were totally failing.

My first idea was to set the include paths in PHP. This failed and the scripts still reported errors. My next attempt was to use absolute paths for my includes. This correctly found the includes, but resulted in safe mode errors.

I finally resolved the issue by creating a custom .ini file for PHP, making the appropriate setting changes and then supplying that ini file as an argument to PHP in the cron command.

SSH into the server, and copy the ini file. Something like:
#cp /etc/php.ini /var/www/vhosts/domain/includes/cron/php.ini

Now open up the new ini file in vi or emacs (I’m not getting into that debate). First you’ll want to disable safe mode by changing the line “safe_mode = On” to “safe_mode = Off”. Next, you can comment out the openbase_dir setting by changing the line “open_basedir = “/usr/share/pear” to be “; open_basedir = “/usr/share/pear”. And finally, set the includes path for your php scripts.

The last step is to make sure you execute the correct command in cron. Remember, you’ll need to pass the custom .ini file as an argument to PHP. Something like:

php -c /var/www/vhosts/domain/includes/cron/php.ini /var/www/vhosts/domain/includes/cron/test.php


This isn’t rocket science, and probably a no brainer to some. But, I found it useful and hope someone else does too.

The best thing about this, is I can leverage existing PHP code without having to write a ton of junk in PERL (yuck). Less code = less frustration.

So how do you serve gzipped js files?

There a few methods out there. I chose the one below since it was fast, easy and I’m hella freakin’ lazy.

The first step is to gzip all of the javascript files that you might be serving up. The fastest way I found was to just telnet into the server, and execute the following bash command:

gzip -cr <javascript directory>

Of course you’ll need to replace <javascript directory> with the correct directory that your javascript files are located in. The -c option tells gzip to keep the originals. This is important so that you can still serve non gzipped versions to browsers that don’t handle gzip! The -r option tells it to recurse through the directory. Now you should have a directory full of javascript files and their gzipped counterparts.

init.js
init.js.gz
jquery-ui.js
jquery-ui.js.gz
jquery.easing.js
jquery.easing.js.gz
jquery.history.js
jquery.history.js.gz
jquery.js
jquery.js.gz
swfobject.js
swfobject.js.gz

Yay. How exiciting, no?

The next step is to modify .htaccess to do some URL rewriting.

AddEncoding gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]

Essentially your telling the web server to server up gzip files, if the browser accepts them and the user is not on Safari and if there is a compressed version of the file available.

That’s really about it.

Here’s the difference in file sizes:

Pretty significant size difference!

So, I uploaded to a remote server and tried again. Blammo. Chit just worked the way it was supposed to. This left me scratching my head however.

I installed Charles (www.charlesproxy.com), which is a great debugging HTTP proxy/monitor, to see what was going on. Everything worked as it should in FireFox, but still no dice in IE.

Then I noticed that traffic wasn’t being captured for Localhost when using IE. After a bit of stumbling around the net I found that if you add a period right after localhost, Charles will capture the traffic.

http://localhost:8080/ajaxTest.html

becomes:

http://localhost.:8080/ajaxTest.html

When I reloaded the page, I got a very nice surprise. Not only did Charles capture the traffic, but the XHR returned with a proper responseXML property!

I’m no network engineer, so I’m not even going to try and guess as to WTF. But, I’m happy it works as expected and thought I’d post about it in case someone else ever runs into this issue.

• Ported all of the javascript over to jQuery and ditched those ancient JavaScript libraries I’d written years ago
• Implemented some keyword searching on projects so you can see projects based on languages or technologies.
• Reworked the backend so that everything was a little more search engine friendly (url rewritting for prettier urls and hidden javascript calls)
• Added a bunch of new (and old) work into the mix.

Creating a search engine friendly ajax app is a pain in the butt, if it’s an after thought

Installing Apache on Vista
Installing PHP on Vista

Installing MySQL is a no-brainer. Hell, even I could do it.