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

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.

One aggravating factor was, that even though the script I had installed did have as function to get rid of leading whitespace, it was also programmed prudently enough to leave any content alone – with the offending whitespace left in – if said content was not an RSS Feed.

And so the solution to my problem was, to tell the buffer set up by this script, to drop all its contents, just prior to where ‘admin-ajax.php’ would normally start outputting its proper header-information. Apparently, the offending whitespace had already been written to this buffer, by then.

Apparently what I needed to do, was to clear this Output-Buffer, before any output commences from the ‘admin-ajax.php’ File.

<?php
/**
* WordPress AJAX Process Execution.
*
* @package WordPress
*
*/

/**
* Executing AJAX process.
*
* @since 2.1.0
*/
define( 'DOING_AJAX', true );
if ( ! defined( 'WP_ADMIN' ) ) {
}

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

ob_clean();

/** Allow for cross-domain requests (from the frontend). */

// Require an action parameter
if ( empty( \$_REQUEST['action'] ) )
die( '0' );

/** Load Ajax Handlers for WordPress Core */

@header( 'Content-Type: text/html; charset=' . get_option( 'blog_charset' ) );




This needed to be put once, before the script generated any output.

And the result is:

Yess !

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.