Converting From WordPress To Drupal
January 9, 2009 – 10:21 am
I decided recently that it was time to check out Drupal. Up to now i’ve been using WordPress for web sites that need a drop-in content management system, but Drupal seems to be fairly widely used, so i thought i should learn how to use it. As part of the learning process, i decided to convert this blog from WordPress to Drupal.
This blog was the obvious choice for the change, as there aren’t many posts or comments and it’s a geek blog so a bit of experimentation shouldn’t put visitors off too much. I did consider writing a php script to suck the data out of the existing mysql database tables and insert it into a new database in the format that Drupal uses – and i probably should have done, really, as it could have been useful in future – but i decided it wasn’t worth the effort as doing it manually wasn’t going to be that hard. There is a Drupal module for importing from WordPress, but it doesn’t work with the current version of Drupal yet.
There are two main aspects of converting a site from one content management system (CMS) to another – the appearance and the data. The first thing i did was to convert the WordPress theme i was using to a theme that would work with Drupal.
Converting the html to a Drupal theme was quite easy. It was mainly just a question of replacing WordPress php variables with Drupal ones (or, for the non-php literate: replacing WordPress tags with Drupal ones). Both CMSs have a similar approach to inserting data from the CMS into the page layout – at least they do if you use the “PHP template” theme engine (Drupal offers a choice of three different theme engines). I used the “Zen” theme as a reference for the variable names.
But converting the CSS was a bit more difficult. The page template CSS was simple, of course, as i had it all there in front of me, but finding out what CSS classes and ids the embedded modules used in their html required a bit of work. I could have read the source code, of course, but an easier way was to use the Web Developer plugin for Firefox. This plugin allows you to outline elements on a page by hovering the mouse over them – and it shows the CSS structure in an information bar at the top of the browser. So, by hovering the mouse over, say, the blog posts list at the top of the right hand sidebar, i could see the class structure of that element and write a CSS rule accordingly.
Getting the functionality that i’d had in WordPress was a bit more of a challenge though. A lot of the built-in functions that i’d got used to with WordPress aren’t built into Drupal. To get a properly functioning blog, i had to download and install quite a few modules. I even had to install a couple of modules just to include an image in a post.
In WordPress, the ability to configure how the URLs are structured is built in and simple to use – in Drupal, you have to install a module. To make the comments form sane enough for my liking, i had to install a custom module (courtesy of francort in the Drupal forum).
WordPress has a very good ajax wysiwyg editor built in, but Drupal only has a very basic text editor. I don’t mind using it myself, but it’s not something i could provide to a client for content management. I tried installing TinyMCE, which is a javascript wysiwyg editor – mainly because it allegedly had the ability to work with images too, but i couldn’t get that aspect of it to work. I wasn’t even slightly impressed by TinyMCE, i’m afraid – it simply didn’t work properly and it mangled the post i tried using it on. So i uninstalled it again. I haven’t checked to see if there are any other options, but i’ll get round to that at some point.
To transfer the content from the WordPress system to Drupal, i just created new posts and selected and pasted the text from the old ones. That was easy as there aren’t many posts in this blog yet. I set the creation time of each post to what it had been originally under WordPress – that bit was easy. There are only four comments so far and i copied those by viewing the posts they’re attached to (anonymously) using a different browser from the one i was logged in with, and used the same details as the original comments. Then in the admin interface i edited them and changed the date and time of posting to match the originals.
And then i was pretty much ready to change over. But at this point, i very nearly decided to stay with WordPress and not do the changeover. I wasn’t very impressed with Drupal and i could see it wasn’t going to be as good as WordPress. Drupal looks a lot more glossy and slick than WordPress does – but underneath the gloss it’s not as good.
In fact, this process made me realise just how good WordPress is – something which i probably hadn’t given it full credit for up until now. I knew it would make my life easier if i stayed with WordPress for this blog. But then, if i’d wanted an easy life i wouldn’t have decided to make the change in the first place. I need to get to know Drupal and the best way to do that is to run the blog with it, so in the end i carried on and did the changeover.
Changing over from WordPress to Drupal brought its own annoyance, of course. With WordPress, it’s trivial to have the WordPress installation in its own subdirectory, below the root directory of the web site. This is much tidier than just chucking all the WordPress files and directories into the site root. Apart from anything else, there are other files in the root directory that aren’t related to the WordPress installation and it makes life easier if you don’t mix them up. But where keeping files out of the root directory is trivial with WordPress, it’s virtually impossible with Drupal – particuarly if you want tidy URLs as well. If you’re interested in this (long running) issue, you can read about it in this Drupal issues thread where one rather pig-headed contributor refuses to see that it’s a problem.
Overall, i’m glad i made the change – not because i like Drupal (i don’t particularly, but i guess i just need to get used to it), but because i’ve learnt a lot by doing it. I’m sure there will be situations where i’ll need or want to use Drupal for content management rather than WordPress and the more experience i can get with it the better. But, although i’m sure Drupal is better for some jobs than WordPress, i certainly wouldn’t recommend installing it for a single-user blog site – use WordPress for that!
I agree, TinyMCE seems a bit dreadful and the photo handling ‘capabilities’ are dire. Even the module originators can’t seem to agree about what you should do to get image uploads to work with TinyMCE. For example, the README file from the tinymce module says:
“NOTE: If you want to use img_assist with TinyMCE, you don’t have to
install a plugin. Just enable the img_assist module and click
the photo icon that appears below each textarea.”
While the INSTALL file from the image_assist module says:
“If you use the TinyMCE WYSIWYG editor, you need to install a plugin for Image
Assist.
* Move or copy the folder ‘drupalimage’ in the img_assist directory to
[sites/all/]modules/tinymce/tinymce/jscripts/tiny_mce/plugins/
…”
I’m still trying to get it to work either way myself.
Having just set up a site in Drupal, I’m not thinking about converting it to WordPress 😉
Ahem, could you edit that last line to read “now” instead of “not”, then look up this page:
http://www.themediadrome.com/content/poetry/wodehouse_printers_error.htm
and decide whether I deserve to be shot.
By the way, is this
http://copwick.net/screenshot.png
another example of Drupal doziness, or what?
Hmmm… I don’t understand the relevance of the link to that poem. But, yeah, drupal doziness definitely.
Having just set up a site in Drupal, I’m not thinking about converting it to WordPress 😉
Having just set up a site in Drupal, I’m now thinking about converting it to WordPress 😉
??
Hi Will,
Nice write up on converting from WordPress to Drupal. I made the switch last year with three of my sites moving some from static to drupal.
I also found the tinymce module did not impress me; it was more likely my understanding of just how it worked. I switched to Fckeditor, although I prefer to use the program Marsedit for writing content and posts.
Drupal is not for the technically challenged. WordPress is very easy to setup and run but does have extremely limited flexibility in my opinion.
To blog with Drupal as I later found out, should not be turned on for a single user. This is where I should have started by posting as a story, not a blog post.
What I find amazing about Drupal is its scalability, you can take it from a single user to just about what ever you want it to become.
Glenn
Thanks Glen.
I started off not installing the blog module – and just writing stories, as you mention. But it didn’t work the way i wanted it to and i installed the blog module, which helped. My main problem, as far as i remember, was the menus. By default, stories get sorted by date – oldest first – but with a blog, the menu should work differently. There may be a way to get the menu to work right with stories, but it seemed to me that i would have to organise the items manually. The blog module created its own menu that works pretty much the way i wanted it to.
I agree with you about Drupal’s flexibility edge over WordPress – that’s exactly why i think it’s important to be able to use it for sites where that flexibility’s needed.
I installed FCKeditor, but it seems to delete all the new lines in the text of an already-written blog post and turn it into one big paragraph. That’s a big problem and it’s meant that i’ve disabled it. It may be ok if i use it to write the post in the first place – and maybe i’ll give it a try when i write the next post. But i don’t want to have to reformat all the existing posts just so i can edit them if i need to! I’ll check out marsedit.
Very interesting article. Thanks
I had the opposite problem with FCKeditor (didnt work at all) and removed it. TinyMCE with Wysiwyg add-on was what made things tolerable. Yes, you can get into module hell for all the add-ons and managing them but that is sometimes better than having a bunch of things added you will never use.
Its compatible with other editors also.
“A Wysiwyg profile can be associated to an input format. A Wysiwyg profile defines which client-side editor is loaded, what buttons or themes are enabled for the editor, how the editor is displayed, and a few other editor-specific functions.”