Yet Another or fix DokuWiki blogging?

What requires less time? Writing a new blog generator or fixing your old? — I can tell you my answers were changing rather often within the last 12 hours :-/ Eventually, I ended up fixing my blogs (including this one here) running on DokuWiki and the blog plugin.

Since many years, I am happily using DokuWiki for documentation and to publish scripts and such. In 2007, I started to also use the blog plugin for blogging about technical stuff. I love the simplicity, and the plain text flatfile backend. However, the experience has always been rather troublesome. Plugin updates often broke the layout, had vulnerabilities, needed fixing, or just didn't work.

Naturally, I was constantly looking for alternatives (why abuse a wiki for blogging anyhow?). I was hoping to find a simple, static blog generator that I could run from the command line. Of course, there are plenty. Strangely enough, though, when looking closer only very few withstood my criteria. As time passed by I started to sketch out some ideas for writing my own blog generator: Yet Another Shell Blog Engine (YASHBE) sounded like a cute name :-)

Eventually, I created a comparison table. At first, doing so seemed to be a very good idea because my first thoughts were "Oh, look, the DokuWiki thing is not that bad after all" and "Well, my own code could do a lot if I wrote it." – To cut a long story short, reviewing alternatives, writing the comparison table, researching and fixing the problems with DokuWiki took more than 12 hours. If I had started to code YASHBE right away I guess I would have finished it by now, too.

• The blog index page was partly broken and looked horrible which is why I updated it manually for some time. Fortunately, thanks to work by Michael Hamann that was fixed in the "blog" plugin. {{blog>blog?7&nouser&permalink&noeditbutton}} provides reasonable results for me.
• RSS feeds could only be called broken. Apparently, older versions of plugin:feed could be used for blog posts but I could'nt get this work with the current version.¹⁾ The documentation recommends to use DokuWiki's native RSS syndication, however, results were unacceptable.
• Archive pages looked horrible, workarounds using plugin:pagelist didn't fit my bill.

After reading the source code of feed.php I found that actually there is a way to exclude "media" (file uploads). It just wasn't documented. So,

[[this>feed.php?ns=blog&linkto=current&content=html&mode=recent&view=pages&num=7|Blog posts]]

was pretty close to what I expect from a blog feed: Pages only (no uploads), linking to the current version. Due to a bug num=7 is ignored, but the feed delivers at least 5 entries which should be sufficient.

Update of 2013-04-21: feed.php delivered less than 7 entries because the number of matching entries in meta/_dokuwiki.changes was lower than 7. See my comment on DW bug #2765.

Unfortunately, the titles of the feed items include the "edit summaries". So, if I fix a typo in a post entitled "Feed woes", and if I document this in the edit summary, the feed item will be e.g. "Feed woes - typo fixed". This is hard-coded in feed.php, line 227 in the "Adora Belle" version. I've added && ($_GET['ns']!='blog') at

if($conf['rss_show_summary'] && ($_GET['ns']!='blog') && !empty($ditem['sum'])) {
    $item->title .= ' - '.strip_tags($ditem['sum']);
}

This or a similar switch should do.

Update of 2013-04-21: Today, I found that the "blog" component of plugin:feed works quite OK and I doubt that it is going to be removed (as it says on its web page). So, one can use e.g. {{blogfeed>blog?7|Blog posts}} to get a feed of 7 items without the need to hack feed.php. However, the {{blogfeed...}} shows only abstracts, not full text entries.

Update of 2013-04-21: The feeds produced by plugin:feed have a hard-coded favicon.ico pointing at lib/images/favicon.ico. Consider to add the file, hack plugins/feed/feed.php or add e.g.

RewriteRule ^lib/images/favicon.ico   /favicon.ico [L]

to .htaccess.

For SysAdmin'ish Blog Archive I use {{archive>blog?2013-*&nouser}} etc.. This generates an HTML table for each year. Since these are separate tables the column widths vary. It's just cosmetics but IMHO it really hurts. I could use {{archive>blog?*&nouser}} to generate 1 large table for all entries but I wanted the year headlines. The following CSS improves the look (on my template):

/* make tables full width */
table.pagelist { width: 100%; text-align: left; }
/* reserve some fixed width for the page titles */
table.pagelist td.page { width: 47%; }
/* make date and comment columns non-wrapping and non-expanding */
table.pagelist td.date, table.pagelist td.comments { white-space: nowrap; width: 1px; }

Added 2013-04-21

I wanted to add this as a reminder (to myself and whoever cares): I am normally much in favor of recycling and fixing the old instead of getting new stuff or re-inventing things. However, in this case it seems like if I had started to write my own program right away, without checking out alternatives, without making a list of what I actually disliked about the old solution, without researching bugs and whether they might be easy to fix, by now, I would have a working solution, too, plus a lot of hacking fun and the joy of learning new stuff (my plan was to use Markdown and Bootstrap).