I am confident that my site is secure again.

What happens from now on, is that ‘WordFence‘ performs routine security scans of my blog. It then emails me with reports.

According to the latest report, emailed to me overnight as I slept, my blog had one issue, out of hundreds of potential issues: One of my plug-ins needed an upgrade.

Of course, I would have seen that this plug-in required an upgrade anyway, as soon as I checked my Dashboard this morning, which showed me the same result.




An Update on how the Object Cache works, in WordPress

In this earlier posting, I had added comments that describe caching in general, as well as the Object Cache of WordPress, without really knowing how the latter works in detail, because I have never written a WordPress plug-in.

There was a fact which I had never mentioned, that in the caching daemon, each Key-Value Pair has a time-stamp, indicating exactly when the Value was set. Apparently, when plug-in designers query the MySQL database, they have the option to make that a cached query, which means that the query will first query the cache, and only if there is no Value in the cache, will query the database.

This query has as optional parameter, an expiry time, so that if the Value in the cache is older than this time, it will be regarded as not being in the cache.

I suppose this is useful in certain cases, where there is no opportunity to delete the Key in the cache when data is updated, but in which to view a widget simply looks up some value in the database, which could be cached.

I have communicated with the author of Post Views Counter, who has told me that he has in fact modified his plug-in, to add an expiry value to his cached queries, to try to solve the problem of data-views not updating, since the last plug-in update. And I have also installed the latest version of his plug-in, which contains his patch.

I suppose that one question this revelation raises, is whether it is in fact a part of what gets cached, pieces of HTML that constitute whole postings, at the request of core PHP code. It may not be. Instead, it may only be the case that HTML continues to be generated by PHP code, on the basis of database queries, but that more of those queries may be cached queries now.

However, the actual HTML of which my postings consist, is obtained by queries to the database.


Note: The patch which this plug-in author has applied to his code, does in fact work, and I can safely delete the cron-job which I had created as a workaround.

Continue reading An Update on how the Object Cache works, in WordPress

I use WordPress.org, not WordPress.com, for most of what I subscribe to.

I think it is a bit my own fault, for not explaining in a clear way, what the difference is between WordPress.com and WordPress.org .

WordPress.com is a specialized blog-hosting site, on which members can write their blogs, but which runs on professionally-maintained servers, by WordpRess.com .

But, the people behind this service have also made the PHP Scripts available for free, that run on the server, and that cause the HTML to be generated, which causes proper WordPress blogs to appear on the browser of the reader. People may download those, and may upload them to whatever Web-server they have access to, provided that that Web-hosting service, also supports the running of server-side scripts, by the Web-hosting service members. Some Web-hosting services put a lot of restrictions on what their members may publish, such as static HTML Pages only, or such as no access to any MySQL server, the latter of which WordPress.org uses actually to store the blogs.

And so, because this support-factor is the main part of the expenses incurred by WordPress.com, I will assume that sharing their core scripts poses no perceived threat to them. Their main expense is not, that core set of PHP Scripts. But, because an individual may have problems setting all this up as well, there is an associated Web-site, namely WordPress.org, where independently-hosted WordPress users can go for tech support, and to download plug-ins.

Continue reading I use WordPress.org, not WordPress.com, for most of what I subscribe to.

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.