Customising Serendipity

I started in what some would say is the obvious place: index.php and found line 256 where the view key of the $serendipity array was set to 'entry'. This is the branch of code executed when following the link from the front page to read the whole of an entry. I skipped ahead to the SQL query which is supposed to extract the title of the current entry, and I patched the code to output the text of this query to the page. Running this SQL SELECT statement I confirmed that no results were being returned, which prompted me to actually read the query and saw that the entry $id was set to 2008, a very suspicious number for a blog with less than 100 posts. What I quickly found was that this $id number is getting its value from the 1-th element of the $matches array. Slightly less quickly, I remembered that when the PHP function preg_match is called like this: preg_match($pattern, $subject, $matches) it is actually setting the value of $matches. This meant that a regular expression was incorrectly extracting the year instead of the blog entry number.

To create a sort of minimal test case, I started the barely-usable PHP interactive mode on the command line and produced a session like this:

What is going on here is that my file name format is YYYY-MM-DD_id.html but the regular expression is extracting the initial sequence of digits (up to the first underscore or dash) and assigning this to the 1-th element of the $matches array. Admittedly, that particular file name format was chosen specifically by me, in place of the default, but following these rather permissive instructions:

Here you can define the relative URL structure beginning from your base URL to where entries may become available. You can use the variables %id%, %title%, %day%, %month%, %year% and any other characters.

The quick solution was to simply change the format, which worked, confirming my diagnosis.

As it turned out, I soon started to think about making the Serendipity install accessible at the URL of my old blog, and I realised that I could set up a mod_rewrite rule from URLs of the form http://esuna.co.uk/~hagfish/blog/archives/$id to http://esuna.co.uk/~hagfish/blog/index.php?/archives/post-$id.html . This meant losing the reference to the date of the post in the URL, but now the URLs have the advantage of being incrementable. In case that mod_rewrite rule is useful to someone, it is here: RewriteEngine on RewriteBase /~hagfish/blog/ RewriteRule ^archives/([0-9]*)$ index.php?/archives/post-$1.html [R] It doesn’t make the URLs look very pretty, but it does redirect users and search engine crawlers to the new homes of the old articles, which is useful.

Finally came my favourite change, adding ISO validity to the dates. I was pleased to find a localisation file which lets the user specify locale-specific options (although doesn’t let the user specify separate locales for the strings and the date format), and for the en UTF-8 case the defaults are:

Obviously I was happy with the short format, and experimented with some more verbose forms of it for the long format, but ended up just specifying the same format for both, to be the most compatible with international visitors and standards.

Unfortunately, as with WordPress, there is no localisation option for the archive dates in the sidebar, and this information is burnt into the sidebar code. The first place I looked to fix this was the sidebar.tpl template file, but this made use of a $item.content variable whose definition was not easy to find. Turning to my trusty grep I looked for the sidebar text Older… and found the constant OLDER which in turn lead me to the file plugin_internal.inc.php. In the 'gregorian' case nested inside the 'months' case, I found the offending code. I changed:

on line 482 to:

and that was that.

But isn’t all the formatting of the article still wrong? And what about the syntax highlighting? And the abbreviations? Obviously there are some plugins I still need to install…