## The Blog will be a little slow for the next few hours or day…

In the way I have set up WordPress.org, it makes use of a caching daemon named ‘Memcached‘, that runs on my server and speeds up the fetching of specific, frequently-requested content. This is not to be confused with whatever cache is also speeding up your browser.

As part of a routine set of updates fed through my package manager this evening, this daemon also received an update, which required that it be restarted. As a result, the cache is now cleared, and the fetching of the favorite postings to the readers will be somewhat slow for the next few hours, or maybe even for a whole day.

I apologize if this inconveniences anybody.

Also, this behavior does not represent any sort of malfunction, either by the daemon, nor in the update process. All the updates seemed to go through just fine.

Dirk

## 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


4.1+dfsg-1+deb8u11


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

Dirk

## 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


/usr/share/wordpress/wp-includes/functions.php



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


wp_json_encode()
_wp_json_sanity_check()
_wp_json_convert_string()



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


/usr/share/wordpress



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.

Dirk

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

## An Oddity which greets me, When I Log In to my Blog Each Morning

One of the facts which I have written about at length, is that I take the somewhat unconventional approach, of hosting my own site, on my own server at home.

And while my site has different parts to it, one important part to it is this ‘WordPress.org’ blog.

One of the facts which I have learned about WordPress.org, is that it serves requested pages using PHP Scripts, that run synchronously. Thus, if the script was to stall in its effort to return a value – a quantity of HTML – then the user / client could be staring at a browser, with a spinning wheel that says it is waiting for the page to be fetched – for quite a long time.

But I am still quite comfortable in the idea, that this only affects my blog in unimportant ways. For example, if the blog-engine is looking specifically for updates to any of its plug-ins, then it is waiting for the site of every plug-in author, to report back to it, whether one plug-in has an update pending.

Since my instance of WordPress.org has about 20 plug-ins installed, the probability that one plug-in author could not be responding, is not equal to zero. Yet, the PHP Script that is looking for any updates, is still running synchronously.

What some people might think, is that in such a situation, all they would need to do is contact the same site again, from the same browser, and thus force a new thread to serve them. But this is actually in error, because my Apache server is set up, to delegate one session, to one Apache sub-process. Thus, my server will recognize, in this case, that the IP address connecting is ‘127.0.0.1’, and it will send further requests for the page, back to the same sub-process, which was given the task to serve one session. This server is session-aware and optimized to be so.

Also, when I want to look at my WordPress.org Dashboard, the first time I do so in the morning, the server thread responsible for ‘127.0.0.1’ also includes a new search for plug-in updates. So I can sometimes wait for a while. After that, all my access-requests to my Administrative Dashboard, become fast as easy again.

I am confident that this mainly affects my ability to fetch certain pages as the Administrative Identity, and that this has not yet affected clients / browsers, who simply want a page of my blog served out. If it was to affect them, there would be a more-serious problem for me to address.

If this has affected You, I recommend you tell me about it, by leaving a Comment.

Dirk