The weblog software that people seem to choose by default these days is
Wordpress. Wordpress has a lot of features, is widely used and liked,
and is offered as a free single-click install by a lot of web hosting
providers. But several of the Wordpress blogs I follow have been hacked
at some point. When I looked into blogging software, the reason became
clear: Wordpress is a large piece of software, written in PHP, a language
was designed in a world where security concerns
were much less significant, and which has addressed those security
concerns (and other evolving needs) by adding things, not by a
fundamental redesign. (UPDATE: it appears I was being far too
generous to PHP in saying that it had been ‘designed’.) The result is a rather large, complicated
language, which is hard to learn well enough to master all the security
issues. Also, Wordpress uses an SQL database to store weblog entries,
comments, and such, which opens up possibilities of SQL injection
attacks. The single-click install is easy, but upgrading is not so
easy; and if one runs the software for any length of time, one has to
upgrade much more often than one has to install.
A lot of other blogging software, too, uses SQL databases to store weblog data. But databases add complexity; for one thing, to back up a database-driven weblog means issuing special commands to back up the database, in addition to doing the normal backup of the weblog’s files. The added complexity might be worthwhile if there were any real need for a database, but there normally are few enough weblog entries that using a file for each one is quite practical; and once written, they seldom change.
I suspect that the reason why blog software commonly uses databases is
that PHP makes using SQL easy, and doesn’t make other ways of storing
data as easy. In any case, it’s quite inefficient: even though weblog
pages hardly ever change, the PHP/SQL combination means that each time a
user asks to view a web page, a PHP process gets started up (or woken
up), sends queries to an SQL server, receives the results, and rebuilds
the web page using them, adding the headers, sidebar, and other
formatting that the user has chosen. The sidebars often take further SQL
queries. Due to this inefficiency, database-driven blogs are routinely
brought to their knees when they draw huge traffic (as in “slashdotting”
or “instalanche”). Right when a weblog is getting the most attention is
exactly the wrong time for it to fail. There are various optimizations
that can improve this — for one thing, PHP can be
(WSGI) rather than re-started
for every request (CGI); and there are also plugins which cache the
resulting web pages rather than rebuilding them every time. But
installing and maintaining one of those plugins is additional work; and
even they don’t bring the efficiency up to the level that static web
pages naturally have.
Of course you can easily move a Wordpress blog to wordpress.com, and let them handle issues like caching and keeping the software up to date. That’s how they make their money: by selling advertising on the blogs they host, and/or charging those blogs for premium features. The blogging software they give away is not a revenue source; indeed, if they were to make it too easy to maintain, they’d be sabotaging their revenue source.
I don’t grudge them their revenue — the people who write blogging software do need to eat — but personally, I feel like going to the other extreme. Thus this blog is done in PyBlosxom, a small file-based blogging package written in Python, which I’m using in static-rendering mode, where rather than being run each time someone visits, it is run once and generates all the web pages for the entire blog. PyBlosxom’s default mode has the author writing blog entries in HTML; I’m using a plugin that provides for writing them in Markdown.