The next question will demonstrate that you are really keen. Ask them to reproduce the bug on a-not-her machine
Continuing from verse 20 – Simplify; sticking with TRAC #30052. It seemed I could not reproduce the problem on my newly upgraded Windows server, running PHP 5.5.18 and Apache 2.4.
There didn’t seem to be anything special about the problem that would prevent me from reproducing it in my development environment. I set about debugging it using my trace routines.
I finally discovered that WordPress knew all along what the problem was but it wasn’t going to let me know.
Deep down in the bowels of the code there was a call to [api wp_get_image_editor]. When I installed PHP 5.5.18 I hadn’t enabled the php_gd2.dll extension.
WordPress was issuing a WP_Error( ‘image_no_editor’, __(‘No editor could be selected.’) but that error wasn’t filtering up to the browser.
Had it done so I would have quickly been able to fix the php.ini configuration problem
; Need GD with function gd_info() for Async media upload extension=c:/php/ext/php_gd2.dll
And then I’d have been able to reproduce the problem I was seeing on the Linux servers.
So that’s another bug to report I suppose.
See also
- TRAC #30052 – Add New Media Drag and Drop Hangs on Crunching
- Problem Solving – Top 10 questions to ask when something doesn’t work
Note: In the screen capture we see the output produced by Xdebug, which clearly shows the call stack that leads to the Undefined index message.
My php.ini file contains
zend_extension = c:\php\ext\php_xdebug-2.2.6-5.5-vc11-x86_64.dll [xdebug] ; Enable this to automatically get the call stack when something goes wrong ; this will get logged in the PHP errors log xdebug.default_enable = 1