Photo taken by foxypar4 illustrating Coming And Going and has been filed under the Creative Commons license.
Ever stop to wonder how portable your blog is? I mean, you are using WordPress today but do you think you’ll be using WordPressa a year or two from now? What if you started on Drupal and then want to move to WordPress? This is the situation that Performancing is in and I find it rather archaic that many of these publishing systems or content management systems do little in the way of allowing users to export data. The closest I’ve been able to get with Drupal is by using what is called (Views) to create an RSS view for the past 2,500 posts. This doesn’t help me at all when there are thousands of posts from 2005-2008 published on the site. As I searched high and low on the Drupal module site looking for ways to export the content into at least an XML file, I came up empty handed. Considering XML has been around for awhile and it is 2008, I find it to be a joke that Drupal along with other publishing systems do not support the exporting of important content out of the box. Important content being tags, post meta data, post content and comments.
Although not perfect, WordPress provides not only a myriad of different ways to import your content into their system, but it provides you with a way to export your data into an open format. This open format is called WXR or eXtended RSS. When you export your content from WordPress, this XML file will contain your categories, tags, pages, comments, custom fields, categories, and most importantly, your content. This allows you to easily migrate your WordPress content from one WordPress installation into another or, moving between a self hosted WordPress installation into a WordPress.com account. Why can’t Drupal or other systems support this type of functionality? WXR from what I know is an open format because it is based off of XML. I realize that just about every content management system does their own thing, but how nice would it be if they all supported an open format like XML or eXtended RSS.
Based on my research of the various CMS’s that exist, the only one I have seen that supports eXtended RSS is WordPress. Just about every other system out their is portable if you count the fact that they support MySQL. However, in 2008, why must we continue to subject ourselves to hiring MySQL database gurus in order to migrate content from one system to another. Couple this with the fact that most of these systems are open source, why can’t these systems provide an easy way to import or export important data into them and let the end user decide which system they want to use instead of having people become locked into a specific system. Although some will argue that you are not locked in considering if the database that contains your content is MySQL based, you could hire a database guru to migrate your content. I just find that to be unacceptable.
Perhaps there is hope though. Browsing around the Habari Project wiki, I came across a page that contained information regarding potential projects for the Google Summer of Code. Thanksfully, Import/Export appeared to be one of the projects:
Many tools permit one to import from their prior tool, but very few provide any kind of export functionality. The Habari project believes strongly that your data is more important than the tool you use to publish it. To that end, the Habari project would like to initiate a cross-platform export format so that end users can move between publishing solutions with greater ease.
Now, if we could only get every other CMS Development team to acheieve this level of thought, end users would be much better off. No word yet on the progress of the project but I find it enlightening that the Habari team is at least acknowledging the need for such a system.
I think in a perfect world, all of these open source projects such as Habari, WordPress.org, Drupal, etc, would get together and work with each other to make sure that each system could import the data that is exported from each other. Seems to me as if the XML file format provides an excellent open platform for this to be based on. I’m not sure if EGO has any thing to do with this not being a reality yet or if the perfect world is simply too complex for this to happen. Every system does things their own way which is why the initial format should be an open standard instead of something created in-house. What an aggrevating experience it is to see the Drupal forum have an entire section dedicated to migrating to Drupal but not have a forum dedicated to migrating from Drupal.
Please share your thoughts and opinions on this subject within the comments. Let me know if you are sick of being burned by content management systems not providing an easy means of exporting your important content.
Posted a link to the Textpattern forum as the issue is obvious also for the Textpattern CMS. Thanks!
While I sympathize with your situation – I’ve been there and done that many times, both for myself and on behalf of my clients- it’s really simple why there’s no export functionality in most content management systems. There’s no incentive for anyone to provide one.
Since exporting the data for a site implies that the site is moving to some other platform, anyone who is developing or supporting the source platform has no interest in that other platform. If they did, then they would be developing or supporting that other platform.
The only exception to this rule also proves it. WordPress has export functionality because it’s a common task to move from wordpress.com to a hosted solution.
If you wanted to be able to export Drupal to WordPress, I’d suggest that you search WordPress-oriented forums and support sites. You’re more likely to find someone like Urbanworkbench who implemented Drupal to WordPress migration.
I sympathize with you. About a year ago I moved my first blog, a hobbyist blog but fairly popular, from WordPress-hosted to self-hosted, also WordPress. The export function worked great with just a couple minor technical glitches. The big gripe with the WordPress export/import process that most people have is it doesn’t move images. Luckily, I didn’t have an image-heavy site, but if you did, you have a real hassle on your hands. If you’re not a proficient coder to do the work for you, then you have to download/upload all the pictures, then fix all the links in all your posts.
Other than that, WordPress’s export works great and I wouldn’t consider anything else for a straight blog.
I literally just moved from Drupal to WordPress last week on urbanworkbench.com. I mashed together a couple of scripts, but still had some headaches and legacy issues to resolve. Leave me a message (on my contact page) and I’ll send you the database scripts I used – never know, it might be just what you are looking for.
btw – the comment above (by Bas) is spam.
It’s important to point out that perhaps the reason that WXR (“WordPress eXtended RSS”) hasn’t caught on elsewhere is because it’s only based on XML, not actually XML.
There are instances where the output that WordPress creates is not valid XML. While WordPress can easily import this malformed data, it poses a problem for other tools that would either need to duplicate WordPress’ code or rewrite it to include those inconsistencies. This is even more of a problem for tools that are not GPL-licensed, since you can’t just copy the WordPress source to do this, and existing efficient tools for parsing XML won’t help parse WXR. Even worse from an idealist’s point of view, it’s perpetuating a standard that really shouldn’t be one.
More technical info is available here:
Habari would really like to have an open standard for this interchange; one that works. If other tools are willing to help us build it, we’ll certainly throw our efforts behind it.