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.
I have to admit I'm a bit disappointed in this post. You're blaming the tool, that's fine, go get another tool. It is clear to me a large source of your problems is simply your own hubris. As well, I think you're suffering from too much nerd horror. What you tried to do was dumb, Drupal 6 was released almost 2 years ago and has been in maintenance mode since, and no-one in the Drupal community would ever claim running it with PHP 5.3 in *production* was a good idea.
As well, sure, Drupal is still maintained in CVS but you can get it from git ( git://github.com/mikl/drupal.git ) or svn ( https://svn.acquia.com/drupal/branches/1.x-6.x ). I got those links from 5 minutes of Google-ing. Drupal's problem with CVS is that they have built significant project management infrastructure on Drupal.org around CVS, so moving off is proving to be more painful perhaps than PHP's. They will get there eventually, but you do have options in the meantime, even if you didn't find them.
It feels to me like your real problem was that you didn't take the task seriously, perhaps didn't do much research, and went for a deployment that fit your own ideas of what should work, whether it actually would or not. Isn't that more your fault than Drupal's? As you said, you didn't want it to "take much more time and effort than I have to give". Relationships take time, don't they?
cheers, Jeff
Drupal has Bazaar, Subversion and Git mirrors:
http://drupal.org/node/355154
Although I agree with you that Drupal has some serious flaws and I admit I don't know the specifics of your situation, but this ordeal stinks of poor planning. As such I can't accept that Drupal is solely responsible for your frustrations.
Have you seen this page: http://drupal.org/requirements ?
There is 6.13 (http://montrealers.ca/CHANGELOG.txt) deployed on the website, I really do not think you should complain.
That's exactly the problem I've been facing with CMS's in general. They tend to not be coded in a way that fits with existing and emerging practices in enterprise php development.
I've recently convinced the company I work at to use Zend Framework's MVC structure where possible, but they have also decided to use WPMU for the sites that merge more on content. Sure, WPMU is fine for content sites, but I have the nagging feeling that any change in requirements means the developers will have to hack and hack plugins to change the functionality, and I'm not at all impressed with the Wordpress API. Luckily so far the plugins we have made are content related.
So, the solution I have been trying to come up with, a platform on top of ZF, which will be at least as functional as Drupal, and match Wordpress's ease of use, whilst still paying full attention to non-cms functionality. The trouble is there's not much of that valuable commodity you speak of in my free time, which is also spent trying to learn to be a better developer in general. It really needs to become a open-source project with other contributors and a clear vision.
Oh, I have one more question - have you tried to upgrade from 5.x to 6.x?
I've not looked at Drupal much, so this is not a dig at the people behind it, its community or the code. I'm also not a developer by trade so take my opinions with a grain of salt.
Perhaps what you post indicates is that, for a number of such projects -- and quite popular ones at that -- it doesn't take much before even modest users outgrow the stock offerings and feel the need to add custom code. Whether that's code written by them, or
Is there an easy answer to that one? I suspect not, because as you say yourself, a lot of stuff broke when you upgraded even where the core Drupal app continued to work. (At least I infer that, not least because the site shows something!) No doubt some of it is because people aren't maintaining their bits as quickly as one would like (or at all).
But why could some modules not be updated? Do they depend on deprecated features? If so, there's usually no excuse as warnings about that seem to come far in advance.
Oops. Managed to delete half a sentence, but I think you'll know here I was going with that one!
It may just be that details are missing from the narrative in this story, but why did you upgrade to PHP 5.3 without first seeing what would break on your site? Unless I'm missing something, calendars, galleries and maps don't just disappear.
Drupal 6 has only officially worked with PHP 5.3 for about two months and third-party modules are another story entirely. What's in PHP 5.3 that the Drupal instance absolutely had to have?
This post comes across to me as a statement of conversion and I think the title ("a messy breakup") speaks to that, as well.
Your expectations are not too high—they're just based on the assumption that most people care about code. They don't—they care about functionality and will gladly go to whatever length is necessary—stick with old versions of PHP, run an inefficient site, be exposed to potential security flaws, deal with unmaintainable code and non-existing upgrade paths—to have it. That's how Drupal gets to run the White House's website while the rest of us shake our heads.
Am I right in interpreting from your post that you were crossing your fingers because you were doing the updates on a production environment, and that lack of unit tests/selenium tests etc. helped cause regressions and reduce the predictability of updates? Many php off the shelf applications are not a highlight of technical architecture but what they usually have in common is that they can get things done, easily. PHP itself is a prime example of this. It's not pretty, but it works damn well.
How big is the chance you were going to run into similar issues if you had chosen something other than drupal?
Latest version of Drupal 6 (6.14, released on 2009-09-16) comes with support for PHP 5.3.0 out of the box. The site you mentioned is running on 6.13 (based on the CHANGELOG.txt at http://montrealers.ca/CHANGELOG.txt) which was released on 2009-07-01. So please upgrade to the latest version of Drupal 6 before you start blaming it unnecessarily.
Thanks.
Support for 5.3 was added through http://drupal.org/node/360605, which went into Drupal 6.14, though that didn't really do much to upgrade contributed modules. Several of the backend systems for what drupal.org runs itself are SVN. When drupal.org updates are staged, they come out of a separate SVN repo. The CVS system is still in place in large part because the project module that manages all the automatic packaging for contributed modules is based on CVS. It takes time for a volunteer to come along and upgrade that backend connection.
It's quite common to install Drupal core and contributed modules as a CVS checkout, and then import the checkout, CVS directories and all, into a separate repository management program, like SVN. Then when it comes time to make a Drupal core upgrade for getting things like 5.3 support, all you should need to do is cvs up in the core root and check that back into your SVN repo. Even if you've made custom patches, the syncing is going to be a problem whether you're on Drupal or not.
You could try switching to a package like Habari, but I think you'll find that Drupal is evolving even more in version 7 as a general content engine, rather than a more narrowly focused blogging or news engine.
I wouldn't say that Drupal code is low quality. It's procedural but it doesn't mean it's bad, in fact, once you get used to Drupal's dispatching process and naming conventions it's not hard at all to know what's going on.
I understand it's time consuming and annoying when a piece of software stops working after an upgrade. However I don't see how this relates to Drupal, I have a whole bunch of software (from well recognized vendors) which broke when switching to Vista from XP.
In my humble opinion you should have an "staging" version of the server where you can try Drupal and system upgrades (not security fixes) before upgrading the live server. That way, if you missed Drupal's warning about not supporting PHP 5.3, you would have had an opportunity to see for yourself.
Regarding the "low" quality of some web software, you should have a look to how many of the standard unix style command line utilities are written. Many of them are procedural code, poorly commented or documented. Still they are relied upon by millions to perform any kind of task. The problem I see with web software in general, and open source PHP projects in particular, is that anybody can hack them easily and there are really poor policies to incorporate those hacks upstream. So projects grow very quickly in features but without hardly any actual code reviews or iterations of already implemented features.
This is exactly my beef with home-grown
I've worked in I.T. for almost 20 years and those two features have always been the source of my greatest frustration.
The problem with companies doing things in house is they figure they're paying the programmers anyways so they may as well be programming something so they end-up with a never ending project.
The problem with free software is all of a sudden the developer(s) decide there's something cooler to work on and if you're not ready to move with them you're left with a stagnant system. How many of our favourite programs have ended up in the deadpool because they were essentially one man projects and that man (or woman) gave-up programming for zen gardening or parenting or something.
What about something like Google App's Sites (or just Google Sites stand-alone), Wordpress.com or Square Space? Yes, you have to live with what they give you, and there's still the risk they pull the plug (i.e.: Google Page Creator) but at least there's a clearly defined boundary of what can ≠
The Drupal community was very involved in pushing people to adopt PHP 5.2 as the minimum for hosting, and the forthcoming Drupal 7 will require 5.2 as part of an effort to break with the cruft of PHP 4.x.
The problems caused by PHP 5.3 came as a surprise - and it's not reasonable to blame the Drupal project as a whole for the fact that not all of the (free) community-contributed modules you decided to use are coded to the highest standards. The latest Drupal 6.14 core should behave reasonably on PHP 5.3, but Drupal 6 core and modules are also supposed to still work on PHP 4.4, so it's a rare module maintainer who will have the spare time to test using PHP 4.4, 5.0, 5.1, 5.2, and 5.3 which all potentially break the code in different ways and even have API changes within their minor versions.
Also, if you look you'll see that the new Ubuntu 9.10 has PHP 5.2.10 since the Ubuntu community judged 5.3 as not ready for general production use.
By the way, there are several non-CVS mirrors for Drupal core if you prefer to scratch your itches that way, including:
http://github.com/drupal/drupal/tree/DRUPAL-6
https://code.launchpad.net/drupal/6.x-stable
https://svn.acquia.com/drupal/branches/1.x-6.x
There is also a git mirror of all contributed projects: http://git.drupalfr.org/
though it may get re-imported to fix a minor problem with the date format in the CVS Id tags.
To clear up some things:
- MontreAlers is a *hobby*, not a job. Yes, it was poor planning—it was all the time I could find. If I had more time, I would have written something that exactly met our wants, but I didn't. My point is that it shouldn't require a lot of planning and intimate knowledge of software internals to upgrade a system like this.
- Since it is a hobby, we don't have a lab, staging environment, test suite. I was expecting a system that didn't require a team of developers to maintain. Our budget is exactly $0.
- I don't think that all procedural code is bad. I DO think that in something like a CMS that needs third parties to write addons and plugins should have a better interface than a bunch of non-obvious function calls.
- I upgraded my entire server to PHP 5.3. http://montrealers.ca/ isn't hosted on its own PHP instance. Yes, I had problems with other software when I did that.
- 5.3 was branched over two years ago. In my opinion "the PHP 5.3 changes came as a surprise" is inexcusable for a project as active/large as Drupal. Forward-compatible changes still should have made it.
- Yes, lots of software sucks. Yes, lots of people get things done with it. I was willing to tolerate Drupal until it stopped working.
- People have pointed out alternate version control repositories for Drupal. That's probably helpful to some people, but it's not worth my time if they're not official. And if they ARE official, that was unclear to me.
- It's entirely possible that my admin skills just plain suck. If that's the case, then I have very little hope for most of Drupal's target market.
- Also entirely possible: my search will circle back to Drupal as the least worst of all choices, and I'll have to bite down and spend much more time and effort than I'd like maintaining what should be a simple site. Or we'll put up a couple static pages and call it a day.
Don't worry, Drupal fans, my frustration isn't entirely focused on your beloved. I have an upcoming post on SilverStripe that has a similar message (I didn't even make it through the installer).
Actually, PHP5.3 caused a lot of problems in a *lot* of communities. I've been listening in on some internals lists (not php-internals) and when people started posting the deprecation warnings as errors, the communities didn't know what was going on. In on particular group, they went so far as to suggest the user to submit a support ticket to their provider to fix the PHP installation.
I've seen this happen for a variety of reasons... the project isn't connected with the PHP community as a whole, the project is nearly dead and rarely active, misunderstanding what is going on in the community, small teams without the ability to test new PHP releases, and a variety of other things.
I consider myself pretty well clued in on the general PHP Community and web2project v1.0 (June 2009) was throwing all kinds of notices and warnings on 5.3. In v1.1 (Sept 2009), we were able to suppress those in order stop scaring users, but it's going to be another minor release or two before we can clean up all of them. I only installed 5.3 two weeks ago... I was too busy doing other things.
And then again... the Drupal community (which I'm somewhat part of) could offer the same criticisms of you using 5.x as described above. ;)
Hate to tell you, but you are going to run into third-party plugin issues on every single system you use. That's what you get in the open source community, disparate developers working independently on their own little slices of code. As others have said, Drupal core supports 5.3, so that's a non-argument. The procedural vs. oop argument has been going on for so long now, I don't think it needs addressing anymore. Suffice to say, drupal has a very robust hook system. Would it be better to move towards an oop architecture? Sure. But drupal does a pretty darn good job of procedural code. I'm not sure what you are upset about with the api. There is definitely room for improvement, but everything is clearly laid out. Check out api.drupal.org for more info. At the end of the day, if Drupal isn't the solution you need, then change solutions. I am the last person to force a particular solution. Still, I hope that you will take a hard look at your problems before blaming them on Drupal.
Yes, we know...Drupal is a disgrace to PHP and should be lynched.
Sean, if you circle back to Drupal, let me know. I *will* help you, because I like you and I like beer, and because with any similar system, Drupal also has a lot of tribal knowledge that will make your life easier. For example, it doesn't seem like you're using drush, and that's just wrong.
ps, this blog doesn't have any way of notifying me when posts I comment on are updated. Is this possible with Habari? Ideally, it would be digested and spit out twice a day.
Jeff: Thanks for the offer. If/when I exhaust the other options and haven't given up anything to do with the Web, and become a pro brewer, I'll definitely ping you.
As for comment notification: I think there's a Habari plugin for that, but I don't have it installed...
S
@Jeff: Thanks for the reference to drush. I'm running 3 Drupal sites and I hadn't heard of it. Should make maintenance waaay easier!
Sean,
It is not about being a fan (or not) of any particular project - it just makes A LOT of sens to RTFM before upgrading. You should never take support for new version of programming language/runtime environment for granted.
M.
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 the question of whether a CMS will work at all http://www.sunlightlabs.com/blog/2009/content-management-systems-just-dont-work/
If not maybe a framework is an option.
Otherwise I hear good things about ModX - and Joomla seems to have improved a lot lately.
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
@Jeff Griffiths There's an atom feed for the comments on this post, Right below where it says "25(at time of commenting) Responses to…" there's an icon an text link for the feed.
That's available out of the box in Habari, might be up to the individual theme to specifically provide the link.
Sean,
I can sympathize with your frustration, BUT...
If you thought the Drupal core and ecosystem was plagued with poor code, poor upgrade paths, and broken contrib code stay FAR away from Joomla. Joomla is a fork of the pre-historic Mambo and while the team behind it is valiantly (or foolishly, I can't decide) trying to update the codebase, move it into an MVC infrastructure and whatnot, (all while maintaining backwards compatibility) it's nowhere near ready.
Most of the contrib components for Joomla are quite essentially horrible hacks copy/pasted from the old Mambo code and arbitrarily barfed into a controller class. No components actually work together at all, and most times will break each other (I've had fudged component installs nuke a database, or worse, go as far as to literally cause the site to !!!delete itself off the filesystem!!!). Hell, most components completely code AROUND the core in order to maintain compatibility with Mambo, Joomla 1.0 and Joomla 1.5 in a single component. Often times components will roll their own user management, permissions systems, etc making maintenance a complete nightmare. This doesn't even account for the problem the Joomla community is facing with most of the most worthwhile components being commercial releases (...and even those releases aren't exactly pillars of excellent code... if you can even see the code as a lot of these commercial releases use encryption software).
Like I said, Joomla is making improvements and trying to make shifts in the project's culture, but in it's current state it's near impossible to use without hacking the hell out of it and putting up with inconsistent UI and different ways of doing things in every component you install.
That's not to say Drupal is perfect or excuses Drupal's shortcomings - much like you I often feel like I only use Drupal because it's the "best of the worst", but based on my experiences with countless CMS products, Drupal is the one I keep coming back to. The community behind the project is extremely strong (in fact, I find the strength and collaborative nature of the community uncanny), module developers more often than not work together, not against one another, and while some of the work flows are definitely clumsy, and the admin area is cryptic, I'm happy to say I've deployed several Drupal sites without having to touch a single line of core code to do what I wanted. I can't say the same about ANY other CMS product I've played with over the years.
That said, I'm interested in what you end up choose to use. I'm always on the look for bigger and better systems.
Interesting OP and responses. I haven't upgraded my PHP as I'm still on 5.2.9, but I hope I don't have the experiences that Sean has had with my Drupal sites.
As noted before, there is a difference between core Drupal and third-party modules with the latter varying in the quality of code. The problem is that the average Drupal site can't do without these third-party modules with 50 to 100 of them being necessary for every fully functioning offering.
I really never used Drupal, but have heard that it very usefull,with may options to create a brochureware website, Internet forum, or a community website providing for User-generated content.