The boring stuff I’ve been working on during August

It’s August. The office isn’t as busy as usual. My brain isn’t being used as much as it normally is, and it needs to find an outlet. So it’s the month when, if there are things that need doing to the design or coding of the website, I turn my mind to it. The last occasion that I spent any significant time over the summer to make tweaks was way back in 2012. Since then, the site has been running well, the design is how I want it, and nothing much has needed doing. Or any problem I wanted to fix has been beyond my estimate of my ability to resolve it.

The functionality clean-up and upgrade

Since my last summer upgrade, mobile technology has been advancing, and nowadays if your site doesn’t work well on a phone Google penalises you. Right now, I’m not too fussed about Google rankings, but what I have been fussing about is that the key navigation pages that I use to find things on the site – the listings of the 1,000 or so taxonomy tags – haven’t been working on LKL’s mobile version. The page has been displaying a heading but no text. I discovered that the reason for this is that my mobile version uses easy, generic templates provided by the Jetpack WordPress plugin, while the desktop version of my site uses Thesis, my chosen theme framework, with all the modifications and customisations that have accreted over time. Specifically, the taxonomy pages need to use php to list out all the tags – and because you can’t use raw php in a WordPress post I had to draw up a custom page template to do all the work for me.

But because that custom page template is built for my desktop theme it doesn’t get picked up by the Jetpack mobile theme, and all it delivers to a mobile user is a blank page.

To fix this – to get the same text displaying whatever theme is being used to serve up my content – I needed to get the php to operate within the body of a WordPress post. And I discovered that the way to do that was to define a custom function (containing all the necessary php) which can be called by a shortcode within the text of the post. (A shortcode is a defined string of text contained within square brackets).

After much experimentation, I managed to retire the custom page template and got WordPress to display the taxonomy listings as part of the post’s content within whatever page template is being used. Lessons I needed to learn on the way included the following:

• Because of the way WordPress parses shortcodes, I needed to ensure that the php functions “returned” the text that I wanted inserted into the post rather than “echoed” it. Otherwise all the generated text would appear at the top of the page rather in the position that I place the shortcode.
• The custom function needs to be defined in a plugin file (used by any theme you might want to use in the future) rather than in your current theme’s custom_functions.php file.

The results, which look no different to desktop users, but which now contain meaningful information for mobile users, can be found here (for the tags) and here (for the categories).

Having solved the immediate issue that had been bugging me I turned my attention to a longer-standing challenge that I had been deferring. But with renewed confidence in my ability to cobble together working code from snippets I could find on the internet I designed new code to enhance my events lists: select all event notices between defined dates and sort them by event date rather than date published. Event date is a custom data element I’ve added to my event posts, while date published is a standard WordPress data element. By default, all WordPress pages list your content in the order it has been published, most recent first. Querying and sorting on custom metadata was the new challenge which had for many years seemed a step too far, but this month was resolved in a few hours of cut, paste, tweak, trial and error.

The final tweak was to fix the coding so that the current and upcoming events list includes not only events that I’ve published on LKL but also posts that I’m working on in the background. That means that when I hear of a new event that I don’t have full details of yet (for example, this year’s Korean Film Festival) I can do a quick draft post containing the event name and date, save it in “pending”, and the event will then show up on the list at its appropriate place but without a hyperlink to the full details. When I get those full details I can add them to the draft and then properly publish the post.

So now there’s a list of upcoming events in date order, and a yearly archive of past events with links to event details and, where available, links to the reviews we’ve written. (See, for example, the 2012 archive here). That last piece of information has kicked off a much more substantial piece of work to ensure that wherever there’s a review written on LKL, the original event notice contains an additional piece of metadata, namely the location of the post or posts which report on that event. Where there is more than one report on an event the decision has had to be made whether to group the posts together using a new tag, or whether simply to link to the most thorough report. Generally I’ve been taking the approach of creating new tags. As part of this trip down memory lane, I have enjoyed reading the reports provided by LKL’s many guest contributors.

As a final tweak, and so as to make the best use of the above manual labour, I’m currently trying (but so far failing) to write a piece of code that automatically adds some text at the bottom of an event notice providing a link to a review if I subsequently get around to writing one. (Update 3 September 2017: now done)

Increasing page load speed

While enhancing all the metadata, I found that the site was falling over more often than usual; indeed one morning when I woke up it seemed that all the data in my posts table had been wiped. Fortunately it was just a corrupted table which my webhost managed to fix, telling me that sometimes when the server falls over things get damaged.

So my mind turned to reducing server load, another challenge which has been niggling at me for a number of years (you would not believe how many warning messages are generated by my cPanel / Webhost Manager software: my error log is over 2 terabytes).

I looked at all the error messages generated by GTMetrix and other page speed monitors to see what I needed to do. And that kicked off a whole separate exercise. Once I’d determined the main problems, I needed to work out what the solutions were. And most of the quick wins involved changes to the .htaccess file.

I’d forgotten half the stuff I had put in there: redirects of pages that didn’t exist any more, among other things. So, having trimmed the .htaccess file of redundant instructions, I put in some recommended coding: for example, I tweaked the website so that the more static elements are saved in your browser’s cache rather than sent to you every time you visit, and I’ve compressed much of the content, hopefully speeding up page load times. Other page speed optimisations (such as organising the css commands in a way that a computer finds logical rather than in a way a human does) are a step too far.

I’ve started Smushing the images too, which has highlighted another data issue: I’m now on my third webhost, and each one seemed to configure things a different way. Specifically, when it comes to the metadata relating to images that have been uploaded to individual posts, there are three different relative paths for the image location on the server – one for each webhost. The earliest posts have the paths for my first webhost. This means when Smush tries to find things to compress based on the paths defined in the post metadata it can only find the images for the posts that I have published since moving to my most recent webhost, which I did over the Easter weekend way back in 2008. Maybe this explains why sometimes the images on my earlier posts sometimes don’t display properly. My next mini challenge, then, is to pick up enough MySQL to correct the out-of-date pathnames in my post_metadata table.

