Even though my Blog is hosted on a supposedly-secure Linux machine, on which the core WordPress Files have permissions set such, that the Web-server cannot write to them, there is always some slight danger, that an infection can make its way onto my blog, through plug-ins which I have installed, which come from the WordPress site, but which are not under the scrutiny of the Debian software team, who created my WordPress core files. My Web-server can also self-install updates to those plug-ins, from their respective owners, because the write-permissions of the plug-ins directory are such that it can. ( :1 )

The reader may have noticed that there used to be an icon in the bottom of my postings, which allowed him either to Print the posting, to Save it as a PDF, or to Email it elsewhere. This icon was due to the ‘PrintFriendly Plug-In‘.

This plug-in did not even install any suspicious code on my server, but is cloud-based, in that any use made of it will redirect to the Web-site and servers, belonging to PrintFriendly. Not only that, but the icon itself can contain links to their site.

Well today I did notice, that my Web-browser, when pointed at my own site, tried running scripts from a site called ‘kxcdn.com’, and which my own browser had the installed extensions to block. This raised an alarm-bell in my head, and I went into action, looking for any contagion.

The PrintFriendly plug-in, or more correctly, their site it pointed to, was the source of that contagion. Deactivating that plug-in has now taken away the capability of the readers, to Print, to PDF or to Email my postings. But it has also removed any of the malicious attempts to redirect to ‘kxcdn.com’. The threat has effectively been neutralized on my server.

But, If You Did open that site, it would possibly have led you to This Situation. If it did, I hope you did not fall for their ploy. I apologize profusely if this happened to you, and do my best to control such problems from the first moment I notice them.

I have now installed the WordPress-security-extension ‘WordFence‘, and hope that this will reduce any vulnerabilities in the future.

Dirk

1: ) Actually, before my WordPress instance can update its plug-ins, I need to authorize the event. However, this safeguard only determines at what time updates can take place in practice, and just might make me aware of some suspicious activities that have yet to happen. It does not actually control, what code is inserted in the update.

However, as of now WordFence does control this, and has given me a clean bill of health!

## 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 , without really knowing how the latter works in detail, because I have never written a 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 , 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.

Dirk

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

## A Silly Mistake not to make, when Using Post-Views Counter

During my previous posting, I did write that I not only use WordPress, but that I actually use a plug-in named ‘‘. In fact this plug-in will work correctly by itself, and only requires that the blogger add special code to the PHP () scripts of WordPress, if he or she wants special behavior from the plug-in.

Not realizing this, I had put the following lines of code at the bottom of the file ‘‘:


<?php
/**
* Loads the WordPress environment and template.
*
* @package WordPress
*/

if ( !isset($wp_did_header) ) {$wp_did_header = true;

wp();

require_once( ABSPATH . WPINC . '/template-loader.php' );

echo do_shortcode( '' );
//        pvc_view_post( $wp_query->post->ID ); }   Since then, I have commented out that last, offending line. The effect which that line had produced, in my logged-in view, was this: The first posting of my blog home page was never really viewed, 37 times by itself, as the widget would indicate. But there does exist a home page of my blog, which displays the 4 most-recent postings, and views of which I do not want counted. The problem here is the fact that this expression:  ($wp_query->post->ID )



Returns a valid Post-ID, when there are 4 postings on the same page. I had not expected this. But this expression returns the Post-ID of the topmost posting in the home page.

## Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk