| 4 | | The filename changes to the new post ID ( 29144 in the latest instance ) |
| 5 | | When I view the media page everything looks OK. |
| 6 | | Also the Crunching... is on the right hand side. |
| 7 | | |
| 8 | | |
| | 4 | * The filename changed to the new post ID ( 29144 in the latest instance ) |
| | 5 | * When I viewed the media page everything looks OK. |
| | 6 | * Also the Crunching... is on the far right hand side. |
| | 7 | * In working environments the crunching is not so far to the right. |
| | 8 | * Post ID of > 1000 is not an issue in the working environments. |
| | 12 | * And I can now confirm that the problem was caused by my own tracing plugin... |
| | 13 | * which was outputting some HTML comments during 'shutdown' processing. |
| | 14 | * So the response was no longer a single integer. |
| | 15 | * I have reproduced the problem in different environments with post ID < 1000 |
| | 16 | * The placement of the Crunching on RHS is a red herring. |
| | 17 | |
| | 18 | 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']? |
| | 19 | |
| | 20 | The question one might ask is "should there be some way |
| | 21 | of communicating to routines that hook into 'shutdown' that the response has been sent and you mustn't do anything to mess it up?" |
| | 22 | |
| | 23 | Could the client end be a little less sensitive? |
| | 24 | |
| | 25 | |
| | 26 | |
| | 27 | |
| | 28 | |
| | 29 | |