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 WordPress.org 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, ‘WordPress.org’ 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

MySQL Server Update Today, No Downtime

I use the home-computer I name ‘Phoenix’ as my Web-server. This means that I’m always looking for ways to complete routine system updates, without wanting my server to go offline, as my server going offline would also mean, that for several minutes, my site is not accessible to the public. My server would go offline for a few minutes, if I simply needed to reboot it.

Today came another time, when an update to my MySQL (Database-) Server became due. I have two instances of MySQL running:

  1. As a system process, which serves my Web-site and blog,
  2. As a user-process, which serves the desktop-PIM-daemon also known as “Akonadi”.

Simply having installed the MySQL update, will assure that the system-process is also restarted. But it will not assure, that the user-process is also restarted.

In such cases, what I can often do, is, after the update is finished, Log Out my user-session, and Log it back In. Doing so does not fully reboot the computer, but just restarts the user-space processes, which make up my session, including Akonadi, and including that MySQL user-process.

Today, after the update itself, I performed such a log-out-followed by the log-in. What this means is that my Web-site should have remained accessible the whole time. Yay!

This was the last time, I had accomplished the same thing.

Dirk

 

Routine WordPress Update Today.

One of the facts which I’ve written about often, is that I host my site, and therefore my blog, on my private computer at home, named ‘Phoenix’.

One advantage this gives me, is the ability to program my Web-server in any way I please. When people subscribe to Web-hosting services, unless they are subscribing to a Virtual Private Server, they receive whatever set of server-side resources their hosting service is willing to offer them. This way, I get to install those myself.

The WordPress blogging engine of this blog, is similar to ‘WordPress.org‘, but is actually a version, the core files of which are managed by the Debian Package Maintainers. This WordPress installation just received an update this morning, to version ‘4.1+dfsg-1+deb8u16′. One detail which is tricky in my case, about receiving updates to the core-files via the package-manager, is that I nevertheless subscribe to plug-ins, from WordPress.org. Therefore, If I did not manage the application of the package-update correctly, I could end up with a mess on my hard drive, since what most Debian package maintainers expect, is for their users to receive all updates to their software, from them.

I’m happy to say that this update seems to have taken place smoothly, and in a way that respects the arrangement of files which I have between core files, maintained by Debian, and plug-in files, maintained by me.

All systems are go, and there was no appreciable downtime.

Dirk

 

Getting the Orca Screen-Reader to work under Plasma 5

In case some readers might not know, even though computing is heavily visual, certain advanced desktop-managers can be set up for impaired people to use – which also falls under the category of “Accessibility”. This includes the ability of the computer to speak a robotic description of what’s happening on the screen, in case a user can hear, but not see properly.

There are some users who feel they should stick with Windows, because Accessibility can be so hard to set up under Linux.

There are other users who are sorry they every clicked on “Accessibility”, because now they cannot turn it off.

If a visually-impaired user wants Accessibility set up on a Linux computer, I’d definitely suggest letting a trusted other person set it up, because until it’s set up, complicated things may need to be done, and accessibility will not be set up, so that the end-user will not benefit from Accessibility, while trying to set it up.

Some regular users find screen-readers trying for their patience, because of the fast, robotic voice, until they manage to shut it down again. Personally, I only find screen-readers trying, If I happen to have set one up late at night, because the voice could cause some sort of noise-complaint from my neighbors, droning on until I manage to disable it again. In the middle of the day, I don’t find these experiments trying.

I guess that a good question which some people might ask me, would be why I even do such an experiment, given that I’m not visually impaired and don’t need it. And what I do is set everything up until it works, and then disable it again.

On my recently-installed Debian / Stretch computer named ‘Plato’, which is also running Plasma 5 as its desktop-manager, I just did manage to get this feature to work, and then to disable it again.

(Updated 15h50, 1/17/2018 : )

The first thing I had to do, was install a long list of packages. The list below includes what was installed, but it should not really be necessary to give the command to the package-manager manually, to install everything here, because some of these packages will follow as dependencies from other packages. But here is a roundabout list:

Continue reading Getting the Orca Screen-Reader to work under Plasma 5