## The PrintFriendly Button Is Back.

One of my less-commendable habits, is to add plugins to my WordPress blog, which might not be necessary, but which might OTOH be useful after all.

There is now a button at the bottom, left-hand side of my postings, which has a little printer icon, which my readers can click, in order to obtain a printable version of my postings.

There was an earlier point in time, when I took this plugin to be potential malware, because its presence in the browser causes scripts to run from other domains, and I did not think it wise, to be inviting scripts to run as part of my blog, which I do not know the purpose of, and which exist, because the Web-site of a plugin, includes another Web-site I know nothing about, which runs a script. So at that time, I went into high alert for no other reason, installed a whole security suite named “WordFence”, and removed the “PrintFriendly” plugin from my site.

Since then, my confidence in the security of my own site has improved – in spite of the fact that I’m still installing plugins – and I’ve come to think that my reaction back then might have been a bit unscientific. After all, even though I could know for certain that this unidentified script was being loaded onto my browser – which subsequently blocked it – I had no sure way of knowing it contained malware. The script in question may simply have had as purpose, to provide some sort of funding to the site that hosts PrintFriendly.

If the reader clicks on this icon, he’ll see that a floating window pops up, from which he can choose how – or if – he wants to print my posting. That floating window will only appear, if the reader allows his browser to run scripts from ‘printfriendly.com’. That floating window is still hosted on the other party’s server – belonging to PrintFreindly and not to me – and because that floating window is being hosted on their server, it also represents a resource which they need to pay for in some way, even though I’m not paying them.

Now, WordFence has a feature (enabled on my blog), that is called a ‘Front-Side URL Scan’. In short, instead of only scanning my plugin folders for trouble, this feature examines all the URLs which the home-page of my blog sends to the would-be browsers, and compares those URLs to blacklists of known malware. I will next be able to see, whether the URL in question was actually blacklisted – by anybody other than me. If it was, this plugin will disappear again from my blog.

But for now, I’m giving this plugin another chance.

Dirk

## And Now, Memcached Contributes to This Site Again!

According to this earlier posting, I had just uninstalled a WordPress plugin from my server, which uses the ‘memcached‘ daemon as a back-end, to cache blog content, namely, content most-frequently requested by readers. My reason for uninstalling that one, was the warning from my WordFence security suite, that that plugin had been abandoned by its author.

Well, it’s not as if everything was a monopoly. Since then, I have found another caching plugin, that again uses the ‘memcached‘ daemon. It is now up and running.

(Screenshot Updated 06/19/2017 : )

One valid question which readers might ask would be, ‘Why does memcached waste a certain amount of memory, and then allocate more, even if all the allocated memory is not being used?’

(Posting Updated 06/21/2017 … )

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

Dirk

## WordPress Debian Update Today

I use a version of WordPress to host my blog, which is very similar to the versions offered by WordPress.org, but which have been tweaked by Debian Developers, to add security, as well as to increase compatibility with Debian Linux.

But, it’s my personal habit to operate this platform with the ability to install plugins and Themes from the WordPress.org site. Making this available involves some trickery with symlinks and with directory ownership. Yet, WordPress itself is designed with flexibility in mind, when it comes to local configurations. So it tolerates this as a platform.

But from time to time, Debian Maintainers push through an update to their core version of WordPress – which I am using. I happen to have my core files installed in ‘/usr/share/wordpress‘, while I have my extensions installed in ‘/var/lib/wordpress/wp-content‘. The permissions and ownership for these two directories, as well as their subdirectories, involves two different settings in my configuration. One directory, with all its subdirectories, is not writable by the Web-server, while the other is.

When Debian Team pushes through one of these updates, it can break how my personal localization works, because Debian Team is inherently unaware of how any systems may be configured, which are not Debian. This is a bit like how Microsoft programmers inherently don’t understand anything which is not Microsoft.

Sometimes I have installed the update to the core files, without any issues, but sometimes, some additional, manual work is required on my part, to ease the update.

This afternoon, the core files installed fine, and left me with a working blog. But there exist some Themes and plugins which need to be installed from the package manager, to ensure a working site, but of which I usually have the latest versions, from WordPress.org instead. The packaged versions of these Themes and plugins generally tend to lag behind, the most up-to-date versions from WordPress.org.

This means that after one of the core updates, I typically need to reinstall the update, to whatever Themes and plugins the package-manager update has rolled back.

This morning, that added step in my procedure ran into some trouble. But, I was able to resolve the issue in little time, and my blog seems to be at 100% again.

Now, I do have a plugin which puts up a Maintenance Mode page, for as long as I like. But generally, I find that this plugin only hinders me. For one thing, if some type of mess results on my hard drive, having this page enabled could prevent me from disabling it again, and from fixing the issue. Secondly, whatever maintenance I do, is generally finished within 15 minutes or so. So I generally don’t use this plugin.

This afternoon, I began by allowing the core update to take place around 13h30, at which point the blog was still displaying fine. But I ran into issues getting the “TwentyFifteen” Theme back up-to-date, which would have caused any readers to see artifacts when trying to view my page, which were all gone and repaired by 13h45.

So for 15 minutes, readers might have seen some artifacts. If you did, I truly apologize. If I had used the Maintenance Mode plug-in, then doing so would have made my manual procedure more complicated, so that you might have seen the Maintenance Mode page instead, all the way until 14h00. In other words, the task could have taken twice as long to complete than it did.

My official WordPress version is now ‘4.1+dfsg-1+deb8u14‘. And it works again.

Dirk

(Edit: There exists a phenomenon in Human Psychology, with a name I forget. Essentially it amounts to stubbing one’s toe on a table-leg, and due to the unexpected or even inconvenient timing of the pain, blaming the table-leg for the accident. In retrospect, now that this pain is gone, I’d say this SNAFU was entirely my own fault.