I've finally ditched lighttpd + fastcgi and replaced it with Apache on smurf. Lighttpd was good, but fastcgi was a total dog. It broke all the time and it got to the point that I didn't want to host my friends sites anymore. Every time I went on holidays fastcgi seemed to fall over and all the sites would be down for a day or three.

So I've gone back to the stable world of Apache, although not on the important server. In all the years I used Apache and mod_php it gave me no problems at all. A total rock. I was seduced by lighty's memory footprint, but I was a fool.

I'll move the other server over to Apache as well at some point, the one with Thoughtful Foods and KSAsub.. I thought rewriting all the configuration files was going to be a pain, but it was actually really quick. RewriteCondition with -f is bloody marvellous.

PHP is been pretty slow for me since I left Apache 2 and the PHP code caching behind. I tried turck mmcache with PHP4 and it worked pretty badly. It sped things up, but lighttpd started freezing up every few hours. It was probably FastCGI screwing up and it might have been fixed with FastCGI since then. But I'm all PHP5 now, so I needed to use something else. The Lighttpd guys suggested (and maybe created) XCache so I tried it. It only took a few minutes to install and it's working sweet. Wordpress page loads are down from 300ms to 50ms. I just hope it doesn't screw other things up.

I used the XCache installation instructions but had to do things a bit differently.

1. Downloaded the XCache source from http://xcache.lighttpd.net/

   ~/src $ wget http://... (the release url)
   ~/src $ tar -zxf xcache-*.tar.gz
   ~/src $ cd xcache
   

2. You have to install php5-dev and make if you haven't got them

   ~/src $ sudo apt-get install php5-dev make
   

3. Run the PHP/XCache installation stuff

   ~/src/xcache $ phpize
   ~/src/xcache $ ./configure --enable-xcache
   ~/src/xcache $ make
   ~/src/xcache $ sudo make install
   

4. Edit the php.ini file to tell it where the xcache.so file is located. Mine was at /usr/lib/php5/20051025/xcache.so. You need to edit the xcache.size setting (I used 32M, but others use 64M) and the extension (or zend_extension) setting.

   ~/src/xcache $ find /usr -name xcache.so
   ~/src/xcache $ sudo vi /etc/php5/php.ini
   

5. Check that it's working

   ~/src/xcache $ php-cgi -v
   

6. Restart lighttpd

   ~/src/xcache $ sudo /etc/init.d/lighttpd restart
   

Since moving this blog to SliceHost the page load time has dropped from over a second to 100-200ms. Sweet. I don't even have the cache turned on anymore.

Blogfeed is now Atom-enabled. SimplePie is approximately four billion times better than PEAR fricking XML Feed Parser. And after a brief romance, I've concluded that PHP date() is much, much better than PEAR Date. If only PEAR wasn't so neatly integrated and standardised I'd abandon it altogether.

If anyone is wondering what all this means, it is that Tom, Steve and Anmol can now all come to the Blogfeed party.

I'd be inclined to support a worldwide ban on PHP content management systems that aren't called Drupal. Everything else is kind of shite.

Tom helpfully pointed out that Blogfeed dates were totally borked. I spent a fair while fixing them, and maybe I still haven't. Pear Date sure does suck arse. Timezones are awful horrid things. Quite a few people are an hour out still, but I'm pretty sure that's because they've put 10 in where 11 would have made a better timezone offset. Daylight saving is also a dog.

I've often settled for rather ugly solutions to fatal errors in PHP pages. Without exceptions attempting to find your controller to output some error template always seemed messy. Occasionally I've settled for a die() although I never enjoy it.

Working on some tiny project for Denzil I wangled together this little fellow, which I'm quite happy with. Once your controller has started any PHP error anywhere will get routed through your fatalError() function. So you can put array index errors and that sort of thing into a nice template. If the error is in the template code then restore_error_handler() stops the script from looping around forever.

Another nice thing is that you can call trigger_error() from anywhere and you have a pleasant fatals-only exceptions mechanism. I really should have thought of this a long time ago.

