Getting The Edit-Image Function (Crop) within my (standard) WordPress Media Library to Work Again

My WordPress blog has many plug-ins, in addition to which it uses Debian-maintained core-files, instead of standard downloadable core-files.

Eventually, the error that was irking me enough, to insist on finding the solution, was that within the Media Library function, which is built-in to WordPress 4.1, when I clicked on an image, then on the Edit button, I was obtaining the ubiquitous ‘broken thumbnail’, which also prohibits cropping uploaded images within WordPress itself.

According to the Internet, there can be a wide variety of reasons this bug comes up, including but not limited to, not having ‘php5-gd’ installed. And needless to say, that library is installed on my server, one reason being, the fact that it’s an actual package-dependency, which means that Debian won’t allow us to install WordPress, unless we also install ‘php5-gd’.

(Edit 1/21/2018 :

Additionally, ‘’ core files generally benefit from having the package ‘php5-imagick’ installed, but one reason this may not be declared as a package-dependency under ‘Debian’, could be the fact that to state it as a dependency, would also require that our Debian installation have ‘ImageMagick’ installed, which is a larger suite of programs. Yet, even under Debian, ‘WordPress’ core files check whether the ‘imagick’ PHP-extension is loaded, and if its properties are as required, will try to make use of it.

As it happens, ‘php5-imagick’ was installed on my computer from the beginning (of my use of WordPress). But one question which I still do not know the answer to, is whether WordPress actually needs ‘imagick’, to offer its image cropping and editing capability. I only knew that either way, I had this PHP-extension installed, so that there was little else I could do, to try to offer WordPress what it needed. )

The culprit for me turned out to be, that I was already using an Output Buffer, in order to get rid of leading white-space, which was threatening to make my RSS / Atom Feeds unreadable on many clients, due to plug-ins I have installed, which I don’t even keep track of in a complete way.


This deserves some colloquial explaining. Ideally, if every WordPress plug-in was coded according to best-practices, they would all have leading ‘<?php’ tags at the very beginning of their scripts, and no corresponding ‘?>’ tags at the ends. This way, the creep of white-space – i.e., of blank lines between actual HTML-formatting, and before starting-tags of the HTML document, might be avoidable. But a reality which some instances of WordPress offer instead, is that users like me have many plug-ins, some of which are not coded well, so that blank lines can come in front of the leading tags of the HTML-document itself.

One side-effect of this can be – and early in my own blog was – that when a client-program was pointed either at my Entries RSS Feed, or my Comments RSS Feed, that client-program would just display an error-message, instead of displaying a feed.

So, instead of kicking all possibly-sloppy plug-in code off my blog, many months ago, I installed a script, which set up an Output Buffer, and which, in very specific cases, would clean up the blank lines – the whitespace – that was preceding the document-start. In itself, this was a dubious fix to my problem, and could also corrupt other types of output.

But since then, a situation arose in which such whitespace was causing problems again, without my knowing where. There is a script-file named ‘/wp-admin/admin-ajax.php’. One of the things it does, like so much other Ajax, is allow a hovering -panel in my editing view to be updated, with a preview of an image which I’ve uploaded, but which I might wish to edit from within WordPress, after having uploaded it.

The problem is, that if whitespace gets inserted there, it will just cause garbled JPEG Files to be generated, which the editing panel cannot display within the browser, and for which reason I was unable to Crop such images. But I had to know what was causing the problem.

Continue reading Getting The Edit-Image Function (Crop) within my (standard) WordPress Media Library to Work Again

I am confident that my site is secure again.

What happens from now on, is that ‘WordFence‘ performs routine security scans of my blog. It then emails me with reports.

According to the latest report, emailed to me overnight as I slept, my blog had one issue, out of hundreds of potential issues: One of my plug-ins needed an upgrade.

Of course, I would have seen that this plug-in required an upgrade anyway, as soon as I checked my Dashboard this morning, which showed me the same result.




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

I use, not, 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 and . is a specialized blog-hosting site, on which members can write their blogs, but which runs on professionally-maintained servers, by .

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 uses actually to store the blogs.

And so, because this support-factor is the main part of the expenses incurred by, 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, where independently-hosted WordPress users can go for tech support, and to download plug-ins.

Continue reading I use, not, for most of what I subscribe to.