From Accessibility to Zope

PHP4 is apparently going to be supported only until the end of the year. The idea is to push developers towards PHP5. Matt Mullenweg notes that PHP4 is adequate for a lot of developers, but also claims that PHP5 adoption is poor because PHP5 hasn’t been marketed properly to developers. I don’t believe this. PHP5 is patently a better language, resolving the single most dreadful language problem that PHP4 exhibits: object copying on reference. Expert developers know this, amateur developers are unaware of the problem and use PHP5 with a kind of religious zealotry.

This migration poses a particular challenge. Rarely does a language change so drastically without offering a simple migration strategy. Vast amounts of legacy code simply don’t work on PHP5. mod_php4 and mod_php5 don’t run in the same Apache instance so it’s not trivial to configure a box to serve some sites with PHP4 and some with PHP5. There is no solution that does not require a lot of sysadmin work setting up proxies, or even virtual machines, and of course, this is not the kind of thing distros do out of the box.

PHP developers seem lacking in conscientiousness about the community they are supporting, as attested by this quote from the PHP4 to 5 migration documentation:

Many PHP programmers aren’t even aware of the copying quirks of the old object model and, therefore, the majority of PHP applications will work out of the box, or with very few modifications.

In fact, that entire subsection of the documentation carries the tone that compatibility problems are inconsequential. I think it’s telling that the PHP documentation can’t produce a complete list of reserved keywords. As the user-submitted comments note, there are at least half a dozen missing from the list.

I’ve also discovered that PHP4 is simply not available for Ubuntu Feisty. While I can understand that there is a genuine desire to move the PHPosphere forward, it’s incredibly dumb to gauge whether people are ready to ditch PHP4 by looking at supported, off-the-shelf web applications, rather than considering the volume of cheap legacy applications. Many people simply need both.

For myself, I’m happy to carry out the migration, but it’s annoying that it’s been handled so badly that my job in doing so is so very much harder. Hard enough that I’ve already put it off for years.

I have just found this expression in some PHP code I wrote around two years ago:

// Call the constructor of the parent class
$this->{get_parent_class(__CLASS__)}();

I’ve never seen this syntax before, and I couldn’t find any reference to it in the PHP documentation. The closest I found was a brief mention that curly brackets could be used to resolve ambiguity in expressions like ${$a}[0]. I have probably pasted it from somewhere after taking a dislike to some of the other ways of calling the superclass constructor (which must be done explicitly in PHP).

This looks like it might be useful in a variety of situations, except that I’m reluctant to use what is, AFAICT, undocumented syntax.

While it has become quite common practice for me to berate PHP, I really never imagined I would come across actual rock-solid evidence that PHP is just one big practical joke the Zend people are playing on me. Noel Edmonds is probably hiding somewhere waiting to pop out and present a trophy, and then pour gunge all over all PHP developers and just generally be weird.

You know classes, right? Those things which are, by definition, not null? That are in fact, the exact opposite of null?

<?php

class TestCls { };

$a = new TestCls();

print ($a == null) ? 'null': 'not null';

?>

Guess. Go on. I’ll give you one guess what PHP prints.

Yes, I know it works if I use a === rather than an ==. But that doesn’t mean the == behaviour isn’t sick and wrong.

RDF makes me feel so liberated now that I’ve actually got it all up and running! Storing data in a freeform RDF graph is so easy when you don’t have to worry about setting up tables or writing queries or anything. Add an arc, remove an arc. It’s that simple.

Liberation is not enough of an incentive on its own, perhaps, but the fact that your web applications are trivially Semantic Web-ready when using an RDF database means that this is definitely the way I will be writing web applications from now on! (Subject to caveats about speed and optimisation and legacy code and pure appropriateness).

In particular, I’ve been able to write a single, easy-to-use class that displays a configurable form, pre-filled from the model, and saves changes back to the model on submit. Code for this looks like this:

$form=new RDFForm($model, $me);
$form->setAction('profile.php?view=basics');

$form->addMultipleFieldMapping(vocab('foaf:name'),
               new StringLiteralProperty(_('Name')));

$form->addFieldMapping(vocab('foaf:title'),
               new StringLiteralProperty(_('Title'), 4));

$form->addFieldMapping(vocab('foaf:givenName'),
              new StringLiteralProperty(_('First Name')));

$form->addFieldMapping(vocab('foaf:surname'),
              new StringLiteralProperty(_('Surname')));

$form->addMultipleFieldMapping(vocab('foaf:nick'),
              new StringLiteralProperty(_('Nickname')));

$gender=new LiteralEnumProperty(_('Gender'));
$gender->addOption('male', _('Male'));
$gender->addOption('female', _('Female'));
$form->addFieldMapping(vocab('foaf:gender'), $gender);

if (isset($_POST['save']))
{
        $form->updateModel();
}

