I apologise for my last post on this topic, it probably wasn't very interesting :-)
I've done the Drupal 6 upgrade, and it was relatively painless. Most modules ported smoothly, a few required me to learn how to port modules to Drupal 6, and one I just gave up on.
On the whole, the porting is simple, Druplal.org has a pretty good howto on the topic. A few APIs have changed, and that's about it. A great tool to help with this is the coder module, which knows about the API changes, as well as Drupal's coding standards.
I've added the GeSHi module for code syntax highlighting (apologies for the planet-spam caused by this), and I've moved from marksmarty to markdown + typogrify (which I had to port to Drupal 6). I'm not too happy with the geshi colour-scheme and indenting, but it does a good enough job. I should write a "command prompt" mode for it, but that can wait for now...
Akismet is currently totally broken for Drupal 6, even if it's labelled as being in beta. I got about half way through porting it before giving up and switching to mollom, which looks like a pretty good replacement (and it takes care of the sign-up form too).
Finally, the subject of input-filters. Drupal lets you define a "default filter", but that filter has to be available for everyone, even comments. So your default filter has to protect against XSS. I'd much prefer it if commenters used a simple, locked-down input-format, and I used a nice markdown format.
I'm not the only one to notice this, and it seems like it'll be fixed in Drupal 7. Until then, I'm using remember-filter which remembers that I use markdown, and all the commenters use the default, locked-down filter. (Again, ported.)
I had to patch a few modules for Drupal 6 support, but it’s really easy to do. I only waited this long because most of the modules I used took a while to get Drupal 6 support, but in retrospect, I needn’t have.
I host a few websites for various people and causes using Drupal, as described here. Now I’m feeling the urge to work on Drupal stuff again, and hope to make some big improvements to this site soon. I’m thinking Activity Stream type stuff for a start (thanks Vhata).
In other news, I have been helping a house-mate set up a website for his magazine in WordPress. I’m amazed how much PHP you need to mangle to get wordpress to do what you want. Watching someone who has no programming experience at all do this stuff can be both entertaining and depressing. What a terrible introduction to programming… The WordPress API scares me, it uses URL-encoded parameters to many functions for a start. And php isn’t exactly a well-designed language.
Well, I suppose I learned to program in BASIC 2.0 - everyone has to start somewhere…
This is my script for migrating from Wordpress to Drupal. I know that there is already a migration script out there, but I still wrote my own for a few reasons:
So here it is.
Limitations and bugs:
wp-). This is messy, but while Drupal’s multi-database system is a cool and would be perfect, it’s unworkable when you are debugging. Errors seem to be hooked in drupal, and if you have a broken SQL query (for example) the error handling code hooks Drupal themes, which aren’t findable in the alternate-db world you are visiting.
As should be obvious to non-feed readers, I’ve migrated my blog to Drupal. This fits in with my greater plan of organising myself and moving into digs this holiday. Drupal is an awesome CMS - or maybe a better description is “the only decent CMS”. I’ve set up and maintained a few drupal sites, and have been very impressed with it.
I’ve yet to migrate all my previous blog-posts across, but by the time you see this post, that’ll be done. Vhata has walked this road before me (albeit from Serendipity), and I intent do follow his advice.
In the past, I mantained my Wordpress blog as an SVN install. This allowed me to install plugins with
svn:externals, which made upgrades a doddle. Drupal uses CVS, so this approach wasn’t an option. After months of procrastination, I investigated config-manager. With it, I built a recipe for downloading drupal and all the modules I use with it. Then I committed this as a bzr tree, so that I could base all my sites on a common base. To install a module, I
bzr mv modules/foo drupal/sites/all/modules/.
Now to update all my drupal sites, I update my
config-manager recipe, and build a new master tree. Commit it to the repo, and push to launchpad. And then
bzr merge in all the sites. It’s pretty quick and painless.
For anyone who’s interested, the modules I’m using are:
So far I’ve had to write a drupal module to support amatomu, and it was a bliss. Drupal’s API and code is some of the neatest PHP I’ve ever had to work with.
I think I’ll be happy here :-)
Todo list (Things amatomu does that I don’t care for, and thus haven’t coded):
Available from Drupal.org. Releases for Drupal 5 and 6 are available.