The transition was surprisingly simple. The things I had feared the most about moving to a non-Zope system (or at least, a non-ZODB system) are absolutely non-issues with PyBlosxom. The biggest hangup I had with other systems was their reliance on an RDBMS, which I feel I've kinda gotten over since working with Zope/Python. PyBlosxom doesn't at all. All the content resides on the filesystem as plain text files, even the comments.

This was the direction I found myself headed as I was refining just what I wanted my home-grown system to do. With the ZODB, we strive so hard to make the object database mimic a filesystem. For something like this, why not just use it?

PyBlosxom supports (through its plugin architecture) reStructuredText as an entry formatter. I had planned on using reST as the basis for all my entries in my homegrown system. One more reason to just use PyBlosxom. At this point, I think I'll pass on writing my own system (at least for the foreseeable future).

Because it's such a simple setup, I've got my entire PyBlosxom site replicated here on my PowerBook, and when it's time to publish, I just rsync my web directory to my server. I don't even have to use Hobo. Since I'm running Apache locally, I can even vet the whole system before publishing. I had to make some slight changes at the top of my config.py:

import os

host = os.uname()[1]
bits = { 'fbyc.net' : { 'web_dir' : '/home/urbanape/html',
                        'base_url' : 'http://www.urbanape.com' } }

web_dir = bits.get(host, {}).get('web_dir', '/Users/zbir/Sites')

These let me do things like this:

# Plugin directories:
# You can now specify where you plugins all lives, there are two types
# of plugindirectories, the standard pyblosxom plugins, and the xmlrpc
# plugins.  You can list out as many directories you want, but they
# should only contain the related plugins.
# Example: py['plugin_dirs'] = ['/opt', '/usr/bin']
p_dir = "%s/cgi-bin/plugins" % web_dir
py['plugin_dirs'] = [p_dir]

# Where are this blog's entries kept?
py['datadir'] = "%s/blog" % web_dir

# Where should PyBlosxom log files be kept?
py['logdir'] = "%s/log" % web_dir

# What should this blog use as its base url?
py['base_url'] = bits.get(host, {}).get('base_url',
                                        "http://localhost/~zbir")

So that I don't have to change anything else about the system. I can rsync the entries, flavors, comments, and images and have exactly the same setup on my PowerBook. Very keen.

My Apache configuration directive on the PowerBook is contained in /etc/httpd/users/zbir.conf:

<Directory "/Users/zbir/Sites/">
  Options Indexes MultiViews
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Alias /~zbir/images/ /Users/zbir/Sites/images/
ScriptAlias /~zbir/ /Users/zbir/Sites/cgi-bin/pyblosxom.cgi/

The VirtualHost directive on the server is similar:

<VirtualHost 8.7.96.33:80>
  ServerName www.urbanape.com
  ServerAlias www.urbanape.org
  ServerAlias urbanape.com
  ServerAlias urbanape.org
  ErrorLog logs/www.urbanape.com-error_log
  CustomLog logs/www.urbanape.com-access_log common
  DocumentRoot /home/urbanape/html
  Alias /images/ /home/urbanape/html/images/
  ScriptAlias / /home/urbanape/html/cgi-bin/pyblosxom.cgi/
  RewriteEngine On
  RewriteLog "logs/www.urbanape.com-rewrite_log"
  RewriteLogLevel 1
  RewriteRule ^/rdf10_xml /index.rss [P]
</VirtualHost>

That last rewrite rule is to support feed subscribers that are subscribed to my old blog's feed. This way, they'll continue to work.

Lastly, to perform the actual synchronization, I wrote a dead-simple shell script, called sync_blog:

#!/bin/sh

RSYNC='/usr/bin/rsync -urvz -e /usr/bin/ssh'
BASE_LOCAL='/Users/zbir/Sites'
BASE_REMOTE='urbanape@urbanape.com:/home/urbanape/html'

echo 'Synching blog entries and templates... ' && \
    $RSYNC $BASE_LOCAL/blog/ $BASE_REMOTE/blog/

echo 'Synching images... ' && \
    $RSYNC $BASE_LOCAL/images/ $BASE_REMOTE/images/

This forces the sync from the PowerBook to my site. I still need to see whether/how this will affect comments. I don't believe it will, but it's worth testing.

After a brief look into static rendering of the site, I think I'm going to pass for the time being. It seems to prevent commenting. I'm looking for more information/example configurations that allow periodic static rendering, while still allowing for dynamic commenting.