In a previous post I talked about getting HTTP authentication working when PHP is intalled as a CGI. That, however, begged the question; why install PHP as a CGI? Performance is going to take a substantial hit, after all. The answer I got from the sys admin of one of the servers I was trying was:

- Better security
If a PHP process is compromised, it's only compromised for the duration of the request.

- Upgrades are easier
Upgrading an Apache module requires restarting the Apache server after the module has been replaced. Upgrading a CGI binary simply requires replacing the binary.

Sounds reasonable for low traffic sites. The other server is a run by a hosting company, so low traffic isn't really something on which they can or should rely.

The WordPress 'new post' bookmarklet lets you highlight some text on a page, run the bookmarklet and redirects you to your admin new posts page with the title prefilled with the title of the page you were on and the content prefilled with a link to the page you were on and the text you had highlighted. However, the default layout isn't the way I like to do quote posts, so I had a poke around to find out how to change it.

In the file wp-admin/admin-functions.php there is a function get_default_post_to_edit(). Midway through the function the variable $post_content is set with an HTML snippet. Edit this snippet to how you would like quotes to be displayed.

I wonder what The Right Way to do this is.

Whenever the word ontology is used in a technical context, what is being promoted is likely of limited practical value.

So, WordPress 2.3 beta adds support for AtomPub. All good. I installed it (separately to this blog, I'm just playing around), but all I could get out of the APE was a 401, even though I'd provided the correct authentication credentials. Looking at the code, with liberal use of the logging therein, I worked out that PHP_AUTH_* weren't being set, so I pulled out some auth code and tried it on it's own. No luck. Weird. I then grabbed a previously working snippet and tried that, but it was broken too. On both the servers to which I have easy access. I sent the snippet to Donal, and the snippet worked for him. WTF?

Turns out, that both the servers I was testing on are running PHP as a CGI, not using mod_php, and if PHP is being run as a CGI PHP_AUTH_* aren't available. Who knew? Well, someone, but not me. And they knew a workaround too.

Thanks for your help, Donal! And to all the cool people who are working on this (Elias Torres, Pete Lacey, Sam Ruby, Tim Bray get special mention).

The APE now exercises my beta blog. Now I have to work out why it can't delete stuff ...

Some of the major disadvantages of metadata are its cost, its unreliability, its subjectivity, its lack of authentication and its lack of interoperability with respect to syntax, semantics, vocabularies, languages and underlying models.

Sounds like it has a lot of promise.

I'm finding more and more feeds are being returned from Google. This seems like stupid behaviour to me. You use a search engine to meet an information need. I want to know something about Ferret, I'm likely to use a search engine to find it. Do I want to subscribe to a feed? No, that's way too much commitment. If I find what I'm after and the site looks interesting I'll poke around a bit and then I might decide it's interesting enough to subscribe to.

The correct behaviour would be for Google to return a link to the site from which the feed originates.

The title says it all really. I'm using hpricot for the first time, and the page I'm scraping has quaint uppercase HTML elements, shouting its TABLEs at me. It took me quite a while to work out that I didn't have to shout at hpricot.

In PHP 5.2 the __toString() method is used to convert an object to a string. In PHP 5.1 the __toString() method is used to convert an object to a string but only when print or echo is called on the object. So, doing something like this won't work in 5.1:

foo = bar($object.' won't convert the object to a string');

I've just installed vcscommand.vim, which integrates version control into vim. I was trying it out and was getting the error "No suitable plugin" whenever I ran a command. Turns out this was because I wasn't actually in a working directory, I was in the directory I initially imported. So, remove the directory and then checkout the source, now all good.

When working with Ruby's Find, don't change directories with FileUtils.cd, as Find gets confused. You're better off working with full paths (use File.expand_path).