Add New Media Drag and Drop Hangs on Crunching

[Gregory_Lang]

When using the drag-and-drop feature of "Media -> Add New" the upload hangs at "Crunching...".

After extensive testing, I have determined this occurs when the auto_increment primary key (ID field) on the "wp_posts" table reaches 1000. If I delete content and reset the key to 999 or below "Add New" works but, when the key hits 1000 "Add New" get stuck at "Crunching...". I can find no errors in any logs or by using the "backtrace-errors.php" debugging file.

I have been able to duplicate this issue on multiple WordPress servers.

Note - Images do get uploaded and processed and the entries are placed correctly in the database. The problem is that the upload screen gets stuck displaying "Crunching..." along side the primary key number.

[johnbillion]

Thanks for the report Gregory_Lang.

I've tested this on two separate servers and cannot reproduce the issue.

Can you test this again with all your plugins deactivated and with the default theme enabled please? I know you said that you've reproduced this on multiple sites, but there may be a common plugin between them that is causing a problem.

In addition, do you have any language packs installed on the site, or any plugins in the mu-plugins directory that could be interfering?

If none of the above appear to be the issue, please let us know the exact version of PHP, Apache/Nginx, MySQL, and the operating system on your server(s).

Finally, if you can use your browser debugging tools to inspect the response to the AJAX call which gets triggered when the file is uploaded, that would help immensely (I suspect there is some unwanted output in the AJAX response).

[Gregory_Lang]

I'm working on an "Amazon Linux" instance in AWS and this is what I did:

• Built a new base image using Amazon Linux x86_64 version 2014.09
• Installed Apache version 2.4.10
• Installed MySQL version 5.5.40
• Installed PHP version 5.4.34
• Downloaded WordPress version 4.0
• Created a blank database and then ran the WordPress configurator
• Logged in to 'wp-admin', went to "Media -> Add New" and drug a file into the area that says "Drop files here" and it worked.
• Logged in to MySQL and ran "ALTER TABLE wp_posts AUTO_INCREMENT =1000;"
• Logged back in to 'wp-admin', went to "Media -> Add New" and drug a file into the area that says "Drop files here" and on the left side of the screen I got "1000" while on the right side I got "Crunching..."

At this point, I can reduce the auto increment value to below 1000 and the drag and drop works again but, as soon as it hits 1000 the problem returns.

I'll try the browser debugging tools tonight to see what I can find.

[johnbillion]

Were you able to look into the AJAX response Gregory? I think that will be the key to finding out what your issue is.

I'm going to close this ticket for now as it's most likely a localised issue, but please feel free to continue commenting with your findings. We can re-open the ticket if it does turn out to be a core issue.

[Gregory_Lang]

I wasn't able to find anything looking at the Ajax response but I was able to determine this problem only happens on instances within the AWS cloud. I have not been able to duplicate the issue outside the AWS environment. I have opened a support ticket with AWS to have them research the issue also.

[bobbingwide]

I was getting the same unexpected result. The Crunching... never ended.

Notes:

• The filename changed to the new post ID ( 29144 in the latest instance )
• When I viewed the media page everything looks OK.
• Also the Crunching... is on the far right hand side.
• In working environments the crunching is not so far to the right.
• Post ID of > 1000 is not an issue in the working environments.

When I deactivated ALL my plugins the Crunching did complete.

• And I can now confirm that the problem was caused by my own tracing plugin...
• which was outputting some HTML comments during 'shutdown' processing.
• So the response was no longer a single integer.
• I have reproduced the problem in different environments with post ID < 1000
• The placement of the Crunching on RHS is a red herring.

Unfortunately my code checks for DOING_AJAX, but since $_REQUEST['action'] is NOT set then wp-admin/async-upload.php doesn't set it. Is it safe to test $_REQUEST['short']?

The question one might ask is "should there be some way
of communicating to routines that hook into 'shutdown' that the response has been sent and you mustn't do anything to mess it up?"

Could the client end be a little less sensitive?

[bobbingwide]

Just to confirm that I have performed "ALTER TABLE wp_posts AUTO_INCREMENT =1000;"
but didn't get the problem.
When I tried to reset the value to a number below 1000 the new post IDs were still above 1000.

However... on another site, while investigating the placement of the crunching red herring I did get

<br />
<b>Notice</b>:  Undefined index: extension in <b>/home/herb/public_html/wp-includes/class-wp-image-editor.php</b> on line <b>360</b><br />
<br />
<b>Notice</b>:  Undefined index: extension in <b>/home/herb/public_html/wp-includes/class-wp-image-editor.php</b> on line <b>360</b><br />
18948

