Memcached no longer contributes, to how this site works… For the moment.

One of the facts which I had mentioned some time ago, was that on my Web-server I have a daemon running, which acts as a caching mechanism to any client-programs, that have the API to connect to it, and that daemon is called ‘memcached‘.

And, in order for this daemon to speed up the retrieval of blog-entries specifically, that reside in this blog, and that by default, need to be retrieved from a MySQL database, I had also installed a WordPress.org plugin named “MemcacheD Is Your Friend”. This WordPress plugin added a PHP script, to the PHP scrips that generally generate my HTML, but this plugin accelerated doing so in certain cases, by avoiding the MySQL database look-up.

In general, ‘memcached‘ is a process which I can install at will, because my server is my own computer, and which stores Key-Value pairs. Certain keys belong to WordPress look-ups by name, so that the most recent values, resulting from those keys, were being cached on my server (not on your browser), which in turn could make the retrieval of the most-commonly-asked-for postings – faster, for readers and their browsers.

Well, just this morning, my WordFence security suite reported the sad news to me, that this WordPress plugin has been “Abandoned” by its developer, who for some time was doing no maintenance or updates to it, and the use of which is now advised against.

If the plugin has in fact been abandoned in this way, it becomes a mistake for me to keep using it for two reasons:

  1. Updates to the core files of WordPress could create compatibility issues, which only the upkeep of the plugin by its developer could remedy.
  2. Eventually, security flaws can exist in its use, which hackers find, but which the original developer fails to patch.

And so I have now disabled this plugin, from my WordPress blog. My doing so could affect how quickly readers can retrieve certain postings, but should leave the retrieval time uniform for all postings, since WordPress can function fine without any caching, thank you.

memcached_1

Dirk

 

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;

        require_once( dirname(__FILE__) . '/wp-load.php' );

        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:

post-views_3

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.

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

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

 

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.