Browsing the post_metadata table is instructive (as indeed is browsing the posts table itself). You wonder what some of that data is stored for. For example, the custom message that I told Jetpack to use when tweeting a new post is of dubious ongoing relevance. If I need to find it, I can probably search my Twitter timeline. And why do I need to know that a Twitter plugin I deleted years ago tweeted a message in accordance with my standing instructions? When I have an idle few days on my hands I’ll go through deleting all the redundant metadata, but my MySQL knowledge needs to improve before then.

The next big project? Probably in the longer term I need to move off the theme that I’m using at the moment to something that is more mobile friendly: a theme where I can control mobile-friendly templates rather than outsourcing my design to the incredibly useful but nevertheless inflexible Jetpack plugin. But that change would require months of preparation, and probably a good few weeks of cleaning up the mess afterwards. And I need to get back to addressing my content backlog.

Update 10 September 2017: the move to https

I’ve been using SSL for FTP and access to my cPanel and WebHostManager software for years. But at the time when I set up my site I think it was impossible to get free SSL certificates signed by a certificating authority. Instead, you could (and still can) issue a self-signed certificate for free. And that’s what I did. Seeing as it was only I that needed to connect to those areas of the server I didn’t mind the fact that my browser always issued me with dire warnings that I was connecting to a site using a certificate that was self-signed and I was in mortal danger. But you can’t expect your average member of the public to be happy with granting security exceptions like that.

But as Google kept adding greater priority in the search rankings to sites which are on https, and as they started to send me emails telling me that they would start issuing security warnings to visitors who leave comments or who fill out the contact form that their email addresses are not being sent securely, I thought it was about time to do something.

I spend a lot of time researching the different levels of comfort you can get from the different levels (and prices) of certification and concluded that all I need is the most basic level. And you can get that very cheaply, or even free. My next priority was ease of installation and management, and so I started poking around in my WebHostManager and cPanel areas to see what packages might have been made available since the last time I looked at the issue.

After a few random clicks, and more by accident than design, I ended up installing free, auto-renewed SSL on LKL and its subdomains.

At first, no change was noticeable on the front end of the site, or in the admin area. After all, I was still visiting the URI http://londonkoreanlinks.net rather than https. When I started consciously visiting the https address I got two different results. In the admin areas of the site I started getting the reassuring green padlock. Nice. But in the public areas I was getting the mixed content warning.

Thus started my engagement with whynopadlock.com, a handy site which scans your https page and tells you why you don’t qualify for the coveted padlock yet.

The main issue was that all the images on the site had the URI starting in http rather than https; the other was that some of the external resources that load on the front page (the google search box and the google calendar) were giving 404 responses.

So I realised that to get the padlock I needed to invest more time. In the process, the plugin Really Simple SSL was consistently recommended by various websites. I gave it a try on a test site and it worked like a dream. Immediately the padlock appeared on every page. But I was concerned that it would increase server load (it uses WordPress and javascript redirects in addition to .htaccess redirects) – a perennial problem for my site. So I decided to try to implement SSL (and eliminate the mixed content warnings) without a plugin.

Critical step: change all image URIs to https (I used the Better Search Replace plugin which enables you to edit the content of every table in your WordPress database without knowing any SQL). (Images stored in the WordPress Photon CDN are already https). Cautiously, I wanted to restrict the damage I could do, so I made sure I hunted for ‘src=”http://londonko‘ and replaced with ‘src=”https://londonko‘ – to avoid changing things I didn’t need to. But having made those changes, I was still getting mixed content warnings. And that’s because a lot of the calls to images are made by reference to metadata rather than the html stored in the posts table. So then I hunted the metadata table for the string http://londonko and made the appropriate changes.

Having executed that step on a test site, and making sure I had the very latest code for my Google Calendar and custom search engine embeds, I ran the test site through whynopadlock and was getting the green padlock, even though I was still getting a 404 message for the calendar. No web resource can adequately explain why that 404 message occurs, but at least that error is not enough to take away the green padlock. So, having backed up everything, I did all the image edits on LKL itself. And behold, nothing fell over. So I backed up everything again.

I lived with this status for a couple of days to make sure nothing untoward happened. Other than being asked to log in more frequently than usual (WordPress was confused as to whether I was http or https) I was confident enough to take the final big step: force SSL across the whole of LKL.

Here’s what I did.

• Look at the coding for the 301 redirects that Really Simple SSL inserts into the .htaccess file (there seemed to be several suggestions as to what precise code to use, depending on which web forum you visit. The Really Simple SSL code seemed to work fine on my test site, so if it ain’t broke don’t fix it.)
• On the test site:
  • Make sure you’re logged in to your database via phpMyAdmin so that you can undo anything you’re about to do, should the WordPress admin area crash or lock you out
  • Log in to your FTP programme so that you can edit your .htaccess file (and un-edit it if necessary!)
  • Log in to your WordPress admin section and change the home page and site URIs to https
  • Paste the 301 redirect code into your .htaccess file
  • Cross your fingers, and grin like an idiot when everything seems to work just fine. Which it did immediately.
• Repeat the above steps on LKL itself
• Faff around in the Google analytics and webhost site to tell them that I’m now https.
• Sit back and wonder how I managed to get it done without a major incident. I hope.

With my most pressing technology issues now put to rest, I’m hoping my mind can now be persuaded to focus more on the content backlog. That’s it for this year.