+++*

Symbolic Forest

A homage to loading screens.

Blog : Posts tagged with ‘blogging’

We can rebuild it! We have the technology! (part one)

I said the other day I’d write something about how I rebuilt the site, what choices I made and what coding was involved. I’ve a feeling this might end up stretched into a couple of posts or so, concentrating on different areas. We’ll start, though, by talking about the tech I used to redevelop the site with, and, indeed, how websites tend to be structured in general.

Back in the early days of the web, 25 or 30 years ago now, to create a website you wrote all your code into files and pushed it up to a web server. When a user went to the site, the server would send them exactly the files you’d written, and their browser would display them. The server didn’t do very much at all, and nor did the browser, but sites like this were a pain to maintain. If you look at this website, aside from the text in the middle you’re actually reading, there’s an awful lot of stuff which is the same on every page. We’ve got the header at the top and the sidebar down below (or over on the right, if you’re reading this on a desktop PC). Moreover, look at how we show the number of posts I’ve written each month, or the number in each category. One new post means every single page has to be updated with the new count. Websites from the early days of the web didn’t have that sort of feature, because they would have been ridiculous to maintain.

The previous version of this site used Wordpress, technology from the next generation onward. With Wordpress, the site’s files contain a whole load of code that’s actually run by the web server itself: most of it written by the Wordpress developers, some of it written by the site developer. The code contains templates that control how each kind of page on the site should look; the content itself sits in a database. Whenever someone loads a page from the website, the web server runs the code for that template; the code finds the right content in the database, merges the content into the template, and sends it back to the user. This is the way that most Content Management Systems (CMSes) work, and is really good if you want your site to include features that are dynamically-generated and potentially different on every request, like a “search this site” function. However, it means your webserver is doing much more work than if it’s just serving up static and unchanging files. Your database is doing a lot of work, too, potentially. Databases are seen as a bit of an arcane art by a lot of software developers; they tend to be a bit of a specialism in their own right, because they can be quite unintuitive to get the best performance from. The more sophisticated your database server is, the harder it is to tune it to get the best performance from it, because how the database is searching for your data tends to be unintuitive and opaque. This is a topic that deserves an essay in its own right; all you really need to know right now is that database code can have very different performance characteristics when run against different sizes of dataset, not just because the data is bigger, but because the database itself will decide to crack the problem in an entirely different way. Real-world corporate database tuning is a full-time job; at the other end of the scale, you are liable to find that as your Wordpress blog gets bigger as you add more posts to it, you suddenly pass a point where pages from your website become horribly slow to load, and unless you know how to tune the database manually yourself you’re not going to be able to do much about it.

I said that’s how most CMSes work, but it doesn’t have to be that way. If you’ve tried blogging yourself you might have heard of the Movable Type blogging platform. This can generate each page on request like Wordpress does, but in its original incarnation it didn’t support that. The software ran on the webserver like Wordpress does, but it wasn’t needed when a user viewed the website. Instead, whenever the blogger added a new post to the site, or edited an existing post, the Movable Type software would run and generate all of the possible pages that were available so they could be served as static pages. This takes a few minutes to do each time, but that’s a one-off cost that isn’t particularly important, whereas serving pages to users becomes very fast. Where this architecture falls down is if that costly regeneration process can be triggered by some sort of end-user action. If your site allows comments, and you put something comment-dependent into the on-every-page parts of your template - the number of comments received next to links to recent posts, for example - then only small changes in the behaviour of your end-users hugely increase the load on your site. I understand Movable Type does now support dynamically-generated pages as well, but I haven’t played with it for many years so can’t tell you how the two different architectures are integrated together.

