Tracking Of Media Upload Error In Blog

PressTigers

Tracking Of Media Upload Error In Blog

July 31, 2015
Leave a comment

While working on a blog, Media Upload bug could be faced by any of us. As it generates an error notification while uploading a media file. The error message ‘An error occurred in the upload. Please try again later’ is quite a common one among WordPress users. Also there is no real concurrence about what causes the problem, or what the solution is for this particular issue. It materializes that it is a ‘default error’ in WordPress, which means that it is likely to be thrown in a number of different scenarios. Hence the confusion about fixes. Sometimes the error was only thrown for users with certain WordPress user roles such as for Authors but not for Administrators. When someone switched his/her user role from Administrator to Author, immediately the error occurs. What is causing the problem? Lets find out after debugging the whole process.

Digging Into The Code:

The trial led immediately to this function in wp-admin/includes/ajax-actions.php:

function wp_ajax_upload_attachment() {
     check_ajax_referer( 'media-form' );
  if ( ! current_user_can( 'upload_files' ) )
    wp_die();
  if ( isset( $_REQUEST['post_id'] ) ) {
      $post_id = $_REQUEST['post_id'];
      if ( ! current_user_can( 'edit_post', $post_id ) ) 
wp_die();
  } else {
     $post_id = null;
  }

function wp_ajax_upload_attachment() {

check_ajax_referer( 'media-form' );

if ( ! current_user_can( 'upload_files' ) )

wp_die();

if ( isset( $_REQUEST['post_id'] ) ) {

$post_id = $_REQUEST['post_id'];

if ( ! current_user_can( 'edit_post', $post_id ) )

wp_die();

} else {

$post_id = null;

}

In relevant highlighted section of the code, $post_id was always set to 1. current_user_can(); refers to the permissions that the current WordPress user has. If user is an ‘Author’ in the blog and didn’t create the post with id=1, then he/she will not have ‘edit_post’ permission, because Authors only have rights to edit their own posts. So the upload process fails, and shows that error message.

When posting from the front page of the blog, there is no $post_id value until the post has been submitted. So why was the function above checking for authorizing rights in an unrelated post, the post with id=1?

To figure it out either that post_id was being set in the request or not, it was found that the request made was in a JavaScript file i.e. wp-includes/js/media-views.js. But on the other hand, the post_id value it sent was passed to it via the wp_enqueue_media function in wp-includes/media.php file. It was initialized in wp-admin/includes/media.php file of media_buttons function. The post_id value there was pulled from $_GLOBALS[‘post’] or $_GLOBALS[‘post_ID’] value.

At this point just stop tracing backwards because global values can be set from any number of places. It seems like however this was one of the case where the global post value was irrelevant to the upload process. The post_id set to the global post value that happened to be 1 was the remnant of a previous interaction.

How To Fix?

If we look at wp_ajax_upload_attachment() function, we can see that the process only fails if a post_id value is set and the user doesn’t have rights to edit the post with that id. If no post_id is set at all, everything works as expected. Ideally, we would be able to unset post_id in the theme, leaving core files untouched. Add a simple check to the wp_enqueue_media function in wp-includes/media.php file to test whether to set the post_id value in the JavaScript file or not.

Solution:

Replace the following code in wp_enqueue_media function:

$post = null;
 if ( isset( $args['post'] ) ) {
 $post = get_post( $args['post'] );

$settings['post'] = array(
 'id' =&gt; $post-&gt;ID,
 'nonce' =&gt; wp_create_nonce( 'update-post_' . $post-&gt;ID ),
 );

With this:

$post = null;
 if (isset( $args['post'] ) ) {
 $post = get_post( $args['post'] );

// Test for front page submissions, as with P2 theme
 // In this case global post_id is not applicable and can cause
 // permissions problems for authors, resulting in the dreaded
 // message 'An error occurred in the upload. Please try again later.
 if (is_admin()) {
 $settings['post'] = array(
 'id' =&gt; $post-&gt;ID,
 'nonce' =&gt; wp_create_nonce( 'update-post_' . $post-&gt;ID ),
 );
 }

$post = null;

if ( isset( $args['post'] ) ) {

$post = get_post( $args['post'] );

$settings['post'] = array(

'id' => $post->ID,

'nonce' => wp_create_nonce( 'update-post_' . $post->ID ),

);

With this:

$post = null;

if (isset( $args['post'] ) ) {

$post = get_post( $args['post'] );

// Test for front page submissions, as with P2 theme

// In this case global post_id is not applicable and can cause

// permissions problems for authors, resulting in the dreaded

// message 'An error occurred in the upload. Please try again later.

if (is_admin()) {

$settings['post'] = array(

'id' => $post->ID,

'nonce' => wp_create_nonce( 'update-post_' . $post->ID ),

);

}

The confusingly titled WordPress function is_admin(); returns a Boolean that tells us whether we are in the blog’s Dashboard area or not. This will be true in majority of cases when making a post or uploading a media file. When posting from the front page is_admin() function returns false, no value for the post_id is passed to the JavaScript file i.e. wp-includes/js/media-views.js and the upload does not encounter the permissions problem later in the process. Previous tests showed that the error did not occur when posting from the blog’s Dashboard, so this is a reasonable workaround for now.

Alternative Solution:

It seems that the global post and post_ID values are usually set when making a post from the Dashboard which is a standard WordPress approach. If you are sure that this is the case and don’t mind using WordPress approach of setting global values from here there and everywhere, you could apply a different solution to the problem i.e.; in the media_buttons function, simply reset the post and post_ID global values to 0. In the media_buttons function, add the code highlighted in red below:

function media_buttons() {
 // If we're using http and the admin is forced to https, bail.
 if ( !is_ssl() &amp;&amp; ( force_ssl_admin() || get_user_option( 'use_ssl' ) )  ) {
 return;
 }

include_once( ABSPATH . '/wp-admin/includes/media.php' );
 ob_start();
 global $post_ID, $post;
 $post_ID = $post = 0;
 do_action( 'media_buttons' );
 $buttons = ob_get_clean();

// Replace any relative paths to media-upload.php
 $buttons = preg_replace( '/(['"])media-upload.php/', '${1}' .
 admin_url( 'media-upload.php' ), $buttons );

// Remove any images.
 $buttons = preg_replace( '/&lt;img [^&gt;]*src=("|')(.+?)(1)[^&gt;]*&gt;/i', '', $buttons );

echo $buttons;
 }

function media_buttons() {

// If we're using http and the admin is forced to https, bail.

if ( !is_ssl() && ( force_ssl_admin() || get_user_option( 'use_ssl' ) ) ) {

return;

}

include_once( ABSPATH . '/wp-admin/includes/media.php' );

ob_start();

global $post_ID, $post;

$post_ID = $post = 0;

do_action( 'media_buttons' );

$buttons = ob_get_clean();

// Replace any relative paths to media-upload.php

$buttons = preg_replace( '/(['"])media-upload.php/', '${1}' .

admin_url( 'media-upload.php' ), $buttons );

// Remove any images.

$buttons = preg_replace( '/<img [^>]*src=("|')(.+?)(1)[^>]*>/i', '', $buttons );

echo $buttons;

}

This approach has the advantage of restricting changes to theme while leaving the core file wp-includes/media.php unchanged.

Conclusion:

This is a solution for one instance of ‘An error occurred in the upload. Please try again later’ message. If you’re seeing the same message, your issue may be similar – or not. As it’s a generic message. WordPress’s significant weakness is its excessive dependence on the use of global variables which results in horrible bugs like this one in a non-standard use case scenario, and often can be difficult to troubleshoot and fix.