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.
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.
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.
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
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.
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