Nowadays most heavily-used sites, including blogs, have moved towards what I supposed you could call a third generation of architectural style, which offloads the majority of the computing and rendering work onto the user’s browser. The code is largely written using JavaScript frameworks such as Facebook’s React, and on the server side you have a number of simple “microservices” each carefully tuned to do a specific task, often a particular database query. Your web browser will effectively download the template and run the template on your computer (or phone), calling back to the microservices to load each chunk of information. If I wrote this site using that sort of architecture, for example, you’d probably have separate microservice calls to load the list of posts to show, the post content (maybe one call, maybe one per post), the list of category links, the list of month links, the list of popular tags and the list of links to other sites. The template files themselves have gone full-circle: they’re statically-hosted files and the webserver sends them back just as they are. This is a really good system for busy, high-traffic sites. It will be how your bank’s website works, for example, or Facebook, Twitter and so on, because it’s much more straightforward to efficiently scale a site designed this way to process high levels of traffic. Industrial-strength hosting systems, like Amazon Web Services or Microsoft Azure, have moved in ways to make this architecture very efficiently hostable, too. On the downside, your device has to download a relatively large framework library, and run its code itself. It also then has to make a number of round-trips to the back-end microservices, which can take some time on a high-latency connection. This is why sometimes a website will start loading, but then you’ll just have the website’s own spinning wait icon in the middle of the screen.

Do I need something quite so heavily-engineered for this site? Probably not. It’s not as if this site is intended to be some kind of engineering portfolio; it’s also unlikely ever to get a huge amount of traffic. With any software project, one of the most important things to do to ensure success is to make sure you don’t get distracted from what your requirements actually are. The requirements for this site are, in no real order, to be cheap to run, easy to update, and fun for me to work on; which also implies I need to be able to just sit back and write, rather than spend long periods of time working on site administration or fighting with the sort of in-browser editor used by most CMS systems. Additionally, because this site does occasionally still get traffic to some of the posts I wrote years ago, if possible I want to make sure posts retain the same URLs as they did with Wordpress.

With all that in mind, I’ve gone for a “static site generator”. This architecture works in pretty much the same way as the older versions of Movable Type I described earlier, except that none of the code runs on the server. Instead, all the code is stored on my computer (well, I store it in source control, which is maybe a topic we’ll come back to at another time) and I run it on my computer, whenever I want to make a change to the site. That generates a folder full of files, and those files then all get uploaded to the server, just as if it was still 1995, except nowadays I can write myself a tool to automate it. This gives me a site that is hopefully blink-and-you’ll-miss-it fast for you to load (partly because I didn’t incorporate much code that runs on your machine), that I have full control over, and that can be hosted very cheaply.

There are a few static site generators you can choose from if you decide to go down this architectural path, assuming you don’t want to completely roll your own. The market leader is probably Gatsby, although it has recently had some well-publicised problems in its attempt to repeat Wordpress’s success in pivoting from being a code firm to a hosting firm. Other popular examples are Jekyll and Eleventy. I decided to go with a slightly less-fashionable but very flexible option, Wintersmith. It’s not as widely-used as the others, but it is very small and slim and easily extensible, which for me means that it’s more fun to play with and adapt, to tweak to get exactly the results I want rather than being forced into a path by what the software can do. As I said above, if you want your project to be successful, don’t be distracted away from what your requirements originally were.

The downside to Wintersmith, for me, is that it’s written in CoffeeScript, a language I don’t know particularly well. However, CoffeeScript code is arguably just a different syntax for writing JavaScript,* which I do know, so I realised at the start that if I did want to write new code, I could just do it in JavaScript anyway. If I familiarised myself with CoffeeScript along the way, so much the better. We’ll get into how I did that; how I built this site and wrote my own plugins for Wintersmith to do it, in the next part of this post.

* This sort of distinction—is this a different language or is this just a dialect—is the sort of thing which causes controversies in software development almost as much as it does in the natural languages. However, CoffeeScript’s official website tries to avoid controversy by taking a clear line on this: “The golden rule of CoffeeScript is: ’it’s just JavaScript’”.

Relaunch!

It's a new day, and so on

Well, hello there! Time to start all this up again.

