WordPress Update Went Smoothly Today.

I run a localized version of WordPress, 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 WordPress.org .

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 ‘4.1+dfsg-1+deb8u12′. 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.


P.S. I also had to restart my ‘memcached’ 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.

Continue reading WordPress Update Went Smoothly Today.

Routine Theme Update Today

Any reader of my blog will notice, that I did not code this HTML by hand. I use bundled software named “WordPress”, and I use a version of it similar to what is offered at WordPress.org. This blogging tool is very sophisticated – in my opinion – and extensible through plug-ins and other extensions. I can install WordPress.org updates and extensions, even though my version of the core engine is a Debian / Linux -packaged, localized version.

One of the features of any one blog is its Theme. Though not a plug-in, the Theme plays an important role. It defines the general ‘look and feel’ of any one blog, thereby defining the general layout in the browser of the reader. It is also the Theme, which will determine how easy or difficult it may be, to read a blog on a mobile device – given that many people no longer connect to the Internet as much as they used to, using a PC or even a laptop.

I use the TwentyFifteen theme. Just today, it received an Update, from version 1.6 to 1.7 . As far as I can tell, this update took place without incident, and should not affect your reading experience in any way.

Yet, there was one step which I needed to take during this update. I needed to flush the cache I provide with ‘memcached’. This was to prevent readers from receiving any HTML fragments, which would still have belonged to Theme version 1.6 . Therefore, because of this cache restart – on my server, not on your browser – the response to some of the queries of the reader will be a tad slower for several days, since it is the cache on my server, which accelerates the output of specific HTML, which was already formed the last time the same article was requested from my server.



Corrected WordPress.org Update, Situation Normal

According to This Earlier Posting, there had been an update to the WordPress.org blogging engine – which I am using – which had specific problems as issued by Debian Team.

I am happy to observe, that as of now, the latest update from Debian Team has taken their earlier mistake into account, so that a new update was pushed through, which runs fine. Not only was I able to apply the new update easily, but I believe I was even able to keep my blog showing the Maintenance Mode image throughout, to warn people of this undertaking. This Maintenance Mode image should have been visible to potential readers, from 14h37 until 14h45.

Everything seems to be working fine with the blogging engine.

Again, the response of the blog might be slightly slow for the next time being, because anything which requires me to display the Maintenance Mode image, also requires that I flush my cache, on the server. But all of what happened today was completely routine.

It was also completely normal, that Debian Team repaired the error in a previous update, by issuing a new update immediately on the heels of that one. I am now on WordPress version





It was the version containing ‘+deb8u10‘ at the end of its name, that contained the original problem.



Botched Update, Minor Blog Disruption

I host this blog on my own server. Further, I use a blogging engine the name of which the reader can see plainly on the site, which is partly installed via the Debian package manager, and partly via in-place downloading and updating of extensions via plug-ins.

Just tonight, the Debian team put through a package-originated update to ‘WordPress.org‘, which has happened smoothly in the past, and the nature of which I have integrated with my particular site quite well.

But immediately after the WordPress.org update tonight, the blog went off-line briefly, and I feared the worst – that I had made chopped beef out of my local configuration of files.

But what I found instead, this time around, dismayed me: In the file named


There is a re-declaration of three functions, in principle:


Since these three functions have been redeclared within the same code file, that belongs to


And belonging to the package, there was no way the blog could have sent off any HTML at all – regardless of what my plug-in settings might have been. It is baffling that Debian Team would make the error, of declaring the same functions twice within the same file.

I simply had to comment out the offending functions, and my blog works again, plug-ins, theme and all.

So it would seem that the code that keeps WordPress.org running, is malleable after all, so that I was able to restore order within my files.


(Edit : ) I suppose that for the next few hours or days, the readers might notice that the blog engine is rather sluggish. This is due to the fact that I needed to clear my cache. But clearing the cache on this server would have been necessary anyway. I had the whole maneuver planned out so carefully – To put the blog into maintenance mode, to clear the cache, to change a directory permission, to apply the update, to re-owner the folders, and to deactivate maintenance mode…

Such a shame the the code did not play nice this time.

This affected the blog from about 21h30 until 22h45.