Well, here’s an entertaining bit of techie fun for you…
It all started a while ago, when the formerly nice people at 500px announced that the portfolio feature which I was quite happy to pay for was going to be taken away, and replaced with something more complicated, but only if I gave them more money. I muttered about this back in April.
Regular readers and other such mythical creatures may recall my slight tendency to take a while to get around to things, but I’ve had a vague notion that I need to do something to replace that portfolio before the decision is taken for me. And having been bitten slightly by 500px, I was coming around to taking it back in-house, so to speak and hosting it myself. I’d half-heatedly looked at some WordPress themes, but didn’t find anything I really liked, and had long since decided that developing anything non-simple is not something I’m likely to manage to do.
Then a random thought struck me – a few years back, I’d played around with a Lightroom add-in that worked with the Web Module to generate web sites. And amazingly, I even remembered the name of the site.
So, I popped over to The Turning Gate, where I found the previous products had been replaced by Something Clever called Backlight. This consists of a web application you install on your own site and a Lightroom plugin that creates a Publish Service. Basically, you configure the site, add its details to the plugin and then publish albums.
Well, I had a good look around the site, looked at some examples, had a look at the support forum and concluded it might just be what I needed. By the nature of the product, there are no trials and no refunds, so it was a bit of a gamble, but sometimes you just have to do that.
So, I configured a new website on my Linode server and copied over the files. Hmmm. First problem: instead of the friendly login page, I got a message telling me that it needed the SQLite module and wouldn’t play without it.
SQLite is a flat-file database thingy which can hook into PHP, but it seemed I didn’t have it. After much apt-getting and muttering, I found that on Debian 9, SQLite isn’t included for PHP 5.6. There were some suggestions for downloading, compiling, standing on one leg and doing the can-can, but I know my limits…
So, I decided it was time to see about moving the server to PHP 7 (There is no PHP 6. We do not discuss PHP 6.).
I used the helpful PHP Compatibility Checker plugin to scan my site for possible issues. It pointed out that my own plugins used a bit of no longer supported code, which I was able to fix, and mentioned that a plugin I no longer use would break, but otherwise I should be fine.
So, I disabled the Apache PHP 5.6 module, enabled the PHP 7 module, and my new site started to behave.
I did some playing and tweaking there before heading back to this site. Ah. Problems…
The first thing I noticed was that while big images were being displayed on pages, the little thumbnails in the Media Library were altogether missing.
The next thing I noticed was a load of spurious characters, mostly Â appearing in posts.
The last thing was that the nifty EXIF details block below my photos was totally unformatted and a wee bit hard to read.
The first problem was easy – I used the Regenerate Thumbnails plugin to make WordPress recreate all the thumbnails.
The second was more fun – this came down to deleting the surplus characters by editing the database. Well, actually it was another plugin – Search and Replace that did the hard work for me (after I’d taken a backup of the database, and used the “dry run” feature to preview all changes).
The EXIF problem was more head-scratchy. First, the Exifography plugin had lost all its settings. Odd, but easy enough to recreate, as I have it set up identically on a test site.
That nearly worked – the details now appeared on separate lines, but not in the centred grey box. So, it was time to inspect some code. The block should appear like this:
But instead it looked like this:
Well, with those backslashes escaping the quotes, it wasn’t going to work. I tried re-entering the settings, deactivated and reactivated the plugin, attempted to understand the code, and came to the conclusion that it must have voles. Or something. It looks like the stripslashes function wasn’t stripping slashes, presumably having decided on an alternative career in bakery, or something.
So, it was back to the database. I located the settings in the wp_options table, found that the value for the bit of code that begins the block did indeed contain those slashes, and so I removed them, remembering to reduce the little numeric value by two so it didn’t get confused. And yes, I am keeping that vauge: if you don’t know what any of that means, do not attempt to edit your database. If you do know what it means you’re probably laughing at this post anyway. With that change made, normal service was resumed and the data appeared as it was supposed to.
The last thing was checking on the thumbnails. On the first pass, out of well over 9,000 images, around 170 had failed to process. So, I ran it again and ended up with just six that needed some TLC. Five were ones where the file name in the database had become mangled – another case of character encoding changing things to odd symbols. It was easy enough to download the files, rename them, insert them back into the posts and delete the previous versions. The final one just seemed confused, but the same trick worked for that one too.
Most of this oddness is probably due to the age of the site – it was originally created in the early days of WordPress (v1.something), and things like character encoding can be fun for that kind of thing.
Anyway, we’re now running on PHP7 and everything now seems to be working. And that’s my longest post in ages.
 Now that’ll be one for another post
 And another one…