This blog has been dormant, for, what, the best part of a decade I think. I started a second blog all about gardening in the hope it would get me to write more in general, but this site stayed quiet. I started a Tumblr, and even managed to post things semi-occasionally, but that faded away much as the whole Tumblr community has faded too. I thought, though, midway through a rather unusual year, that it might be time to get this site going again.

My biggest motive this time, really, is that I don’t like the way the internet has been going over the past ten years ago. The old, open Web has been closing down, drifting instead toward megacorporation-owned walled gardens where you are trapped inside a corporate app that discourages you from leaving. When those walled gardens start to shrivel up and wither, what happens? Look at Facebook; look at Twitter; look at Tumblr and its steady decline. The days of the independent blogger are gone; most people now who do want to do some form of blogging will go to Wordpress.com, or Medium, or to a site like Dev.to if they’re technically minded. So me, being contrarian, decided to become an independent blogger once again.

A few things have changed. I’ve redone the design to hopefully look reasonable on a phone, because that’s what most people use for their casual reading nowadays. I’ve taken away comments, for a few reasons: it saves me the effort of worrying when people leave controversial ones, and it saves me the sadness when they inevitably don’t leave any at all. On the technical side, I’ve ported everything over to a static site generator, so everything loads in a flash. At some point I’ll write…

The Plain People Of The Internet: My lords! Will they eversomuch be bothered about all that technical gubbins? Or is it all so much tumty-tumty verbiage, like?

Me: I wondered if you lads were still around, you know. I’m sure some people might be interested.

The Plain People Of The Internet: Lads? Lads? Now there’s not very inclusive of you, is it.

Me: Fair point, Plain People.

As I was saying, I’m sure some people out there will be interested in long technical posts about how the site is now built and structured, and although most of my technically-minded blog posts end up on my employer’s website nowadays, it may well be that some technical topics are more suited to this place. In general I suspect there will end up being more of the longer, more considered essay-type posts on here, and fewer of the one-liner posts about how I don’t have anything to say. And, as you’ve already seen, I’m sure that if my meanderings start to become too diffuse and unfocused, they will be interrupted by the Plain People Of The Internet, who at some point in the distant past escaped from a Flann O’Brien newspaper column and now seem to live somewhere in the collective hive-mind of the global internetwork.

The Plain People Of The Internet: Now there’s a word you don’t hear very often. Fair rolls off the tongue.

A whole load of the aforementioned one-liner posts have already been culled from the archives. This isn’t exactly the British Library or some great tome of record, so I’ve removed things from back in the mists of time where I was only posting to meet some arbitrary and self-imposed target of posting on a certain schedule. I’ve also gone through and cleared out a whole heap of dead links, and spotted a host of spelling mistakes that have been sitting there out in the open for everyone to see for years. There are probably many more dead links I missed checking, and many more spelling mistakes I’m still to notice, but I’m reasonably happy with the state of things as they stand. As well as deleting a pile of stuff that was here previously, I’ve also added stuff that I’d previously posted to Tumblr, such as my thoughts on what Amsterdam is like, or the experience of watching my father die. Hopefully, some people other than me will think these things were worth saving.

I’m aware that previously I’ve posted things that say: “Well, hello there! Time to start all this up again,” and then have stuttered slowly to a stop within a few days or weeks. Let’s see how it goes this time.

The Plain People Of The Internet: By sure, we will.

Curious problem

In which FP has an obscure font problem, in annoyingly specific circumstances

Only a day after the new garden blog went live, I found myself with a problem. This morning, I noticed a problem with it, on K’s PC. Moreover, it was only a problem on K’s PC. On her PC, in Firefox and in IE, the heading font was hugely oversized compared to the rest of the page. In Chrome, everything was fine.

Now, I’d tested the site in all of my browsers. On my Windows PC, running Window 7 just like K’s, there were no problems in any of the browsers I’d tried. On my Linux box, all fine; on my FreeBSD box, all fine. But on K’s PC, apart from in Chrome, the heading font was completely out. Whether I tried setting an absolute size or a relative size, the heading font was completely out.

