Backup not found: (A)bort®etry (P)anic

Moving to Drupal

February 4, 2005 - 2:08pm

I’m working on moving CP to Drupal. It’s amazingly easy since someone wrote an importer in Perl that actually uses MT’s own code to get the data and then writes it to the Drupal DB. Even better is that with a simple one-line update to the code it will take the URL that MT gave the entry and give that to the new entries, so all my old links will work.

So, with that done, I work on the template to bring this theme over to Drupal (I did it before for an old version of MG, so I’ll just toy with that one).

So, why Drupal? Well…

Why Drupal?

Drupal is, quite honestly, the king of open-source CMSes. I’ve been using it on several sites and with the conversion of CP to Drupal I will not run a single site off another CMS. It has a quite elegant underlying system, is very modular, and is a dream to hack and write modules for. Even theme creation is straight-forward.

But to talk about why I want Drupal, I need to talk about why I don’t want MT. So as to not make this just about MT, I’ll write about what sucks with the site as-is, since a lot of this is custom code, too.

  1. Page updates are horrendously slow, and getting slower. This isn’t all the fault of the CMS, or my additions; my webhost is getting slower as well. But, in the end, my Drupal sites are even running faster overall, even when I setup Smarty to cache the hell out of my MT pages. I’d move back to static MT pages, but updates go even slower then and the serving of static pages rivals that of Drupal, honestly. Since I do so much with a page (you have no idea) before delivery, I’d rather stay in a dynamic environment.
  2. Unwieldily hacks-upon-hacks. My fault, entirely. Well, almost entirely. In order to get MT to do things I want I’ve had to make it output PHP data structures instead of pages. Those then call a script that does some magic and then calls Smarty, which does some magic and puts up a page. It works, yes, but knowing where in the process to change something has gotten a little arcane.
  3. Statistics. I have a custom statistics script that I’ve put in all the pages. It’s old, broken, and vastly inferior to the system built into Drupal.
  4. It’s Perl. I love Perl, I do, but its days as the web-language go-to-boy are gone. Sorry. And making it work nicely with my PHP scripts was getting interesting.
  5. It’s “public-source” rather than “open-source” software. I despise temptation. Let me hack and share it or, otherwise, compile it and hide it from me. Don’t put me in some middle-land where I can look and touch as long as there aren’t others around to see it.
  1. Commenters cannot choose between Textile and Markdown for their comments. I have to set it for them.

So, other than solving that, what does Drupal bring to the table?

  1. One, local, login. Maintain all your comments, and have a login for the forums as well (which will be un-ignored here soon). Eventually I might entertain the idea of guest articles or whatnot, and this would enable that, without risking a soft violation of some license.
  2. URL re-direction. Simple and flawless, the URL redirection in Drupal is amazing. If I want a node to appear somewhere, I enter the URL I want it at and it appears there. So, when I import all of MT’s stuff the old entry names will stay the same. In fact, when I hack the autopath module for Drupal, the URL scheme will stay the same in the future, as well. Without hacking .htaccess files.
  3. Taxonomy. Oh boy, I don’t have words that bless this enough.
  4. Node-level permissions. If I want a private post in a public blog, I can do it. Indeed, I do, elsewhere…
  5. It’s not WordPress. I hate WordPress.
  1. Off-the-shelf, and with modules from their site, it has all the blogging standards: comments, TrackBacks, XML-RPC posting (with MT extensions for categories, etc.), text filters (Textile/Markdown/BBCode/etc.), RSS and Atom feeds, individual archives, teasers and body content, etc. I don’t have to do without anything I’m used to to use it.

More to come about how I hacked mt2drupal to work with Drupal 4.5 and MT 3.1. There are some tweaks I need to make with TrackBack storage in addition to the URL change.

Why didn’t you use this other CMS instead?

I looked at them all. I’ve used them all. Yes. All of them. The two that came close were XOOPS and Drupal, and XOOPS was … just … inelegant. Drupal is clean. I like clean.

Can I see what you’re working on?

It gets blown away rather often when I’m working on the mt2drupal script, but the sandbox is at www.codepoetry.net/drupal.

Mithras said

When I read the title in my newsreader, I thought you were going with the flow of IT and moving to some province in India! Glad to see I was wrong.

JKP said

Interesting…

I too became annoyed with all MT’s shortcomings and made the switch….care to expand on the statement “I HATE wordpress”? I’d be interested to know why.

Cheers

Jamie

Kevin Ballard said

