I know, I am behind the times. PHP 5.3 is almost ready for prime time, but I was still using PHP 5.1.4 I was having some major issues with Apache recently, although I don't think it was Apache that was the problem. I wasn't able to diagnose the problem, but I believe connections to MySQL were hanging and causing Apache to choke. It was very sporadic, but as I rolled out a couple sites that made heavy use of MySQL (and not enough use of caching), the problems became more frequent. My server was detecting too high a load on Apache and restarting it a couple of times a day, and every month of so, MySQL would completely choke and require a killall and restart.

My sites get such low traffic amounts, it wasn't like the server was getting crushed under the load. I upgraded to PHP 5.2.6 and MySQL 5.0.67, and no problems since the upgrade (its only been 48 hours). I have a feeling it was PHP, but don't know for sure. So if you have PHP 5.1.4 and are running into Apache choking, try upgrading to the latest PHP stable and see if that cures the problem.

I have recently set up my development environment in a way that mimics my production environment as closely as possible, which is easy even though I develop on Kubuntu and deploy on centOS. For example, I utulize the exact same directory structure and I make use of php.ini file for settings specific to dev, like displaying errors instead of logging them to a file. Additionally, Zend_Config is a nice place to store stuff that may differ, such as displaying placeholders for ads and throwing exceptions in a dev environment.

The one thing I hadn't worked out, was calling the appropriate section of the config file. In my bootsrap file, I had previously used:
$config = new Zend_Config_Ini(APP_PATH . 'configs/config.ini', 'development');
I didn't update the bootstrap very often and when I did, I had to remember to change 'development' to 'production'. I am also running small sites, so a small amount of down time caused by a mess up really doesn't matter.

But I have started working with rsync to deploy my site out to production, and didn't want to have to deal with hand editing the bootstrap every time a change was made. Enter Apache Environment Variables, which allow you to set variables in apache that are available to PHP. in my configuration file specific to one of my dev websites, I put in: SetEnv DEV_ENVIRONMENT development, while in the production server I have SetEnv DEV_ENVIRONMENT production. Now my bootstrap file has a config call like:
$environment = getenv('DEV_ENVIRONMENT');
$config = new Zend_Config_Ini(APP_PATH . 'configs/config.ini', $environment);

Now I don't have to worry about hand editing my bootstrap when I upload a new copy. I think you can put the SetEnv in an .htaccess file if you can't access the main apache configuration file. I just have to learn rsync a little better, and then I will have a nice deployment process, combing Zend Studio for Eclipse, subversion and rsync.

I've just spent more time than I care to in the last couple of days trying to figure out rewriting urls with Apache, both through .htaccess files and directly in the conf file. Today was relatively painless, as I just had to come up with a way to 301 redirect all “extra domains” and some specific pages. For good measure, I also wanted to redirect non “www” domains to the canonical domain and also allow for future, yet unknown domains to be redirected. Here is what I came up with for an .htaccess file:



RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.yourdomain\.com$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301]
redirect 301 /log.php http://www.yourdomain.com/fog.php

Pretty simple – the RewriteCond looks for any domain other than the one specified and upon matching, invokes the RewriteRule. The RewriteRuule simply uses a 301 redirect to the domain. The last line just redirects to a specific page. Looking at the output of Live HTTP Headers for firefox I noticed that it issues two 301 redirects if someone where to type http://www.extradomain.com/log.php. One redirect to get the proper domain, http://www.yourdomain.com/log.php, and then a second redirect for the actual page. Not a big deal, but I thought it would handle it all in one redirect since I wasn't using the L flag. I know, I have a lot to learn when it comes to mod_rewrite...

On a side note, why is it soooo diffucult to get 301 redirects in place from other people. Domain registers seem to only use 302 redirects and whenever I request a 301 redirect for a domain from another company, I either get silly responses like, “You can use the PHP header function to do a 301 redirect” (these are sites with a lots of individual html and php files, not a app running with a front controller) or it ends up being a 302 redirect.


While I am complaining, I might as well mention the bad behavior I experienced while cooking up some redirects. On my Fedora Core 5 desktop, I edited my /etc/hosts to include the domains and then set up a virtual host with aliases for the domains on my Apache server – this allowed me to use my browser and test the redirects locally with Live HTTP Headers. It seemed that the redirects would occasionally get cached somehow? Not sure whether it was my browser or on the server, but I was changing the .htaccess file and the changes would not take effect. If I cleared my browser cache/cookies AND restarted Apache, things seemed to clear up. But I thought Apache read .htaccess file on every request, and thus, changes should instantly take effect? If it was Firefox, then why didn't clearing the cache/personal data have any reliable effect? Maybe it was my desktop? Who knows...