Sean Coates: PHP, Web (+Beer)

Earlier this week, I wrote a piece on why I'm no longer willing to tolerate Drupal. It got a lot of traffic (for my blog), and a lot of comments.

Most of those comments were "classic apologetics" as one person put it, and upon reading them, I realized that I may not have done the best job of making my point (which boils down to: Drupal takes more effort to maintain than I'm willing to spend). If you missed it, I replied to most of the complaints.

Of all of the comments, though, one really stood out, and rang truer than anything else I've read on this topic:

“I think the problem isn't so much that Drupal didn't work with PHP 5.3 - it's that the Drupal upgrade process is so bad.

In fact there isn't much of an upgrade path for Drupal at all unless you stick only to core (and who does that?)

Drupal has too much "tribal knowledge" of it's own—too much is decided on IRC where it isn't available to more casual users.

More importantly Drupal has rejected great chunks of the tribal knowledge of programmers: OOP helps move projects towards self documentation - while design patterns speed understanding of a new system. In fact Drupal rejects so much that it has even implemented it's own bug tracking and project management tools built on Drupal—that have handcuffed Drupal to CVS for far too long.

Drupal is great for people who don't like programming, who can live with the user interface and don't care what the data model looks like.

It is possible to download Drupal and quickly build a rough prototype with little prior knowledge—or if you really invest in learning the Drupal way you can do pretty much whatever you want with it.

But if you're a programmer at heart and want to use/develop transferable skills maybe Drupal isn't the best tool.

...

There is some awareness of these problems within the Drupal community:

• http://dc2009.drupalcon.org/session/why-i-hate-drupal
• http://www.slideshare.net/walkah/why-i-hate-drupal

”

— Sean Burlington (reposted with permission)

Sean (the other Sean) did a much better job at conveying the point than I did. I think he really hit the nail on the head when he called it "Tribal Knowledge."

More of his thoughts on Drupal.

In my search for a replacement for Drupal, I started playing with SilverStripe over the weekend.

The site looks pretty good, the demo—while minimal (which is totally fine by me)—seems to work decently. It made my "to test" list.

The bottom line:

FWIW, SilverStripe made my "do not recommend" list today. )-:

coates

A bunch of people replied asking "why?" This is my response to those people. My intent is not to bash SilverStripe, but to explain how it fell short of my wants and needs, quickly.

First stop: the code.

SilverStripe is built on a framework called Sapphire, which is developed by the same folks as SilverStripe (a bit like the CodeIgniter-Expression Engine relationship, I guess). A [very] quick look through the tutorials had me interested, and the actual functionality of SilverStripe seems to be something we could work with. I downloaded it, unpacked the archive, and dove straight into the code.

Again, maybe my expectations are too high.

Here's an excerpt from the root index.php.

<p><![CDATA[
// For linux
$_SERVER['SCRIPT_FILENAME'] = str_replace('/index.php','/sapphire/main.php', $_SERVER['SCRIPT_FILENAME']);
$_SERVER['SCRIPT_NAME'] = str_replace('/index.php','/sapphire/main.php', $_SERVER['SCRIPT_NAME']);
// And for windows
$_SERVER['SCRIPT_FILENAME'] = str_replace('\\index.php','\\sapphire\\main.php', $_SERVER['SCRIPT_FILENAME']);
$_SERVER['SCRIPT_NAME'] = str_replace('\\index.php','\\sapphire\\main.php', $_SERVER['SCRIPT_NAME']);
 
chdir('sapphire');
require_once('sapphire/main.php');
]]>

The useless str_replace calls aren't a huge problem, but they demonstrate sloppiness. It's easy enough to detect whether or not we're on Windows (hint: the PHP_OS constant) without redundantly replacing everything twice.

What really got my attention was the chdir call. They must have some reason to do this, but it's almost certainly a bad one. At the very least, it should have a comment indicating why they'd do something weird like this.

Next, sapphire/main.php (excerpt; the first two executable lines in the file):

<p><![CDATA[
$majorVersion = strtok(phpversion(),'.');
if($majorVersion < 5) {
...
]]>

This raised all kinds of warning flags to me. Maybe they're worried about PHP_VERSION constant being missing from some old versions of PHP (to their benefit, the manual doesn't say when this was introduced), and that's why they've decided to use the phpversion() function. There is, however, a function built in to PHP to compare versions: version_compare(). That's the safest way to do this. A more obscure, but faster way to handle this is to check if a function or class only defined in 5.x exists.

.htaccess also hints at something weird:

<p><![CDATA[
<Files *.ss>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Files>
]]>

"What's this *.ss stuff?" I wondered. It's SilverStripe's templating system. I didn't even bother to see how they're interpreted, but they're apparently not PHP-based, with syntax such as <% base_tag %> and $SilverStripeNavigator (the latter was not within tags of any sort).

I made it through barely a handful of files before deciding to just plug my nose and ignore the code, hoping that I would be so blown away by the functionality that I would forget what lies under the covers.

I tried the installer. It complained that I didn't have the mysql extension built. Fair enough, it's true. I didn't have the mysql extension. I did have pdo_mysql and mysqli but no, I didn't have the ancient extension installed. I expected better.