I’ve been thinking about moving my blog away from MT, but I hadn’t settled on another system. Could you explain why you hate WordPress?

I hadn’t given much thought to Drupal because I thought of it as more than just a blog, and I don’t need anything else. Am I just being stupid? Is it a good choice for a stand-alone blog without any other CMS stuff?

Adam Knight said

WordPress annoys me for several reasons, but there are two major ones (keep in mind this was early on, just post 1.0):

  1. All URL aliases were done with .htaccess entries.
  1. Templates required you to use their PHP code in the templates rather than using a templating engine or something. Dangerous and hokey, especially for newcomers.

There’s more, but I’d have to go look at the page, and I’m fighting some small fires after turning on Drupal here. Was expected, but overall it’s working fine.

karl said

I’m a little lost here. Wordpress does use .htaccess for permalinks, but so does everything else.

Plus WP 1.5 is excellently as far as modularity and the theming “engine” is the best I’d hope for since I particularly don’t like the fact that everyone feels the need to add a layer in between just to slow the creation of a page. This might be more “dangerous” but it’s faster and is a completely PHP workflow so that I don’t have to work around the eccentries of a templating engine.

But since you said there were other gripes, I’m gonna assume there was something bigger, more annyoing, uglier that bothered you. I’d love to know what that was.

Adam Knight said

I’m a little lost here. Wordpress does use .htaccess for permalinks, but so does everything else.

What? bBlog does not. MT does not. Drupal does not. XOOPS does not.

Plus WP 1.5 is excellently as far as modularity

Have you used Drupal? Smiling

and the theming “engine” is the best I’d hope for since I particularly don’t like the fact that everyone feels the need to add a layer in between just to slow the creation of a page.

Drupal doesn’t require it, either. What you see here is a theme I’ve written in PHP. I don’t have to do that, however. That was my point.

This might be more “dangerous” but it’s faster and is a completely PHP workflow so that I don’t have to work around the eccentries of a templating engine.

Templating engines, however, are quite fun when used creatively…

Zama said

Drupal seems like a great CMS. All of the benefits to switching to Drupal from MovableType, however, seem impressive only when compared to the outdated MT infrastructure. A lot of these features already exist in other CMS tools, including WordPress. Speaking of which, I would be interested to hear more about what makes WordPress so evil. The two reasons listed are, in my opinion, not nearly worthy of the word “hate.”

1. The URI structure in WordPress is very clean and future-proof, and I don’t see the disadvantage of using mod_rewrite rules to accomplish this. As far as I understand it, WordPress 1.5 has the ability to assign an arbitrary URI to a given static page. This may not be as flexible as Drupal’s URI redirection, but it is certainly sufficient for my needs.

2. Templating in WordPress has apparently improved as of version 1.5. That said, I don’t have much need to monkey with templating, so this area is simply not very relevant to my particular selection criteria.

I have yet to try Drupal, but following are things that I don’t like about the version of it running on CodePoetry, just based on using the new site for two and a half minutes.

1. Crufty URIs everywhere. Examples:

http://www.codepoetry.net/archives/2005/02/05/moving_to_drupal.php

What if I decide to use a Python-based system in the future instead of PHP?

http://www.codepoetry.net/taxonomy/term/27

Term 27! Sweet! Just the category I was looking for.

http://www.codepoetry.net/node/1669/trackback

I’m sorry, but in my opinion, node numbers shouldn’t be visible anywhere. That kind of cruft is bound to be inconvenient if and when one wants to shift to another back-end system.

2. Feeds are limited. Per-post feeds should be mandatory on any CMS, and yet sadly WordPress seems to be one of the few that has them.

3. HTML output is bloated; scrolling is sloooooow. The comment box here is wider than the content box width (juts out into the background). The W3C XHTML validator lists 27 errors on this entry alone. CSS couldn’t even be validated because of the XHTML issues.

Those are just a few of my first impressions. I’m sure there are other issues I haven’t discovered yet.

I have no fewer than three community-based sites that need to be launched in the few weeks, and after a lot of research, I’ve all but narrowed down the candidate list to WordPress and Drupal. WordPress appears to have the advantage when it comes to cruft-free URIs, per-post feeds, and availability of plug-in modules. Any information about why Drupal should be used instead of WordPress (or the other way around) would be most helpful in selecting the final candidate.

Adam Knight said

Every single “problem” you identify is something either fixable (easily) or by design. I’ve already talked about why I kept the URLs the same as in MT, so that’s moot. They can be whatever you want them to be. The design is mine and my own. I can easily fix the comment box when I care to get around to it. And the URLs to the categories can be over-ridden if I actually gave a damn.