class Controller {
    function Controller() {
        set_error_handler(array(&$this, 'handleError'));
    }

    function handleError($type, $string, $file, $line, $vars) {
        restore_error_handler();
        $this->fatalError("$string in $file at $line"); // or something
    }

    function fatalError($msg) {
        // output nice page with error msg
        exit;
    }
}

I got sick of all the other Wordpress RSS plugins, so I wrote another one. It doesn't use Magpie, because that's been pretty buggy for me. And it doesn't let you have different cache times for different feeds on the same page. This one uses PEAR, which I like more, but it's obviously a shame to throw in the whole of PEAR when Wordpress has tried to avoid it. Wordpress also stays away from classes, and plugins are kind of meant to, but configuring most RSS plugins is an arse.

I think I'm hoping that this will be easier for people to fiddle with than some of the others. I suspect that writing your own function for this could be easier than configuring the ones I've tried so far.

$feed = new Feed('http://del.icio.us/rss/');
$feed->limit(5);
$feed->lifetime(3600);
$feed->simple(); // Or $feed->extended()

There's a shortcut function to make things a bit neater.

feed($url, $limit, $lifetime, $extended);

You'll need XML_RSS and Cache_Lite. It doesn't support anything except RSS either.

wp-feeds.zip

Code Igniter is a really sweet MVC-ish framework. I've been spending my last week of sickness reading about all the PHP frameworks, and fiddling about with some of them. Seagull, Cake and Code Igniter seem to be the best.

Seagull is a bit of a mess, but seems to be built by more practical than average sorts of PHP coders. It has Flexy templates, and over the years I've come to like Flexy a lot. It's not the quickest template language to get productive with, but then none of them really are.

Cake is pretty closely modelled on Rails, and is good.

But my favourite was Code Igniter, even though it doesn't have models in a proper sense. But it's really sensibly designed so it's easy to extend. I find with most frameworks, if you don't do what you're told by the tutorials and manuals, you won't get very far. It's also really light and fast, unlike PEAR-based frameworks, and probably Rails.

But I'm more convinced than ever that Ruby (probably with Rails in tag) are going to take over the world. The only real argument I've heard for using a PHP framework is that not all hosting providers do Rails. Which doesn't bode well for PHP. Who knows how long it's embeddedness advantage will last.

Using the PEAR XML Parser I was able to make a nifty interface to Google Calendar for the Food Coop Roster in about 40 minutes. It uses the Google Calendar API. The built-in syndication stuff Google gives you is pretty average. I even made it a Drupally sort of module. Although at the moment it doesn't do anything very spectacular.

Vanilla is a really nice piece of software, in a field utterly dominated by appalling, bloated, insecure, user-unfriendly crap. Vanilla might not be any more secure than the others, but it's far better in all other regards.

I predict that PHP will go, and Ruby will replace it. For a developer, the only reason to keep using PHP is its transportability. And that advantage will disappear as web hosts realise that PHP only has this advantage going for it and start installing Ruby. I've been looking at the PHP MVC "frameworks", and they're OK, but you wouldn't use them unless you were wedded to PHP. There is nothing in them that people couldn't have developed five years ago. Even if they had, it still wouldn't have saved PHP. Ruby has elegance that PHP seems proud not to have.

I've been tempted to write a secure PHP bulletin board. One currently doesn't exist. The ones that do are ultra-insecure and generally suck. There needs to be one with a proper templating language, so templates don't have PHP code in them. They need to have some better database abstraction, to reduce security bugs. How hard can it be to build a secure system? I reckon they just need to think a bit harder about the design. Which probably means starting from scratch.

This is a complete ripoff of tijs's plugin, but I've replaced the CURL library with the fopen URL wrapper. So it should work with pretty much any PHP install. Of course, it is now marginally less good.

lastfm.zip

Now I'm really going to go study. Or maybe have breakfast. But after that I'll definitely go study.

Update: I installed CURL and now I'm using Tijs's original. fsockopen() and the HTTP wrappers in PHP suck too bad.

Update 2: Now I'm using Yahoo Pipes to get it as plain RSS.