Edit Media / Edit Images doesn’t work.

  • Resolved dirkmittler

    (@dirkmittler)


    8 years ago

    Hello.

    I run a Debian / Jessie version of WordPress as indicated. For the most part it runs well, and when there are problems I usually get them fixed. This means I am also running my own Apache server from home.

    There has been one annoying functionality, which I do not benefit from. When I go into my Media Library, Select an Image, and then click on Edit, I get a broken image preview icon, and no ability to edit.

    I have narrowed this problem down. to an AJAX call to the file

    /usr/share/wordpress/wp-admin/admin-ajax.php

    I can duplicate the call to that file as an HTTP call from my browser, and find the only thing this file outputs, is the ASCII numeral 0 (zero) – where it should output some sort of image. AFAIK, this problem has always existed, or has at least existed since my first attempt to edit an image from within WordPress.

    I see over 200 postings on the Web, where other WordPress bloggers report the exact same problem. But then in pursuit of each case, each thread predictably runs into a dead end. Out of 200 postings, there is not 1 adequate explanation for why this happens.

    In some cases, the OP thanks the other posters profusely, to confirm that this problem is theoretically possible. Another thread goes careening on some wild tangent. Each thread greets the OP with some wild chaotic response, that offers no conclusion, and then just dies.

    I would like to know once and for all, what no other WordPress blogger has ever found an answer to: What causes this malfunction? BTW, I have the package

    php5-gd

    Installed, as I am supposed to, and in certain other Web-applications on my server, this package works. Also, this package successfully builds thumbnails and resized versions of the uploaded images automatically, in

    /srv/www/wp-content/dirkmittler.homeip.net/uploads/…

    I would hate to install a 3rd-party photo-editing plug-in, and my main reason is the fact that the ones I have found are cloud-based. My second reason not to would be, the fact that I can just GIMP whatever images I want on the same machine – I am not critically dependent on this working inside WordPress.

    I do not have bizarre rewrite rules in my .htaccess, only the rules which belong there.

    I do not have mod_security installed, and do not have mod_headers enabled. I have created no special restrictions against myself accessing the folder

    /usr/share/wordpress/wp-admin

    I.e., I can admin my blog just fine. I think I would notice, if I could not. And here is my blog:

    https://dirkmittler.homeip.net/blog/

    I have scanned dozens of server-scripts for that closing ?> , but wouldn’t you know it, none of the scripts I have tested, contain that basic PHP bug. I do not intend to output-buffer all my content, to ob_clean() it. And I do not intend to delete my ‘functions.php’ file, and think this will achieve anything other than a full failure of the site.

    Please, suggest more chaotic answers, and then tell me the problem is fixed! ??

    Dirk

    Oh, And my .PHP Files are Not UTF-8 encoded, with a BOM. My PHP-Scripts are ASCII-encoded, with no BOM.

    Edit: Some posters wanted to know the full list of plug-ins which the OP had installed, because maybe in some cases, there could be a plug-in intercation causing this. Well, this is my info on that subject:

    root@Phoenix:/var/lib/wordpress/wp-content/plugins# ls
    akismet media-library-assistant
    awesome-weather memcached-is-your-friend
    captcha metronet-profile-picture
    captcha-pro plugins
    custom-scrollbar postie
    custom-scrollbar-pro post-views-counter
    email-users printfriendly
    featured-video-plus transposh-translation-filter-for-wordpress
    google-sitemap-generator update-control
    htaccess user-role-editor
    index.php who-hit-the-page-hit-counter
    insert-headers-and-footers who-hit-the-page-widget
    limit-attempts widget-logic
    limit-attempts-pro wordpress-importer
    limit-login-attempts-reloaded wp-mail-smtp
    lj-maintenence-mode wp-postviews
    root@Phoenix:/var/lib/wordpress/wp-content/plugins#

    Note: Some of these are not activated. Eg, since I have both limit-attempts and limit-attempts-pro, limit-attempts would be redundant. And, media-library-assistant and metronet-profile-picture are not activated.

    Although some plug-in interaction might be causing this, in my case there are so many, that it is a pointless theory to pursue. And, why would so many other OPs, of other threads, necessarily have the same plug-ins as I do?

    And, I have actually examined the PHP-Script ‘admin-ajax.php’.
    It sets the variables ‘$core_actions_get’ and ‘$core_actions_post’, with an array of AJAX-Actions. The action ‘imgedit-preview’ is nowhere in the lists.

    If the requested action is not found, it defaults to

    // Default status
    die( ‘0’ );

    • This topic was modified 8 years ago by dirkmittler. Reason: Preempt another solution offered elsewhere
    • This topic was modified 8 years ago by dirkmittler. Reason: Certain sensible questions can be anticipated, which have full answers
    • This topic was modified 8 years ago by dirkmittler. Reason: Supplementary Observation
Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter dirkmittler

    (@dirkmittler)

    Sorry.

    The action ‘imgedit-preview’ is included in ‘$core_actions_get’.

    Dirk

    Thread Starter dirkmittler

    (@dirkmittler)

    I’m sorry to bump this posting again.

    But in the file

    /usr/share/wordpress/wp-admin/admin-ajax.php

    There is code which looks like this:

    if ( is_user_logged_in() ) {
    /**
    * Fires authenticated AJAX actions for logged-in users.
    *
    * The dynamic portion of the hook name, $_REQUEST['action'],
    * refers to the name of the AJAX action callback being fired.
    *
    * @since 2.1.0
    */
    do_action( ‘wp_ajax_’ . $_REQUEST[‘action’] );
    } else {
    /**
    * Fires non-authenticated AJAX actions for logged-out users.
    *
    * The dynamic portion of the hook name, $_REQUEST['action'],
    * refers to the name of the AJAX action callback being fired.
    *
    * @since 2.8.0
    */
    do_action( ‘wp_ajax_nopriv_’ . $_REQUEST[‘action’] );
    }

    I suppose that a valid question to ask might be, how does an AJAX request know that the client is logged in, since ‘imgedit-preview’ clearly requires this? And the answer seems to be that the AJAX GET request has code that goes like this:

    /blog/wp-admin/admin-ajax.php?action=imgedit-preview&_ajax_nonce=

    Where the ‘_ajax_nonce’ parameter is a log-in cookie. If something was preventing WordPress from recognizing this, it could prevent the action from firing. But the action produces no errors in the error log, returns with Code 200, but returns Numeral 0.

    Dirk

    Similar issue here. Tailing the error log shows no errors thrown. Just checked permissions and ownership on wp-content/uploads — all is well.

    Would love to be able to crop images using the built-in WP tools. I’m delighted this photon API is available for Jetpack users. At the same time, every “Attachment Details” image is broken and un-editable even though I can reference them from pages and see them in the file system.

    https://www.dropbox.com/s/9phm02d75k2see0/WP-MediaLib-Edit-Media.png?dl=0WP-MediaLib-Attachment-Detailsc=”https://www.dropbox.com/s/9phm02d75k2see0/WP-MediaLib-Edit-Media.png?dl=0″ alt=”WP Media Library – Edit Media – broken” />

    Still No Joy for me on editing (cropping, etc) items already in the Media Library.

    No errors in error.log. Plenty of related items in access.log, but all 200.

    The broken images I get from “Edit Image” on “Attachment Details” have URLs like this:

    https://mysite.com/wp-admin/admin-ajax.php?action=imgedit-preview&_ajax_nonce=1209cc&postid=1265&rand=43147

    Thread Starter dirkmittler

    (@dirkmittler)

    Hi.

    I was the person who started this posting.

    I have a vague suspicion that this issue is due, to how the Debain package-manager-installed version of WordPress, may be coded differently from the public PHP-Files we could just upload to a server.

    More specifically it would have to do with the fact that Debian Package Maintainers will either include a core functionality, and then make whichever libraries it depends on a necessary dependency, for installing the main package – i.e.,

    php5-gd

    Or, how they would otherwise just not put code into the core application, that tries to connect with such a library.

    I’ve read in several places that what we need, to get this crop-preview to show properly, is actually

    php5-imagick

    And, because that’s not an explicit dependency, the core application will omit any codes that would try to use it. But that’s just my guess.

    What I have found, is that there’s another way to edit images within WordPress, and that is, to click on the image in our visual editing panel, where we have inserted the image into our posting. When we do that, some buttons appear, including an Edit button – stylized as a pencil. And everything that gets accessed via that editing button – works! ?? This includes, to choose one of the image-sizes, that php5-gd automatically created for us, as well as how to justify the image and several other options. It still does not include a crop feature.

    And so, I cannot believe there is anything seriously wrong with my WordPress installation. I just can’t crop.

    Dirk

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Edit Media / Edit Images doesn’t work.’ is closed to new replies.