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