I am preparing to upgrade and redo two Drupal installations this weekend. Already I am beginning to dread the preparation. While I have have spoken about how much I liked Drupal, it’s apparent that they are going through growing pains and should re-assess their coding practices.
I suspect the real problem with Drupal is a complete lack of a cohesive and effective design. One of the things I have noticed with the recent MT upgrade is that MT has better error handling. When MT throws an error you get a error that will allow you to trace back the problem and hopefully fix it. For example when I encountered a number of error with the new templates I had developed for MT. Since I was getting verbose error messages when rebuilding the site, this allowed me to track down the error. This isn’t the case with Drupal. I was getting errors yesterday when attempting install a more traditional forum software package. The solution in the end was to spend some time on the forums at drupal.org and then set my index manager to the system default – yet nowhere did I get a verbose error message telling me that and only found that after an hour or so of searching.. As I prep the upgrade for my Drupal sites, I am pretty shocked at the number of steps required to upgrade. Some of these things are pretty straightforward such backing up your installation before doing something as drastic as upgrading. On the other an upgrade shouldn’t require this much work but Drupal’s development process makes the system a security and management nightmare. I was installing a forum for Mike at appliedepistemology.com (which BTW the Drupal default forms are largely useless – incredibly ugly and impossible to follow a conversation. After getting them working, Mike and I actually prefered the Yabb installation).
Currently Drupal is split into two effectively branches – 4.7.x and the newly refactored 5.X.X branch. The 4.7 branch is the effectively abandoned version – largely because of it’s poor design. To me this is a warning sign in a software project – completely starting a new fork because the old is unsustainable and effectively marooning everyone who has used the product to date is a BAD IDEA. The Drupal philosophy is as follows, “while each new major release of Drupal contains the means for stable and reliable upgrade paths that preserves your data from previous releases, each new release of Drupal provides little or no backward compatibility.” That’s Drupal in a nutshell which means that it’s shaky ground on which to build a community project it’s avowed goal!. Here’s Drupal’s founding programmer Dries Buytaert,
“Given the fact that Drupal’s main strengths have always been the agility with which it can respond to the ever-changing landscape of web development, and the almost infinite amount of flexibility and expansion it affords developers, I feel that preserving the ability to constantly innovate is of higher importance, at the present time at least, than preserving backward compatibility. None of us would be here now using Drupal were it not for this core value, and I strongly believe that it is fundamental to our future.”
In other words I cannot be bothered to design a system properly from the beginning so I reserve the right to do everything again and again. Incidently this certainly accounts why security holes are constantly popping up in Drupal as opposed to Movable Type. In fact it’s pretty common to see giant gaping problems in Drupal development practices. That link is to my current favorite – there is no test suite or even basic unit tests before developers submit “important” patches to Drupal. That’s right we can’t be bothered to see if patches are gonna cause a problem.
If you are going to focus on the “getting the technology right” then you need to get the technology right and not use that as a excuse for sloppy coding practices. But getting the technology right means more than simply re-writing your application every few months. It means spending time developing good development practices. Why would I as a developer spend my time developing for an application that cannot guarantee backwards compatibility for my plugin or application? Drupal sucks for developers unless of course your job is updating and maintaining Drupal installations. Then the billable hours will simply pile up.
I realize that design is hard but if you do it properly you get a platform will scale. For example Andrew Maltsev got the design right for Xao when we developed it. For example it runs the site ISBNDB handling price history on millions of books from over 4 million sources and provides a web service API for developers to use. I suspect that any Drupal installation that tried the same thing would be incredibly slow and simply not work. The point isn’t to toot the horn on the Xao suite, it’s to point out that design matters. When you get it right, you get a platform that you can build on easily and securely.
Movable Type’s upgrade was far easier and much easier than the yet undone Drupal upgrades. I know this because I have already spent more time planning the Drupal upgrades than I did DOING the Movable Type upgrades.
MT has another advantage over Drupal and WordPress. You can build large parts of the site statically which significantly boosts perfomance. I love to read someone saying, “Static builds take more CPU cycles.” Well initially yes but if you factor in the CPU overhead of constantly hitting the database, MT has the clear advantage. Additionally if you get a sudden influx of visitors to your site, you can bet your MySQL installation will be the first thing to go in a shared hosting environment. Hitting the DB EVERY SINGLE TIME is inherently a bad design. Trust me it is. Sure you can retro fit caching onto a WordPress install or enable Drupal’s own caching but retrofitting caching solutions to cover a poor design seems a poor solution to me. Furthermore the verbose error handling and static builds of MT are hallmarks of a good design. When a development team takes the extra effort with an application in error handling, you can get a sense that they will take the same care with the other parts of the application.
I mention the difficulty of long term maintaince with Drupal because I am seeing a lot of non profits use it as their primary community building software because they are saving a few dollars on not actually getting a software license for something like Movable Type. This is pennywise because you will spend FAR more maintaining the installation because of Drupal’s coding practices. Upgrades take far too long and if you have done any custom work on the application, you will never be certain the application will be backwards compatible from one version to the next.
Design matters. Proper architecture matters. To say that they don’t (because you are chasing technology) is silly. Sure Drupal might work when download it today but will it work 6 months from now? How many hours of profession support will you need? I have been running MT and Drupal for two years right now on entirely seperate systems but similar projects. I can safely say that MT is a better solution for a firm with limited IT resources. It’s easier to maintain, provides more robust error handling and few security holes. Drupal might work today – but because of the design philosophy of the Drupal project, it represents a serious risk both financially and in term of security. Look in the end you are going want something robust and supportable.
Digg this entry
Both comments and pings are currently closed.