Movable Type vs. Drupal
February 23rd 2007 Posted at Design
14 Comments 
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.
This article is a bit of a head-scratcher. MT is an excellent bicycle, but it will never be in the same class as projects like Drupal, Alfresco, or even Joomla!. It’s a static blogging application with a plugin architecture; comparisons to WordPress and Blogger are more appropriate. Its feature list has remained static for years, with minor bug fix releases coming out on occasion.
In addition, you seem a bit confused the difference between ‘abandoned’ and ‘no longer the latest.’ Drupal 4.6 and Movable Type 2.x (both about 3 years old) are ‘no longer supported.’ Drupal 4.7 is simply ‘no longer the latest.’ Though it’s been superseded by Drupal 5.0, is still supported and receive security and bug fixes as needed. Much of the development community’s work now focuses on Drupal 5 modules and themes, just as there are few people working on plugins for old versions of Movable Type.
SixApart makes no promises about plugin compatability between versions, either: look at the number of plugins out there that are only compatible with specific point-releases of MT. (3.0 only, 3.1 only, 3.2 only, etc.) This doesn’t mean that it’s a good thing: it’s definitely something that needs to be considered. I’m baffled, though, by the suggestion that it’s an advantage for MT.
Also… huh? There was no ‘fork’ in the Drupal project, any more than Movable Type 3.3 was a ‘fork’ of version 3.2. Version numbering is, as I mentioned, a pretty standard convention.
The Xao project seems to be an example of your ideal: in seven years, it has received a handful of minor 1.0.x updates. If what you have works, why update? Just because Drupal 5 shipped doesn’t mean you have to install it. That is ‘chasing technology.’
Couple of comments here Jeff –
“Much of the development community’s work now focuses on Drupal 5 modules and themes, just as there are few people working on plugins for old versions of Movable Type.”
So in other words it is largely abandoned. I spoke to at least two other IT people who have felt the same way about the 4.7 – namely they feel abandoned. In an open source project resources are limited and 5.x and 4.7 are far different than than naming conventions. Eventually patches for the 4.7 fork will dribble off.
As far as Xao goes it never received the critical mass it needed to succeed as a project – it’s built on Perl and Perl programmers have less of need for something like Drupal. Drupal is far more open as it’s built on PHP. My point about Xao was that with the proper design you can do a lot of things – and I would ask you to show me a site the size of ISBNDB (in terms of data set size) built on Drupal.
“It’s a static blogging application with a plugin architecture; comparisons to WordPress and Blogger are more appropriate.”
Except of course many people are installing Drupal largely as a blogging platform. In fact here’s a quote from the Is Drupal right for you. The first use listed is as a blogging platform. Drupal has other uses as mentioned on that same page but quite frankly Drupal has a jack of all trades, master of none feel to it. You COULD use as an ecommerce platform but it makes more sense to an ecommerce platform for that. It’s most common uses are as blogging platform where it’s clearly substandard and online community building (and I don’t think it’s great for that either. But I like to roll my own)- and I feel it’s development and security model are too high a cost to maintain. While many people are using Drupal in many ways – it’s most common function as a blogging platform where MT is clearly a better platform.
I was big fan of Drupal – I built two seperate sites using it. But you have got to admit that it’s a real bear to upgrade and maintain and that’s largely a function of the development practices of the Drupal team. I might be just upset I am spending this weekend upgrading Drupal. But I know my MT upgrade was far easier.
Look perhaps the real question is what are you using Drupal for? If you are a developer and can maintain the installation it’s not too bad. You are going to have headaches. The problem is that many entities who do not have the resources to maintain a Drupal install are using it and most of the time these people are just blogging with it. In that case you would be better off with MT.
Like the blog Jeff, especially the dual blogging with you and Catherine. Nicely done – it’s gives a nice visual on what’s going on in both your lives.
Agreed, Brian — and I think that’s a lot of the confusion. My wife wanted a simple blog setup for her and a friend of hers (www.castlenowhere.com) and it made sense to use MT for it; they didn’t need any of the advanced dynamic stuff.
Having worked with a number of other CMS systems, and Movable Type, I just disagree that upgrade hassles are inherent to Drupal’s development methodology. They’re inherent to any system that’s been customized with a lot of plugins, modules, and site-specific enhancements. The Movable Type 2.x-3.x upgrade absolutely killed me for that very reason — I was using quite a few custom plugins, a highly customized template, and a number of tweaks to get around the limitations of statically built pages.
That’s why I moved to Drupal — I was building dynamic knowledge management tools for an online game, and ‘blogging’ was a small slice of the functionality.
There are quite a few sites with millions, even billions, of records out there using Drupal. I think that’s probably not the right metric to use, though: in modern web apps, ‘number of records’ is less useful for choosing the right tool than ‘desired interaction model.’ For a site like ISBNDB, though, it looks like you had an extremely focused design and didn’t want a lot of end-user interaction; while it’s *possible* to build a site like that in Drupal, Drupal is probably also a bad fit for it. It doesn’t need any of the features that Drupal really brings to the table, so the overhead would be pointless.
Static HTML files will always be more efficient than dynamic ones, but for most dynamic sites, static ones just won’t do. It’s like saying that Layers in Photoshop are bad, because they’ll always be slower and less efficient than a flat image file. Building a site like MTVUK’s Flux with statically generated pages would be hellaciously painful. It’s about picking the right tool for the job.
I’m sorry if I seemed to come down hard on the post. đŸ˜‰ I’m a big believer in the idea that Drupal’s dev community needs to honestly assess its flaws and recognize which ones need fixing and which ones are simply necessary design compromises. I just think that a number of the issues you’ve mentioned are not “Drupal” issues, but “Dynamic Web App” issues.
There are couple of the things that struck me about the Drupal development model.
1.The intentional disdain for backwards compatibility. That seems to me to reflect a certain design mind-set.
2.The lack of a testing suite for developers committing patches. This is just asking for trouble.
Those two items are signs to me anyway that Drupal needs to re-evaluate some development practices. I know that sounds harsh but it’s my opinion.
The business reasons for Drupal are varied but I often get requests for help from entities who have no business running Drupal. They have no internal IT staff so after a year or so they are running something with quite a few holes in it. Drupal needs more care and feeding than these entities can provide. Look at your own post on your Drupal to-do list
http://jeff.viapositiva.net/node/466
“Drupal for Boggers: Way back in the day, a custom fork of Drupal 4.4 called ‘Drupal For Bloggers’ added some cool features like trackbacks, a template based theming engine, and more. Maintaining a fork is a huge pain, though, and most of its features were rolled back into Drupal core or became contrib modules. D4B fell into disrepair, and was never updated to stay in sync with new versions of Core. Now, it’s time for a packaged Drupal profile that pulls together the same functionality with standard Core and contrib code. Akismet spam checking, Trackback integration, Flickr and del.icio.us integration, and a clean theme engine for non-coders like PHPTal would all be great components.”
Drupal is really being used quite a bit as blog/frequent publishing platform because it’s free. That’s what I suspect the #1 use of Drupal is, yet the D4B branch died.
Look branches die off in open source software because the developer whose itch was getting scratched moved on or perhaps found another itch. But you can’t say these sorts of things don’t create problem for users – they do.
As I read more about Drupal 5 it’s apparent that the Drupal team is taking steps in the right direction.
drupal is more than a blogging platform dude.
It’s interesting that you think Movable Type can handle the same types of sites that Drupal does. I ran MT sites for about three years and finally moved away from the platform because of its limitations.
Yes, it does a good job of building simple sites. Its multiple blogs can me massaged into a content management system but it simply lacks too many content presentation formats that Drupal makes easy. And Drupal also makes it easy to add custom forms and data display for different sections of the site.
They’re simply not the same sort of animal at all. Movable Type is a solid platform and yes, its static pages lessen server load. Ever wait while it rebuilds 2000 or so pages? Ever had a network crash in the middle of such a rebuild and have to re-install the db? There’s scaling on the server and scaling for the publisher. They aren’t necessarily the same thing.
Having installed at least three Drupal sites I am well aware that it’s more than a “blogging platform”. However most people are installing it as a “blogging platform”. And there are a number of people installing Drupal who probably shouldn’t such as small non-profits.
I never claimed that Drupal and MT handled the same type of sites. I merely claim that many of the people installing Drupal would be better served by an MT installation and that many of the people installing Drupal are doing so simply for blogging and an actual blogging platform might be a better choice. Additionally the statements by the Drupal developers themselves hardily inspire confidence about the stability and upgradability of a Drupal installation. Look what I said about Drupal two years ago I used to regularly defend them.
SixApart makes no promises about plugin compatability between versions, either
Actually, they go to great pains to ensure backwards compatibility. Of course, they’re not going to give you a guarantee; they didn’t write the third-party plugins.
Incidentally, the number of plugins broken by upgrades is very small. There are (non-trivial) plugins that haven’t been touched in four years that still work perfectly.
specific point-releases of MT. (3.0 only, 3.1 only, 3.2 only, etc.) This doesn’t mean that it’s a good thing: it’s definitely something that needs to be considered.
Erm, those are base requirements. You’ll have to provide a specific example if you’re claiming there’s plugins out there which will only work with 3.1 or such.
There is a big difference in terms of design philosophies. Drupal actively disdains backwards compatibility. MT actively tries to maintain it. Big difference in long term stability of the application.
Interesting post, but more interesting comments.
Having done all three platforms, plus Blogtronix recently, I have some thoughts on this.
I just moved my company onto Drupal, http://www.teqlo.com and very much appreciate the features in Drupal that make for easy content authoring and integrated website management.
My personal blog, http://www.jeffnolan.com/ is on WordPress 2.1.1 and I very much like the management console and ease of posting, plus the straightforward approach to themes.
I implemented MT3.2 for the internal SAP blogs (Apollo) and at the time selected MT because of the robust mgmt console for managing multiple authors and blogs. I didn’t like the static nature and having to rebuilt the site after even minor changes.
Blogrtronix is what the http://www.enterpriseirregulars.com site it built on and while the checkin of posts via RSS is very cool, the aesthetics of the site are pretty weak, and there are no easy to use facilities for changing that. More to learn on blogtronix, we’re just launching this site.
Sorry for the late comment – you had more than 3 URLs so you were marked as “spam”. It’s interesting that you used Drupal for teqlo.com – it looks better than any single Drupal installation I have seen. More importantly Teqlo itself looks very interesting (probably a blog post all by itself). I will be looking at it more later tonight. Let me know how you feel in a year about maintaining that installation.
As far as the static nature of MT, you can configure it to publish dynamically. I would rather have the performance boost of static publishing. Thalasar.com is hosted on it’s own box so I don’t have as much of a problem with rebuilds. I can imagine that’s it’s a real problem with a shared environment and certainly wouldn’t want to run it there.
yeah, my blog flags anything with more than one link as possible spam. Damn spammers have made life difficult for everyone!
Thanks on the positive comment about the Teqlo site. It was quite a bit of work getting it going because we had to integrate it with our service. We now have a drupal module for Teqlo login and session management, I’m thinking about putting out to the community. CodingClan worked with us pretty intensely for about a month to get everything done right.