All of the fonts on the new site are loaded through the Google Webfonts API, because it’s nice and simple and practically no different to self-hosting your fonts. Fiddling around with it, I noticed something strange: it wasn’t just a problem specific to K’s PC, it was a problem specific to this specific font. Changing the font to anything else: no problems at all. With the font I originally chose: completely the wrong size on the one PC. Bizarre.

After spending a few hours getting more and more puzzled and frustrated, I decided that, to be frank, I wasn’t that attached to the specific font. So, from day 2, the garden blog is using a different font on its masthead. The old one – for reference, “Love Ya Like A Sister” by Kimberly Geswein – was abandoned, rather than wrestle with getting it to render at the right size on every computer out there. The replacement – “Cabin Sketch” by Pablo Impallari – does that reliably, as far as I’ve noticed;* and although it’s different it fits in just as well.

* this is where someone writes in and says it looks wrong on their Acorn Archimedes, or something along those lines.

The Extension

In which an annex is announced

As you can see, as I’ve mentioned more than a few times already, this site has been fairly quiet for the past few months, since we’ve moved house. We’ve come up with a cunning solution, though. Start another blog!

It’s not really a separate blog; it’s more of an annex to this one. A separate side-project, with rather more of a focus than this rambling monstrosity,* with a specific topic, rather than whatever I can conjure up to make 500 words of. The idea being, a narrower topic will make ideas come more easily. It is: The Symbolic Forest Gardenblog.

Gardening posts on this site — all none of them — will now appear over on the gardening blog. Gardening-related photos will pop up over there too. Anything I write that isn’t about gardening, that will still be over here. Keeping it in this domain might end up a bit confusing, because forest gardening is a recognised genre that is almost entirely unlike our garden so far. Hopefully readers will pick up that it’s the Symbolic Forest Gardenblog, not the Symbolic Forest Gardenblog.

* and it’s not going to have footnotes, either.

With Difficulty

In which we muse on how hard it is to write something with all the distractions the modern world has to offer

There’s one big problem with computers and pervasive connectivity. The problem is: it’s all at your fingertips. Which means, when you sit down to do some work, it’s all too easy to realise that there are other things you’d rather be doing; and there are a lot that can be done there and then.

In a lot of cases that’s straightforward to solve: disconnect yourself. It’s a bit trickier, though, when it comes to writing blog posts. Particularly, the sort of blog posts that need fact-checking, more information, and so on. Once you have to start doing that, you start getting sidetracked down a line of “research” which is very interesting and distracting, but doesn’t really help you with getting your blog post written. The inspiration fades away amid a mass of non-information.

What I’m going to have to do, I think, in order to get this process going properly again, is to make more notes. Get a notebook, and find a place far away from the internet. Hide my phone. Lie back in bed, maybe, and write my posts with pen and paper first. And after that, put all the links in and do the fact-checking, after the text is already down. It all goes back to something I wrote a long time back, wondering if having a Blog Editor would improve the quality of this blog. An independent Blog Editor is highly unlikely to appear, so I have to fulfil both roles myself; but if I do try to explicitly divide writing time and editing time, then maybe much more will get done.

Performance

In which things turn to treacle

I’ve noticed, over the past few months or so, that sometimes this site seems to load rather slowly. The slow periods didn’t seem to match any spikes in my own traffic, though, so I didn’t see that there was necessarily much I could do about it; moreover, as it wasn’t this site’s traffic that seemed to be causing the problem, I wasn’t under any obligation to do anything about it.

As I’ve mentioned before, a few months back I switched to Google Analytics for my statistics-tracking. Which is all well and good; it has a lot more features than I had available previously. Its only limitation is: it uses cookies and Javascript to do its work. Because of that, it only logs visits by real people, using real browsers,* and not spiders, robots, RSS readers or nasty cracking attempts. Often, especially if you’re a marketing person, that’s exactly what you want. If you’re into the geekery, though, it can cover up what’s exactly going on, traffic-wise, at the server level.

