## PrintFriendly Button

In the bottom left-hand corner of each of my postings, the reader will see a little icon that has a printer-symbol on it, and the word “Print”. This icon can be used either to print the posting in question, or to save it to a PDF File, on the reader’s computer. In fact, the reader can even delete specific paragraphs from his local copy of my posting – since plausibly, the reader might find some of my postings too long to be printed in their entirety.

Some time ago, I had encountered a situation where Not code belonging to this plug-in, but Rather the URL which hosts the service, was showing me a warning in my browser, that ‘unknown URLs’ were trying to run scripts.

My own Web-browser has a script-blocker, which will display scripts to me which a page is trying to display, but which I did not authorize.

Certain features which I use on my blog, are actually hosted by the Web-site of 3rd parties, whose scripts may run, just because my page includes their widget.

The first time I noticed this I went into an alarm-mode, and removed the button from my blog quickly, thinking that maybe it was malware. But some time after that, I installed an additional extension to my blogging engine, called “WordFence”. This is an extension that can not only scan the (PHP-) code present on my own server for viruses and other malware, but that can also just scan whatever HTML my blogging engine outputs, for the possible presence of URLs to sites that are black-listed, regardless of how those URLs ended up being generated by my blogging engine.

Once I had WordFence installed, I decided that a more-Scientific way to test the PrintFriendly plug-in, would be to reactivate it, while WordFence is scanning my site. If any of the URLs produced by this plug-in were malicious, surely WordFence would catch this.

As it stands, the PrintFriendly button again displays URLs which belong to parties unknown to me. But as it stands, none of those URLs seem to suggest the presence of malware. I suppose, that the hosts of PrintFriendly rely on some of those scripts, to generate income? Since I’m not required to pay, to use their button.

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

## WordFence

One of the facts which I have written about before, is that my blog is set up in a slightly customized way, with core PHP files that come from the Debian package manager, and which do not have permission bits set, so that the Web-server can write to them, but also with add-ons – aka plugin-ins – with permission bits set so that the server can. This latter detail is a great convenience for me, because it allows me to install plug-ins from WordPress.org, as well as to install updates to those, via means that are simple for me to operate.

What I have also written, is that this makes my overall security good, but not perfect. Theoretically, there could be a corrupted plug-in available directly from WordPress.org – even though in general, they do their best to vet those – and which I could install to my blog, without knowing it. Further, even if the plug-in contains no dirty code visible to WordPress.org, the way some of them work might depend on a Web-service from their author, and then that URL could be running some sort of suspicious scripts, let us say on yet another server.

And so a reasonable question to ask might be, of what use WordFence can be in my case. One of the types of scans which this security add-on performs, is a check of all my core files, against what the versions are with WordPress.org, not with Debian. And then this scan reports 58 deviations to me, without analyzing them, just because Debian has slightly different core-file-versions. It also checks my entire plug-in directory, scans all the plug-ins, etc.. But in reality, WordFence never reported any kind of anomaly in my plug-ins, because those are the WordPress.org versions.