Migrating from Wordpress to Django CMS

18 February 2012

Previously the Execution Unit website used Wordpress. I was quite happy with Wordpress and I still think it's a great blogging platform. My problem with it is that I wanted more than a blogging platform, I wanted a platform I could easily extend. I"m thinking of offering a free version of MiniTune with a time limited trial so I needed a platform that could deal with generating temporary keys and verifying keys haven't expired.

Having used Django for New Metal Army I looked around for a Content Management System (CMS) that I could deploy on top of Webfaction and Python. Most of the content of the Wordpress site were simple blogs about code and a few on release notes for MiniTune and Max Astro (getting closer to release... I hope).

Two candidates bubbled to the top after a lot of poking around on the internet: FeinCMS and Django CMS. I'd unsuccessfully used Django CMS before but many many people online said it was a good, stable and easy to use system so I set about testing them out.

FeinCMS.

My initial investigations of FeinCMS moved along quickly. I found an example project in a GitHub repository that I cloned and started to play with. The example repository helped a lot because it was a basic CMS with objects and views for a blog. The code is readable and well documented and I started to make quick progress... and then I hit the buffers. It was my usually experience with large Django systems. At first I get weird Django errors which I google and fix only for more errors to be revealed. This gets tedious VERY quickly. I turned to the documentation for FeinCMS and to be honest I just got lost. I'm no Django expert and I'm certainly not an experienced CMS developer. I am however a brilliant python developer and I just couldn't make anything stick. I stopped when I started to get core Django errors about models being out of sync and despite many syncdb --all and migrate --fake calls I just couldn't get rid of them. Frustrated I stopped and moved on.

Django CMS.

My previous run in with DjangoCMS was about two years ago. In fact before I installed Wordpress for Execution Unit I attempted this very same project with DjangoCMS. At the time I became frustrated with the myriad of plugins and resulting incompatibilities that cropped up and I basically didn't get how DjangoCMS worked. This time I spent a little more time going through the documentation.

The first thing to note is that the documentation for DjangoCMS is significantly better than two years ago. The introduction has a fair degree of hand holding but it's not too slow and patronising. There is a gradual introduction to the basic concepts and you build a basic CMS in an hour or so.

DjangoCMS has an interesting set of plugins and once again I came across numerous incompatibilities between Django, DjangoCMS and the plugins, and between actual plugins. This is to be expected but it is still a pain and I wish there was more guidance in a central location to speed up the process. On numerous occasions I found myself installing plugins from GitHub pinned to specific revisions. This makes me nervous and adds a degree of mental overhead. Now I need to keep track of these repositories and look for releases that include the patch I need and hopefully don't break anything else. 

Once I had got passed the plugin problems I actually made quick progress. When the plugins work they really are a considerable leg up and I think they are a real strength for DjangoCMS.

So I went with DjangoCMS.

Webfaction has great support for Django and some help on setting up DjangoCMS. Before deploying I needed to nail down all the revisions of Django, DjangoCMS and it's plugins that I was going to use.

Fortunately I had been using pip to install everything in to a virtual env. This meant I could use pip freeze and pip install -r to rebuild an identical virtualenv guaranteeing happiness.... well nearly.

pip freeze writes to stdout the packages and their versions, my installation looks like this

Django==1.3.1
PIL==1.1.7
South==0.7.3
cmsplugin-blog==1.1.1
cmsplugin-contact==1.0.0
cmsplugin-filer==0.8.0
django-appconf==0.4.1
django-classy-tags==0.3.4.1
django-cms==2.2
django-debug-toolbar==0.9.4
django-filebrowser==3.4.0
django-filer==0.8.4
django-grappelli==2.3.5
django-missing==0.1
django-mptt==0.5.2
django-reversion==1.4
django-sekizai==0.5
django-staticfiles==1.1.2
django-tagging==0.3.1
django-tinymce==1.5.1b2
djangocms-utils==0.9.5
easy-thumbnails==1.0-alpha-21
html5lib==0.90
psycopg2==2.4.4
simple-translation==0.8.6
wsgiref==0.1.2

Django CMS Page Structure 

One of the things I really didn't understand about DjangoCMS when I first used it was the way pages are built. Instead of locking the user in to one markup system a page is made from blocks which are sequentially rendered. A block consists of some text, a picture, a movie, some html or any other media type that you can imagine.

This is very flexible but it makes writing blog posts for example a real PITA. The post gets chopped up in to disparate blocks, you can only view one block at a time and it's difficult to work out where you are going. This really reaches it's nadir when you are trying to write about code and you include code samples, in a code block, and then when you write about the code block you can't see it to refer to it.

I worked around this by installing a plugin for TinyMCE which added code markup and changed the blogging templates to markup any blocks in an appropriate style.

Conclusion

To be honest I didn't plan for this post to be so long and rambling and I'm sure it's a complete waste of time. In the spirit of the internet I will post it anyway.

I don't regret picking DjangoCMS and I am sure I could have accomplished the same thing is FeinCMS. I'll update the blog when I add new features on my travels through the universe.

comments powered by Disqus