Searching my logs, rather than looking at the Google statistics, showed that I was getting huge numbers of hits for very long URLs, consisting of valid paths joined together by lots of directories named ‘&’:

Logfile extract

That’s a screenshot of a single request in the logfile – the whole thing being about 850 characters long. ‘%26′ is an encoded ‘&’ character. Because of the way WordPress works, these things are valid URLs, and requests for them were coming in at a pretty fast rate. Before long, the request rate was faster than the page generation time – and that’s when the problem really starts to build up, because from there things snowball until nobody gets served.

All these requests were coming from a single IP address, an ordinary consumer type of address in Italy.** Moreover, the user-agent was being disguised. Each hit was coming in from the same IP address, but with a different-but-plausible-looking user-agent string, so the hits looked like a normal, ordinary browser with a real person behind it.

The problem was solved fairly easily, to be honest; and the site was soon behaving itself again. It should still be behaving itself now. But if you came here yesterday afternoon and thought the site didn’t seem to be working very well, that’s why it was. I’m going to have to keep an eye on things, to see if it starts happening again.

* and only if they have Javascript enabled, at that, although I know that covers 99% of the known world nowadays.

** which made me think to myself: “I know I’ve pissed people off … but none of them are Italian!

The size of things

In which we measure monitors

The redesign is now almost done, which means that soon you’ll be saved from more posts on the minutiae of my redesign. It’s got me thinking, though: to what extent do I need to think about readers’ technology?

When this blog first started, I didn’t really worry about making it accessible to all,* or about making sure that the display was resolution-independent. It worked for me, which was enough. Over time, screens have become bigger; and, more importantly, more configurable, so I’ve worried less and less about it. When it came to do a redesign, though, I started to wonder. What browsers do my readers actually used.

Just after Christmas, for entirely different reasons, I signed up for Google Analytics, rather than do my own statistics-counting as I had been doing. Because Google Analytics relies on JavaScript to do its dirty work, it gives me rather more information about such things than the old log-based system did. So, last week, I spent an hour or so with my Analytics results and a spreadsheet. Here’s the graph I came up with:

Browser horizontal resolutions, cumulative %

The X-axis there is the horizontal width of everyone’s screens, in order but not to scale; the Y-axis is the cumulative percentage of visits.** In other words, the percentage figure for a given width tells you the proportion of visits from people whose screen was that size, or wider.

Straight away, really, I got the answer I wanted. 93% of visits are to this site are from people whose screens are 1024 pixels wide, or more. It’s 95% if I take out the phone-based browsers at the very low end, because I suspect most of that is accounted for by K reading it on the bus on her way home from work. The next step up, though, the graph plunges to only 2/3 of visits. 1024 pixels is the smallest screen width that my visitors use heavily.

Admittedly there’s a bit of self-selection in there, based on the current design; it looks horrible at 800 pixels, and nearly everyone still using an 800×600 screen has only visited once in the two-month sample period. However, that applies to most of the people who visit this site in any case; just more so for the 800-pixel users. Something like 70% of visits are from people who have probably only visited once in the past couple of months; so it’s fair to assume that my results aren’t too heavily skewed by the usability of the current design. It will be interesting to see how much things change.

I’m testing the new design in the still-popular 1024×768 resolution, to make sure everything will still work. I’ll probably test it out a fair bit on K’s phone, too. But, this is a personal site. If you don’t read it, it’s not vital, to you or to me. If I don’t test it on 800×600 browsers, the world won’t end. The statistics, though, have shown me where exactly a cutoff point might be worthwhile.

* For example, in the code of the old design, all that sidebar stuff over on the right comes in the code before this bit with the content, which does (I assume) make it a bit of a bugger for blind readers. That, at least, will be sorted out in the new design.

** “visits” is of course a bit of a nebulous term, but that is a rant for another day.