$form->render();

Of course, this is possible with relational databases too given enough layers of wrappers, but this approach makes it trivial to
implement new fields and new field types. Here is a screenshot of how this appears on the page.

Sitting down this evening to code some PHP from scratch after a couple of months of working exclusively in Python, I am stunned to realise how bad plain PHP (PHP4, we’re talking about) is. The shop code provides a fairly comprehensive framework on top of standard PHP, wrapping database, output and error handling. Without it, PHP is so much more dreadful than I remember.

I’m actually amazed that PHP doesn’t print a stack trace when there’s an error. You’re clearly not supposed to write functions.

Perhaps I will make the jump to PHP5. There are compatibility issues even now, but maybe it’s simply time.

I was just working on a set of separate Joomla installations for a client today when I realised that I really needed to be able to run scripts against the different installations.

I was trying to install three different Mambots (one of Joomla’s three different types of extensions) in about 8 installations of Joomla - each with different database configurations and paths, and having started out with a Bash script to merely copy the plugin files into place, I realised that because automating the whole operation would involve reading a configuration file in PHP syntax and performing some queries in MySQL with it, coding this would probably take longer than installing the plugins manually.

There are not very many web apps which have any kind of scriptable API. In fact, I only really know of Mailman, which is only partly a web application. But it’s a feature I’ve used frequently in Mailman - there is a script bin/withlist which acquires locks and opens the list, allows you to modify the list as a Python object, and saves it on exit. Mailman provides a few CLI tools too which can be used in scripting but which are really only trivial examples of the power of the scriptable API.

When I began writing Mailhammer, my own announcement-only mailing list software, I took this scriptability even futher based on my positive experience with Mailman’s scriptable API. All of the working parts are implemented in Python, and the PHP is just an HTML wrapper which opens and talks to a CLI Python script over pipes. This means that the PHP is kept extremely simple, and the Python core is a very clean and simple API, and that the CLI can do everything reliably. It’s a cleanly divided implementation of an n-tier architecture. In fact in practice, I only use the web interface for viewing the data already in the database. Consequently, that interface isn’t very powerful - yet!

Python is well-suite for scriptable APIs - its interactive interpreter and neat object model mean that it’s easy to perform arbitrary operations interactively on complex, persistent data structures. In PHP web applications it might be more feasible to build an XML-RPC interface of some kind and provide a command-line client.

I don’t think that scriptability is considered as even a potential feature for almost any web application I’ve tried; their operation is tied inextricably to their unique interfaces.

For anybody developing a new web application please ask yourself this: will administrators using your software want to be locked in to your pretty and easy-to-use interface, or will they end up cursing you for failing to provide them with power beyond what HTML can provide?

Another case of PHP segfaulting. This time, at least, it was behaving deterministically and by inserting

print "Meep!";
flush();

throughout various bits of the code I managed to track down the problem. It was segfaulting trying to read a config file to which it didn’t have read permissions.

PHP is bad.

One of my old online friends, Twisted, messaged me this morning to say that he was having problems with his installation of Mauvesoft Gallery. He had reinstalled in on a new Ubuntu box but it was not thumbnailing properly: first it was not generating thumbnails; then, having fixed that, he found that it was not caching them.

Anyway, I tarballed up my unstable development version, 1.5, which adds a few features and fixes a few bugs.

Changelog

• Feature: PHP-based templates
• Feature: Watermarking of thumbnails
• Feature: Images now support EXIF captions and titles
• Theme: New theme ‘corporate’
• Theme: ’slides’ rewritten in XHTML and CSS
• Bug: Thumbnail transparent PNGs with GD
• Bug: .JPG extensions not considered images
• Bug: Directory names containing ‘+’ character
• Bug: Imagemagick engine doesn’t work with CMYK JPEGs

He installed that and after a few permissions bugs, it’s up and running.

I suppose this makes it almost ready for an RC. The first alpha is already running on a site I did a couple of months ago for a client, Photography2you.

When I actually package this for release I’m going to use shar, which I am fairly confident I can use to configure the installation after it has unpacked. All webapps suffer from this installation problem, and there doesn’t seem to be a generic solution for installing them, even though there is a very limited range of things that need to be configured to get them off the ground on a single-vhost basis. I can’t imagine that it would be hard to write a package manager for them. Mauvesoft Gallery works on Windows and even IIS too I believe (although I’ve not tested it recently), but Windows is much more lax on the permissions (although I’ve not tried Server 2003), so a normal ZIP file may suffice.

It also occurs to me that as part of this shell-based installer I could offer the user the option to scan their $HOME and symlink any directory it find containing photos (for some definition of photo… perhaps JPEG image over 1 Megapixel?) into the Albums root. Zero-configuration installs here we come. The goal is to make Mauvesoft Gallery simpler to install and use than any other gallery software.