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:
<rss version="2.0"
xmlns:excerpt="http://wordpress.org/export/1.0/excerpt/"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:wp="http://wordpress.org/export/1.0/">
If you add this line:
xmlns:atom="http://www.w3.org/2005/Atom"
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!
Hi Mark,
I like your article on Zinnia :), but I think that I need to add a complement of informations.
Your installation and customization processes are too complicated.
Normaly once the installation of Zinnia done, check that the application is accessible in the PYTHON_PATH.
$ python manage.py shell
>>> import zinnia
>>> zinnia
... <module 'zinnia' from '.../zinnia/__init__.pyc'>
So you don't have to make a copy or a symlink of Zinnia's code.
Secondly if you want to customize the templates of the blog to change the look and feel, you don't have to modify the source of Zinnia. (If you have to do it so, we cannot say that is a generic and reusable app).
You simply have to put your customized templates in a directory linked by the TEMPLATE_DIRS setting of your django project if you have enabled the 'filesystem' template loader.
More informations at :
http://docs.djangoproject.com/en/1.3/ref/templates/api/#loading-templates
So if you want to change the template of the detailed view of an entry, copy the 'zinnia/entry_detail.html' template bundled in Zinnia and paste it at this place for example :TEMPLATE_DIRS[0]zinnia/. Your modifications should be visible directly.
About the wordpress export file, this error occurs only from exports coming from wordpress.com. If you have your own instance of wordpress, it should be OK.
Julien, thanks for the response. You're 100% correct, your way is far easier!
I uninstalled django-blog-zinnia, removed all of the zinnia folders in my project and went through the reinstall process:
pip install django-blog-zinnia
I put the apps back in my settings.py file:
'tagging', #zinnia
'mptt', #zinnia
'zinnia', #zinnia
I copied /site-packages/zinnia/media/zinnia folder to my /media folder and added "ZINNIA_MEDIA_URL = "/media/zinnia/" to my settings.py file.
Then I added a zinnia folder to my templates folder that's specfied by TEMPLATE_DIRS in settings.py. I overrode two files in there, skeleton.html, to update some text and entry_detail.html to add the linebreaks filter to the comments section, {{ comment.comment|linebreaks }}.
Thanks again for your support and great software!