This is with WP_DEBUG( 'true' );

The file I was uploading is called !.jpg

I can reproduce the problem on PHP 5.3.29 with a Linux server

The target file simply becomes jpgn, with a thumbnail called jpgn-300x182.

0. bw_lazy_backtrace /home/herb/public_html/wp-content/plugins/oik/bwtrace.inc:60 0
1. bw_backtrace /home/herb/public_html/wp-includes/class-wp-image-editor.php:358 0
2. generate_filename(_{) /home/herb/public_html/wp-includes/class-wp-image-editor-imagick.php:451 3}
3. _save(object) /home/herb/public_html/wp-includes/class-wp-image-editor-imagick.php:301 1
4. multi_resize(Array) /home/herb/public_html/wp-admin/includes/image.php:120 1
5. wp_generate_attachment_metadata(18952,/home/herb/public_html/wp-content/uploads/2014/11/jpg6) /home/herb/public_html/wp-admin/includes/media.php:345 2
6. media_handle_upload(async-upload,0) /home/herb/public_html/wp-admin/async-upload.php:87 2

generate_filename(10) this_file WP_Image_Editor_Imagick Object

    [image:protected] => Imagick Object
        (
        )

    [file:protected] => /home/herb/public_html/wp-content/uploads/2014/11/jpg6
    [size:protected] => Array
        (
            [width] => 300
            [height] => 182
        )

    [mime_type:protected] => image/jpeg
    [default_mime_type:protected] => image/jpeg
    [quality:protected] => 
    [default_quality:protected] => 90

$_FILES in media_handle_upload is

    [async-upload] => Array
        (
            [name] => !.jpg
            [type] => image/jpeg
            [tmp_name] => /tmp/phpaVY9vv
            [error] => 0
            [size] => 88711
        )

Note: I can also produce the problem on a PHP 5.5.18 Windows server using WP_Image_Editor_GD

It would appear that sanitize_file_name() is to blame - reducing the file to

    [0] => jpg

The question is... What is the expected output of sanitize_file_name() when it's all special characters?
Until I know the answer I can't develop a fix.

[dfavor]

I'm unsure if this is the correct place to add my current problem.

With 4.1 I have a client site getting the stuck in Crunching message too.

ID < 1000 (approaching 800).

When I look at Chrome -> Inspect Element -> Network - async-upload.php - appears to hang.

Nor do I get any class-wp-image-editor.php errors, with WP Debug on + XDebug.scream on which should spew anything out of ordinary.

Suggestions for debugging appreciated.

[dfavor]

Tracing the value of $_REQUEST in wp-admin/async-upload.php around line #50 turns up possibly useful data.

In working systems, $_REQUEST contains:

'attachment_id' => string '835' (length=3)
'fetch' => string '3' (length=1)

Broken sites contain...

'name' => string 'test-image.png' (length=14)
'post_id' => string '0' (length=1)
'_wpnonce' => string '96fedbd5d9' (length=10)
'type' => string (length=0)
'tab' => string (length=0)
'short' => string '1' (length=1)

So if attachment_id + fetch are missing from $_REQUEST, the logic never fires to populate the thumbnail markup data.

[dfavor]

Any suggestions for how to trace $_REQUEST to determine where it's being munged?

[dfavor]

I've identified the problem + fixed it on two client sites.

A less-than-intelligent developer modified the theme's functions.php + wp-config.php to this PHP preamble...

<?php?><?php

instead of the correct...

<?php

The effect was to prepend a <?php?> to all emitted content.

Usually I pass all sites through the W3C Validator first + missed doing this for some reason or I'd have caught this.

My guess is that an JSON returned during an AJAX conversation would have been an error with <?php?> prepended.

For now all's well.

[SergeyBiryukov]

Looks like we have three distinct issues here:

1. An issue with auto increment on wp_posts ID field hitting 1000 on AWS environment.
2. An issue when uploading a file named !.jpg (comment:7).
3. An AJAX response broken by prepending <?php?> (comment:13).

1 is probably still a worksforme, 3 is now resolved. Let's create a new ticket for 2 and close this one.

[bobbingwide]

Hi, re Sergey's closing comments

2. did anyone create the ticket for !.jpg ?
3. I often have problems with AJAX responses being broken. Is there anything that can be done to make the receiving end less sensitive to unexpected output before and after the expected JSON content?

[wonderboymusic]

Taking off the close list for now