You can nit-pick all you want, and Drupal can take it. You can make it very, very clean and pretty quite easily. I’ve just started using it and got as far as you’ve seen it now in six hours of work to go from MT to this. That’s it. Of course it’s rough around the edges.

This is not an “example site” for Drupal. Drupal.org is. CivicSpaceLabs.org is. SpreadFirefox.com is.

Honestly. Chill. I hate WordPress. Get the hell over it. It’s just software.

Zama said

Wow. Okay, let’s all take a Zoloft. Smiling I honestly didn’t mean to ruffle any feathers — I’m quite earnestly trying to determine the strengths and weaknesses of my two front-runners. That was the only purpose to my post. I have no axe to grind.

I apologize if it seemed like I was slamming the new CP, as that was certainly not my intention. I understand that there are going to be rough edges given the short time frame, and I’m glad that your URI structure reflects your needs and not any inherent Drupal limitations. The URI flexibility you further described sounds promising, as it may indeed provide the future-proofing that is our number one priority.

To be fair, I don’t think I was “nit-picking.” At all. I simply pointed out some things that looked like they might be problematic for our needs. That said, your point about CP not (yet) being an example site for Drupal is well taken. I looked at the other example sites you mentioned. As I expected, none of them have what I consider to be back-end-agnostic URI structures. From what you’ve described, however, it sounds like this is just a case of personal preference and not a URI design limitation in Drupal.

I hate WordPress. Get the hell over it.

Um, get over what? That you hate WordPress? That was never in question. If you’d rather not take the time to explain why you hate it, or if the above two reasons fully explain why you hate it, then simply say so and forget I asked. No need to be rude.

It’s just software.

I know it’s just software. Having been down this migration road before (as you clearly have as well), I’d just as soon deploy a system that makes migration easy should something better come along in the future. I don’t think that’s an unreasonable request.

In any case, I appreciate the additional information. It has convinced me that creating a test Drupal installation and putting it through its paces would be a worthwhile endeavor, which is probably something I should have done before I opened my mouth in the first place. Eye

Jaza@www.drupal.org said

1. Crufty URIs everywhere. Examples:

http://www.codepoetry.net/archives/2005/02/05/moving_to_drupal.php

What if I decide to use a Python-based system in the future instead of PHP?

This URL is completely CP-specific. With Drupal’s “friendly URL” functionality enabled, a Drupal URL would never show the .php extension. I would say that CodePoet has explicitly set his URL aliases to end in .php (although this page doesn’t actually resolve to the file moving_to_drupal.php, it resolves to a Drupal node). I’m assuming that this was done for the purposes of backwards compatibility, i.e. not breaking the URLs used by the old CMS.

http://www.codepoetry.net/taxonomy/term/27

Term 27! Sweet! Just the category I was looking for.

http://www.codepoetry.net/node/1669/trackback

I’m sorry, but in my opinion, node numbers shouldn’t be visible anywhere. That kind of cruft is bound to be inconvenient if and when one wants to shift to another back-end system.

Taxonomy term numbers and node numbers can be very easily (and in my opinion, always should be) aliased with more meaningful URL paths. Take a look at my site, GreenAsh, for an example of how this can be done. Drupal’s new autopath module helps with this, as it forces every new node to be aliased.

2. Feeds are limited. Per-post feeds should be mandatory on any CMS, and yet sadly WordPress seems to be one of the few that has them.

I think the Drupal developers are working on this at the moment… or maybe it’s already developed, I’m not sure. I’m not a big RSS man myself, I consider it more an added bonus in Drupal (feel free to disagree, I’m sure many of you think otherwise, and maybe I’ll soon be joining you! Once I can be bothered to actually try out a newsreader and see how cool it is, anyway).

3. HTML output is bloated; scrolling is sloooooow. The comment box here is wider than the content box width (juts out into the background). The W3C XHTML validator lists 27 errors on this entry alone. CSS couldn’t even be validated because of the XHTML issues.

These presentational issues are all totally CP-specific. Most of Drupal’s contributed (and core) themes are built with validation and standards-compliance in mind. Whether individual webmasters use these themes or not, or whether they hack them into non-validation, is not something that Drupal’s responsible for.

“Do not look at the faces in the illustrated papers. Look at the faces in the street.” — ILN, 11/16/07 – G. K. Chesterton

Syndicate content