## Debian WordPress recently received an update.

One of the facts which I’ve blogged about before, is exactly, what blogging platform I’m presently using. I subscribe more to ‘WordPress.org’, and less to ‘WordPress.com’.

This synopsis is a bit over-simplified. The actual WordPress version I have installed is the one that ships with Debian / Jessie, aka Debian 8, from the package manager. But that doesn’t mean we don’t receive security updates. I actually tend to trust the Debian Maintainers more, than WordPress.org, to keep the platform secure. They’ll downright snub features, if they find the feature poses any sort of security threat.

And in recent days, this Debian build of WordPress did receive such a routine update. The main reason I take notice of such things is, the fact that my personal WordPress installation is modified somewhat, from what the package maintainers build. This still allows me to download a modest set of plug-ins from WordPress.org, as well as one plug-in from WordPress.com.

I’m happy to say that no snarl took place, between the recent Debian-based update, and my custom-configured blogging platform. Service was never disrupted.

Dirk

## WordPress Debian Update Today

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.

Dirk

(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.

## WordFence

One of the facts which I have written about before, is that my blog is set up in a slightly customized way, with core PHP files that come from the Debian package manager, and which do not have permission bits set, so that the Web-server can write to them, but also with add-ons – aka plugin-ins – with permission bits set so that the server can. This latter detail is a great convenience for me, because it allows me to install plug-ins from WordPress.org, as well as to install updates to those, via means that are simple for me to operate.

What I have also written, is that this makes my overall security good, but not perfect. Theoretically, there could be a corrupted plug-in available directly from WordPress.org – even though in general, they do their best to vet those – and which I could install to my blog, without knowing it. Further, even if the plug-in contains no dirty code visible to WordPress.org, the way some of them work might depend on a Web-service from their author, and then that URL could be running some sort of suspicious scripts, let us say on yet another server.

And so a reasonable question to ask might be, of what use WordFence can be in my case. One of the types of scans which this security add-on performs, is a check of all my core files, against what the versions are with WordPress.org, not with Debian. And then this scan reports 58 deviations to me, without analyzing them, just because Debian has slightly different core-file-versions. It also checks my entire plug-in directory, scans all the plug-ins, etc.. But in reality, WordFence never reported any kind of anomaly in my plug-ins, because those are the WordPress.org versions.

## WordPress Update Went Smoothly Today.

I run a localized version of , that partially comes from my Linux package manager, but that has been modified by me, to allow me to install the plug-ins and extensions from .

Therefore, whenever an update to the core files is available from Debian Team – from the package manager – I am a little apprehensive, that the way this update is carried out might not be compatible with my customizations.

Most of the time, updates are good, but on occasion, they may break things.

Today an update to the core package came through the package manager, which technically puts my version at ‘‘. I am sure that there are benefits to users like me. But most importantly, it seems that this update did not break anything. Yay!

Also, I am not recording any down-time, because as far as I can tell, I was able to display a Maintenance Mode page, while the update took place, which would have told readers that the site is undergoing maintenance, for a few minutes.

Dirk

P.S. I also had to restart my ‘‘ daemon after that, the purpose of which is to introduce caching on my side – on the server – to speed up retrieval of whatever readers are interested in most often. Because this cache has therefore been flushed, some of the pages and postings may load a little slowly for the next day or two.

(Edit 02/03/2017 : ) I have begun to notice some functional changes in the behavior of WordPress, that I believe stem from this update. In short, the new version seems to use my caching daemon more consistently, than the previous build did.