UPDATE: 4/7/11 !!! IMPORTANT !!! Read the comments between Julien and I below before installing or deciding to install Zinnia. It's far easier than I lay out in this post. I'm leaving here for reference of what not to do :) --Mark
After writing so much lately about Django and Python I felt silly doing so on a hosted WordPress blog. So for no good reason, I started investigating Django blogging engines. I decided to go with Zinnia. It's an app, which means I can include it in other projects I have already started or going. The documentation is fairly complete (or seemed to be) and it's still supported / in development. The main missing ingredient is multi-blog support, which is possibly in the works.
If you've decided on using a Django blog and Zinnia is your choice, I'll let you in on a couple secrets that may save you some time during installation and conversion from WordPress, if that's where you're coming from.
There are three ways to install Zinnia, all which will load all of the dependencies for you. When I did this on my Apple Macbook (for development/testing purposes) I ran the pip install, copied the Zinnia project code from /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia (where it installed), placed that code in my project and put the proper lines in my settings.py file. All of that was pretty seamless. When I updated templates (to change the look) I saw the changes immediately on my local python runserver.
I repeated this process on my production Arch Linux machine, the application acted differently. When I updated my live server with the updated templates, I didn't see any of the design changes. Restarted apache, still nothing. So I ran the zinnia pip install again, restarted apache and whaddyaknow, there were my changes. On the production machine, it seems like Django/Python ignores the "zinnia" installed app in settings.py and runs the code/templates from the site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia folder. Since I didn't want to have code in there and have my project live in two places, I deleted the site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia folder and make a symbolic link to the zinnia folder in my project.
ln -s /path/to/your/project /usr/lib/python2.6/site-packages/django_blog_zinnia-0.8-py2.6.egg/zinnia
Now my project lives in one place and Zinnia works as it should. Yay!
Another thing that impressed me about Zinnia is that it includes tools for converting to and from WordPress. When I exported my WordPress xml file, ran the script and started getting errors:
xml.parsers.expat.ExpatError: unbound prefix
I was starting to think I'd made the wrong decision going with Zinnia. This time though, the problem was on Python/WordPress. WordPress exports with this xmlns information in the rss tag:
If you add this line:
The error magically goes away. I found that solution on StackOverflow. It wasn't a horrible process once I found the couple of gotcha's, so don't be afraid to ditch WordPress!Share on Twitter Share on Facebook