Once I rebuilt PHP with mysql-proper support, I went through the installation process, and when it finished, I was redirected to a page that said "The requested page couldn't be found." So, I gave up.

I could probably fix that problem, and none of the other problems on their own are insurmountable, but combined, they leave me with the impression that the code isn't what I'd like to commit to maintaining.

The search continues...

A little over two years ago, when I got involved with the MontreAlers (note: yes, site broken... read on), the homebrewing club in Montreal, I was quickly nominated to be the sucker who would help take their aging and mostly-neglected web site, and make it somehow useful.

At the time, the choice was simple: custom code or Drupal. Because custom code takes quite a bit of the most valuable commodity in life—time—and because I had (and continue to have) very limited spare time, I chose Drupal.

I hacked together a custom theme (based on one of the prepackaged templates), spent a few hours configuring modules, and spent probably an equal amount of time shaking my head at the procedural and poorly-designed (for small values of "design") plugin/extension API. I grabbed some pre-built modules, and cobbled together a reasonable community site. We didn't need much, and Drupal + a few plugins solved most of our problems.

The site was a hit. Membership in the club has climbed from a handful of members to what's often a troublingly large number of attendees to our monthly meetings. There's no direct correlation to the site, but I think all of the MontreAlers would agree that it has played a role in connecting with new likeminded people.

As with any project whose maintainer doesn't have sufficient available time, the site got dusty over the course of the first few weeks, then dirty over the next few months, and before we even realized, the site was in a state of partial disrepair. Databases were upgraded, hardware was swapped, DNS was migrated, and PHP versions were updated. Each of these tasks of regular maintenance were met with heightened amounts of finger crossing, cursing and furious patching. After upgrades or changes, I'd usually get inquiries about why certain functionality mysteriously stopped working, which often lead to more furious patching, cursing and finger crossing.

Over time, minor inconveniences can easily snowball into what seems like one large, insurmountable problem. The last straw for ongoing my relationship with Drupal was upon upgrading the PHP version on my server to 5.3.

Admittedly, 5.3 is fairly young, but I was ready to take on the challenge. I'm handy enough with PHP's changes that I felt confident that I'd be able to take on any problems that Drupal presented. The obvious first step, here, was to update Drupal to the most recent release. I don't remember the exact date of the upgrade, but I do remember my feelings clearly. It was the day I started actively searching for a Drupal replacement.

The upgrade was extremely painful. There was no clear path to upgrading from our old, stagnant Drupal install to the newest version. Updating the code was a bit painful, but possible. The Drupal upgrader/installer did take care of the database update, which was my biggest worry, and there was some documentation on how to do this on the Drupal site, but I had to dig pretty deep to find it (and I've since lost the links, so I apologize that I can't link to the references I used).

There were two main pain points: I had to manually patch Drupal to work on PHP 5.3, and some of the third-party Drupal modules the club now depended on were not possible to upgrade.

The patching for PHP 5.3 was not entirely unanticipated, and was reminiscent of making fixes in broken array_merge()s when jumping from 4.3 to 5.0. The real problem here is that Drupal still maintains its code in CVS, so I gave up on submitting my patches upstream shortly after diffing and trying (to no avail) to find their subversion or Git repository. I thought PHP was the last significant project to move from CVS to SVN, but I was obviously wrong.

I fully expect Drupal will (or maybe already has) catch up to the current release of PHP (aside: they had plenty of notice to get their code up to speed—PHP 5.3 was certainly long in the tooth by 5.3.0). The real problem with the latest upgrade was that some of our modules not only didn't work with the new version of Drupal, but there was often no available upgrade for them. Our event calendar went missing, user maps (home addresses for club meetings) disappeared, our photo gallery is completely AWOL. There may be suitable replacements (read: alternative functionality in other modules) for some of our wants and needs, but the fact remains that maintenance is painful, and "upgrades"—often for the purpose of plugging security holes—take much more time and effort than I have to give.

The underlying code in Drupal is old. It seems brittle. It doesn't do things I'd expect modern software to do such as have a good inheritance model (hint: it's [almost?] all prodedural code), have self-documenting or intuitive APIs, and it does tons of things that I simply don't care about (I'll probably blog on this last thing as a general poisonous open source trend in another episode). It's more pain than it's worth at this point, and I just need it out of my life.

So, Drupal, we're breaking up.

But I don't have anyone else to go (more on my short list in a near-future entry).

(Here's the rhetorical paragraph.) Is it too much to ask for PHP code to actually be well-written? It doesn't even need to be perfect. Habari is certainly far from perfect, and it has warts, but on a whole, it's good code. Is the barrier to entry for most projects too low? Or is there just a huge lack of experience in knowing how to do things right? Maybe all of the best people are too busy doing other things? Or maybe it's a community-management problem...? I don't know.

When it comes to software, and especially web software, I find myself always settling for "Least Worst." Habari is Least Worst. Trac is Least Worst. MediaWiki, PHPMyAdmin, Roundcube: all arguably best-in-class, but under the hood, they're often painful. I suspect my expectations are simply too high. Should I just lower them? I don't know that either.