Classification

In which we discuss tagging and filksonomies

Another design point that’s come up as part of the Grand Redesign I keep promising you: tagging. The little bundle of links at the bottom of each post that I didn’t really think did very much.

I was a latecomer to tagging. When this site first started, it didn’t have any for the first month or so. After a while I started adding them, pointing them to Technorati. Back then, the site was running on WordPress version 1.5.something, and it didn’t have any built-in tagging support. I was trying to avoid using too many WordPress plugins, and I didn’t think that tag management (as distinct from tagging per se) mattered all that much; so I wrote all the tags manually. Like this, at the end of each post, with the <a> element repeated for each tag:

<small>Keyword noise: <a class="tag" rel="tag" href="…">tag1</a>, …</small>

Which worked, quite well; there was a visually distinct “tag” class, because I wanted tag links – which all led to Technorati back then – to be visually distinct from regular links which would go to whatever they were about.

Things move on, though, and WordPress has since gained built-in tagging functionality. Given that I’m redesigning the whole site, and putting in new built-from-scratch layout templates, I thought I may as well switch to using a more organising tagging system. For one thing, it means less typing each time I write a post. All that code up above is replaced by one little chunk in the template:

<p id="thetags"><small><?php the_tags('Keyword noise: ', ', ' ,");?></small></p>

This one covers all the tags, calling a Wordpress API function to pull them out of the database and convert them into HTML. I know all those commas and quotes look a bit confusing; but really they’re not that bad. And the point is: this is in the template, not in each post. That bit of code there only has to be written once; the previous chunk had to be typed out every time. The most awkward part is that WordPress isn’t flexible enough to let you set the class of each link individually, hence the <p class="…"> at the start.

The big change this leads to, though, is that the tag links no longer point to Technorati. Now, they point back to the site itself: tag page requests generate a page containing every post marked with that tag. And, already, that’s shown that people do indeed click on the tags. People, particularly people coming from searches, do seem to use them. Whether they find them useful or not is another matter, of course, now that they point back within the site and not to a broader variety of opinions on the matter; but they do get used.

Doing it this way means that I put more tags on each post, simply because there’s much less typing to do. Conversion, though, is going to be a bit of a job. Right now there are 760-odd posts on this site, all of which I’m having to reread and re-tag. It’s going to take a while, but hopefully the majority of it will be done by the time the new design is finished.* The only problem with this transitional phase is that: the current template is, because of its age, completely unaware of tags. So it doesn’t really know what a tag-based archive page is; so when you click on a tag, there’s no explanation as to what you’re looking at. I’m not sure if this is going to be a problem for you readers or not; and, hopefully, it’s only going to be a short-lived situation.

The word “folksonomy” has often been used to describe this sort of tagging system. I’m not sure it’s an ideal term for what I’m doing, though. “Filksonomy” might be more relevant: a bit like a folksonomy, but rather more whimsical and silly.

*** In any case, there are plenty of other parts of the new design that also need each post checking and potentially editing.

Road Trips

In which we discuss similarities between books and blogging

Last week, in the last Book I Haven’t Read post, I mentioned By Hook Or By Crook by David Crystal, and predicted that – in contrast to the book I was actually writing about – I’d have By Hook Or By Crook rattled through and quickly finished off.

Well, indeed, I have: it’s read, finished, and back on the bookshelf now. Prediction correct. And, as I said before, I think it was easy to read precisely because it mirrors the way I think. To recap: it’s written as a road trip, during which the writer muses on anything, really, that he finds of interest as he passes. A nearby manor house reminds him of a railway engine named after it, which prompts him to muse on railway engine names in general. The journey from Anglesey to the mainland prompts him to recount the history of the Menai bridges,* and a trip to Hay-on-Wye leads to the history of inn signs, coats-of-arms, and many other things besides.

It’s a book of associations, and a celebration of associative thought. I’m sure that it didn’t actually take place as a single trip, and that when Crystal sat down to write the book he didn’t just muse on whatever came to mind; it’s too carefully structured and crafted for that. But it does read as if that’s what he’s doing. It made me think, moreover, of the way I write this blog, which isn’t at all carefully structured and crafted. But, as I move through the world, I see things which spark my brain alight and give me something to think about; and this blog is the result. It’s full of rambling and digression, but, rambling and digression with a common thread behind it, the thread being the things I encounter.**

I was thinking about this as I got towards the end of By Hook Or By Crook. So, I was quite amused when I reached Crystal’s thoughts on blogging.

[Blogging] is writing which is totally spontaneous, put up on a screen without the intervention of an editor or proof-reader, so it is much more like ‘speaking in print’ than anything before. And it shows many of the properties of spoken language, such as loosely constructed sentences and unexpected changes of direction. Bit like this book, really…

David Crystal has a blog. He started writing it at the end of 2006; he said, as a sort of FAQ page. Given that By Hook Or By Crook was published in ’07, though, I’d assume that he started blogging either a few months after the book had been written or when it was in the final stages of completion. I’m wondering if writing that book was one of the other things, though, that prompted him to start writing a blog. Because, really, they’re often exercises in a similar sort of vein. Spotting something that interests you, and telling other people about it.

* from building up to burning down, you could say

** Which is all a bit of a longwinded and pretentious way of saying: I write about whatever’s on my mind.

Design points

In which nothing, design-wise, is accomplished

As I mentioned recently, I’m embarking on a Grand Epic Ground-Upwards Redesign of this site, because, well, the design hasn’t been changed since I first set it up. I knocked it together in a few days holiday in August ’05; back then my holiday year ended in August and I often had a few spare days at the end of the month where I had nothing to do and needed to keep myself occupied. In 2005, this blog was the result.

Anyway, my point is: it was put together in a bit of a hurry, with most of the design code ripped out of a standard theme I downloaded, without me really understanding what each bit did. The design’s always had a few rough edges, and there are lots of things that I’ve meant to develop further but never have. Hopefully, some of those points will be addressed, attacked, and taken by storm.

Thinking about the design, though, and what I want it to achieve, has made me think about one of the things I was most unhappy with when I first put this site together. One of the things I liked about this theme when I first saw it was:* the little boxes for the date on each post. You know, these ones:

Date with cardinal number

But one thing I didn’t like, though, was the cardinal number. Maybe it’s because I’m English, that that’s how I was taught, but when I read a date, I always read it with an ordinal number. “January 11th”, not “January 11″.

I can’t remember, to be honest, if it was possible to fix that easily when I first started using WordPress. Possibly it was, possibly it was something that’s been added later.** In any case, I didn’t fix it. I know I tried to, at one point; but abandoned the fix and didn’t go back to it. Then I forgot the issue, until, coming back to the redesign, I tried the fix again the other day. When I retried it, I remembered that I’d given it a go before. Because this is the result

Date with ordinal number

Those two extra characters mean that on most days, the text is just marginally too long to fit in the box. The box gets pushed down. Which isn’t so bad; but, it doesn’t always happen. You can’t necessarily know what the date box will look like; how it will relate to the elements around it. Moreover, I don’t know how it will look on other computers, where the fonts have slightly differing metrics to mine.

There are ways to fix it, of course. The box could be slightly wider. I could make sure that the horizontal line always comes underneath the date box, although that might leave annoying white space under the post title. The question, though, is whether it’s worth doing. However many times I tweak it, I’m not sure I’d ever get it quite right based on the current design.

And so, this all is partly why I’m going to start pretty much from scratch. The risk is that I’ll reinvent the wheel; the upside is that at least I’ll know how it works from its heart.

* and still is

** To be pedantic: it’s not a feature of WordPress itself, it’s a feature of PHP, the underlying language. I’m too lazy to go back through PHP’s version change logs and find out when the feature in question – the “S” character in date formatting strings – was added.