I use a version of WordPress to host my blog, which is very similar to the versions offered by WordPress.org, but which have been tweaked by Debian Developers, to add security, as well as to increase compatibility with Debian Linux.
But, it’s my personal habit to operate this platform with the ability to install plugins and Themes from the WordPress.org site. Making this available involves some trickery with symlinks and with directory ownership. Yet, WordPress itself is designed with flexibility in mind, when it comes to local configurations. So it tolerates this as a platform.
But from time to time, Debian Maintainers push through an update to their core version of WordPress – which I am using. I happen to have my core files installed in ‘
/usr/share/wordpress‘, while I have my extensions installed in ‘
/var/lib/wordpress/wp-content‘. The permissions and ownership for these two directories, as well as their subdirectories, involves two different settings in my configuration. One directory, with all its subdirectories, is not writable by the Web-server, while the other is.
When Debian Team pushes through one of these updates, it can break how my personal localization works, because Debian Team is inherently unaware of how any systems may be configured, which are not Debian. This is a bit like how Microsoft programmers inherently don’t understand anything which is not Microsoft.
Sometimes I have installed the update to the core files, without any issues, but sometimes, some additional, manual work is required on my part, to ease the update.
This afternoon, the core files installed fine, and left me with a working blog. But there exist some Themes and plugins which need to be installed from the package manager, to ensure a working site, but of which I usually have the latest versions, from WordPress.org instead. The packaged versions of these Themes and plugins generally tend to lag behind, the most up-to-date versions from WordPress.org.
This means that after one of the core updates, I typically need to reinstall the update, to whatever Themes and plugins the package-manager update has rolled back.
This morning, that added step in my procedure ran into some trouble. But, I was able to resolve the issue in little time, and my blog seems to be at 100% again.
Now, I do have a plugin which puts up a Maintenance Mode page, for as long as I like. But generally, I find that this plugin only hinders me. For one thing, if some type of mess results on my hard drive, having this page enabled could prevent me from disabling it again, and from fixing the issue. Secondly, whatever maintenance I do, is generally finished within 15 minutes or so. So I generally don’t use this plugin.
This afternoon, I began by allowing the core update to take place around 13h30, at which point the blog was still displaying fine. But I ran into issues getting the “TwentyFifteen” Theme back up-to-date, which would have caused any readers to see artifacts when trying to view my page, which were all gone and repaired by 13h45.
So for 15 minutes, readers might have seen some artifacts. If you did, I truly apologize. If I had used the Maintenance Mode plug-in, then doing so would have made my manual procedure more complicated, so that you might have seen the Maintenance Mode page instead, all the way until 14h00. In other words, the task could have taken twice as long to complete than it did.
My official WordPress version is now ‘
4.1+dfsg-1+deb8u14‘. And it works again.
(Edit: There exists a phenomenon in Human Psychology, with a name I forget. Essentially it amounts to stubbing one’s toe on a table-leg, and due to the unexpected or even inconvenient timing of the pain, blaming the table-leg for the accident. In retrospect, now that this pain is gone, I’d say this SNAFU was entirely my own fault.
When I told WordPress.org to update my Theme, to bring it back to its external version, I got the message that the platform was not able to remove the old version of the Theme, after which my blog was left installed, with no Theme at all. I have no idea what people would see, but realized that I next needed to repair whatever problem I had overlooked before, and then to install the external version of the Theme.
Obviously, every time I do this, I’m also butchering files, which the package-manager had installed, belonging to this Theme as well as to one plugin. This is usually a very wrong way to do things under Debian, but just with this WordPress site, it happens to work.
The problem was, a folder belonging to the Theme in question, but whose ownership was still set to ‘
root:root‘ from the way the package-manager had left it. There is a single command which I would normally have the presence of mind to give, before doing the in-site updates, but which I had forgotten to give, and it goes like this:
root@Phoenix:/var/lib/wordpress/wp-content# chown -R www-data:www-data .
In the future, thinking to give this command once, from the correct directory, would save me from experiencing the same problem again.