add_media 'Uploaded to this post' listing unattached files when post type does not support 'thumbnail'

[bobbingwide]

If you have a post type which does not support 'thumbnail' then I have noticed that using Add Media and selecting "Uploaded to this post" you get shown a list of media files which are NOT attached to the post.

Note: This problem was first noticed with WordPress 3.9 and originally attributed to an unknown problem with Easy Digital Downloads.

I was able to overcome the problem by adding post type support 'thumbnail' to the custom post types which exhibited the problem.

I was also able to demonstrate the problem with the 'post' post type by adding a trivial plugin which removed thumbnail support.

add_action( "init", "rfi" );
function rfi() {
  remove_post_type_support( 'post', 'thumbnail' );
}

On the demonstration site the problem occurred when EDD was active. and didn't when it wasn't.

Having upgraded to WordPress 3.9.1, a different site started exhibiting this problem; even when EDD is not activated. It now appears that WordPress SEO is the plugin that's causing the problem.

Note: I have not yet determined the true cause of the problem.
The workaround ( to include 'thumbnail' support) is still effective.

With regards to related defects, you should also be aware of the scenario.
I used shortcodes to display attachments. When I upload the file using Add Media I expect it to be automatically attached. The attachments are not expected to be inserted into the post.

#8490 - I agree with westi and azaozz

[bobbingwide]

I have traced this problem further. It would appear that the wp_enqueue_media() function is being called multiple times by different actions.

With WordPress SEO it first gets invoked by 'admin_enqueue_scripts'

0. bw_lazy_backtrace C:\apache\htdocs\wp-content\plugins\oik\bwtrace.inc:59 0
1. bw_backtrace C:\apache\htdocs\wp-includes\media.php:2660 0
2. wp_enqueue_media C:\apache\htdocs\wp-content\plugins\wordpress-seo\admin\class-metabox.php:712 0
3. enqueue(post.php) C:\apache\htdocs\wp-content\plugins\wordpress-seo\admin\class-metabox.php:0 1
4. call_user_func_array(Array,Array) C:\apache\htdocs\wp-includes\plugin.php:470 2
5. do_action(admin_enqueue_scripts,post.php) C:\apache\htdocs\wp-admin\admin-header.php:80 2
6. require_once(C:\apache\htdocs\wp-admin\admin-header.php) C:\apache\htdocs\wp-admin\edit-form-advanced.php:365 1
7. include(C:\apache\htdocs\wp-admin\edit-form-advanced.php) C:\apache\htdocs\wp-admin\post.php:211 1

but the post information is not passed until 'media_buttons'

0. bw_lazy_backtrace C:\apache\htdocs\wp-content\plugins\oik\bwtrace.inc:59 0
1. bw_backtrace C:\apache\htdocs\wp-includes\media.php:2660 0
2. wp_enqueue_media(Array) C:\apache\htdocs\wp-admin\includes\media.php:523 1
3. media_buttons(content) C:\apache\htdocs\wp-admin\includes\media.php:0 1
4. call_user_func_array(media_buttons,Array) C:\apache\htdocs\wp-includes\plugin.php:470 2
5. do_action(media_buttons,content) C:\apache\htdocs\wp-includes\class-wp-editor.php:205 2
6. editor(,content,Array) C:\apache\htdocs\wp-includes\general-template.php:2284 3
7. wp_editor(,content,Array) C:\apache\htdocs\wp-admin\edit-form-advanced.php:497 3
8. include(C:\apache\htdocs\wp-admin\edit-form-advanced.php) C:\apache\htdocs\wp-admin\post.php:211 1

with wp_enqueue_media() there is a test to see if 'wp_enqueue_media' has already been invoked.
In the second invocation control is returned so the post information is not included,
which leads to the problem reported.

[bobbingwide]

Similarly, with EDD

0. bw_lazy_backtrace C:\apache\htdocs\wp-content\plugins\oik\bwtrace.inc:59 0
1. bw_backtrace C:\apache\htdocs\wp-includes\media.php:2660 0
2. wp_enqueue_media C:\apache\htdocs\wp-content\plugins\easy-digital-downloads\includes\scripts.php:188 0
3. edd_load_admin_scripts(post.php) C:\apache\htdocs\wp-content\plugins\easy-digital-downloads\includes\scripts.php:0 1
4. call_user_func_array(edd_load_admin_scripts,Array) C:\apache\htdocs\wp-includes\plugin.php:470 2
5. do_action(admin_enqueue_scripts,post.php) C:\apache\htdocs\wp-admin\admin-header.php:80 2
6. require_once(C:\apache\htdocs\wp-admin\admin-header.php) C:\apache\htdocs\wp-admin\edit-form-advanced.php:365 1
7. include(C:\apache\htdocs\wp-admin\edit-form-advanced.php) C:\apache\htdocs\wp-admin\post.php:211 1

then media_buttons calls it again

0. bw_lazy_backtrace C:\apache\htdocs\wp-content\plugins\oik\bwtrace.inc:59 0
1. bw_backtrace C:\apache\htdocs\wp-includes\media.php:2654 0
2. wp_enqueue_media(Array) C:\apache\htdocs\wp-admin\includes\media.php:523 1
3. media_buttons(content) C:\apache\htdocs\wp-admin\includes\media.php:0 1
4. call_user_func_array(media_buttons,Array) C:\apache\htdocs\wp-includes\plugin.php:470 2
5. do_action(media_buttons,content) C:\apache\htdocs\wp-includes\class-wp-editor.php:205 2
6. editor(,content,Array) C:\apache\htdocs\wp-includes\general-template.php:2284 3
7. wp_editor(,content,Array) C:\apache\htdocs\wp-admin\edit-form-advanced.php:497 3
8. include(C:\apache\htdocs\wp-admin\edit-form-advanced.php) C:\apache\htdocs\wp-admin\post.php:211 1

[bobbingwide]

What was surprising was that the problem only occurred when the post type did not support thumbnails. When 'thumbnail's are supported the first call to wp_enqueue_media() DOES pass the post ID

0. bw_lazy_backtrace C:\apache\htdocs\wp-content\plugins\oik\bwtrace.inc:59 0
1. bw_backtrace C:\apache\htdocs\wp-includes\media.php:2654 0
2. wp_enqueue_media(Array) C:\apache\htdocs\wp-admin\edit-form-advanced.php:38 1
3. include(C:\apache\htdocs\wp-admin\edit-form-advanced.php) C:\apache\htdocs\wp-admin\post.php:211 1
C:\apache\htdocs\wp-includes\media.php(2655:0) 2014-05-12T17:32:23+00:00 51 cf! 28 184 26735752/27056480 wp_enqueue_media(2) 1 Array
(
    [post] => 184
)

So the calls performed by EDD, WordPress-SEO and then 'media_buttons' are getting ignored.
This suggests to me that the problem is also associated with edit-form-advanced.php

[m_i_n]

I confirm the problem.
If a theme registers new post type (register_post_type()), and there is NO thumbnail in the supports parameter this happens: When you "Add media" in the editor and select "Uploaded to this post", there is a list of all attachments, which are not assigned to any post.

[ericlewis]

Cannot reproduce. Please share boilerplate and steps to reproduce, or screencast.

[m_i_n]

1. Upload some images to Media (but not from inside post, just directly in Media Library).
2. Activate theme which uses custom post type without thumbnails support.
3. Edit a post (custom post type) and click Add Media.
4. Select "uploaded to this post" - WordPress will display the images you've uploaded, which are in fact not uploaded to this post.

[ericlewis]

@min thanks for those steps, but I still can't reproduce.

1. Activated twentytwelve
2. Uploaded an image in wp-admin/media-new.php
3. Commented out twentytwelve/functions.php:75-76

   // add_theme_support( 'post-thumbnails' );
   // set_post_thumbnail_size( 624, 9999 ); // Unlimited height, soft crop
   

4. Added some custom post type boilerplate into an mu-plugin

   <?php
   
   add_action( 'init', 'codex_book_init' );
   /**
    * Register a book post type.
    *
    * @link http://codex.wordpress.org/Function_Reference/register_post_type
    */
   function codex_book_init() {
           $labels = array(
                   'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
                   'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
                   'menu_name'          => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
                   'name_admin_bar'     => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
                   'add_new'            => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
                   'add_new_item'       => __( 'Add New Book', 'your-plugin-textdomain' ),
                   'new_item'           => __( 'New Book', 'your-plugin-textdomain' ),
                   'edit_item'          => __( 'Edit Book', 'your-plugin-textdomain' ),
                   'view_item'          => __( 'View Book', 'your-plugin-textdomain' ),
                   'all_items'          => __( 'All Books', 'your-plugin-textdomain' ),
                   'search_items'       => __( 'Search Books', 'your-plugin-textdomain' ),
                   'parent_item_colon'  => __( 'Parent Books:', 'your-plugin-textdomain' ),
                   'not_found'          => __( 'No books found.', 'your-plugin-textdomain' ),
                   'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' ),
           );
   
           $args = array(
                   'labels'             => $labels,
                   'public'             => true,
                   'publicly_queryable' => true,
                   'show_ui'            => true,
                   'show_in_menu'       => true,
                   'query_var'          => true,
                   'rewrite'            => array( 'slug' => 'book' ),
                   'capability_type'    => 'post',
                   'has_archive'        => true,
                   'hierarchical'       => false,
                   'menu_position'      => null,
                   'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
           );
   
           register_post_type( 'book', $args );
   }
   

5. Created a new 'Book', open the media modal, and select the 'Uploaded to this Post' in the filter dropdown, see no media.

Please make sure you have no plugins enabled and are testing on a default theme, and if you see any errors in your Javascript console.

If you can still reproduce, a screencast documenting the process of creating the bug would be very helpful.

[m_i_n]

Your post type still have thumbnail in supports:

'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )

and the problem exists only if the post type doesn't support it.

Also, don't do your step 3 at all - it's not related.

[bobbingwide]

Hi, details for how to reproduce the problem are here:

​http://rowlandscastlewebdesign.co.uk/?p=1#more-1

You will see that I raised the problem with Easy Digital Downloads as

​https://easydigitaldownloads.com/support/topic/add-media-not-attaching-files-to-certain-cpts-wordpress-3-9/#post-235070

I suggested that the fix to EDD would appear to be to remove the call to wp_enqueue_media() in edd_load_admin_scripts().

When I first analysed / resolved the problem I discovered it when I deactivated EDD.
But I’d deactivated WordPress SEO first.
Had I performed the deactivations in a different order it would have been WordPress SEO that would have appeared to be at fault.

I originally believed that neither plugin needed to call wp_enqueue_media().

Now, with wp_enqueue_media() being called multiple times in WordPress, I feel that the problem could be resolved by moving the did_action() test to just before the invocation of the 'wp_enqueue_media' action.

BTW. I didn't get a response from Yoast.

[epohs]

In some cases the:

add_theme_support( 'post-thumbnails' );

code is needed, in addition to specifying 'thumbnail' support when you register the post type.

The issue also seems to affect drag-and-drop to reorder attachments on posts that have images that were successfully attached to posts (most likely the attachments were attached to these post prior to the 3.9 update).

[bobbingwide]

It would appear that the fix applied to WordPress SEO (v 1.5.3.3) was to include the post_id on the call to wp_enqueue_media().

I imagine it will work for Easy Digital Downloads as well.

Question: Should the codex be updated? Or is there still room for improvement to the core code?

[ericlewis]

Replying to m_i_n:

Your post type still have thumbnail in supports:

I removed 'thumbnail' from the 'supports' array, still cannot reproduce this bug.

Replying to bobbingwide:

I have traced this problem further. It would appear that the wp_enqueue_media() function is being called multiple times by WordPress SEO it first gets invoked by 'admin_enqueue_scripts' but the post information is not passed until 'media_buttons'

Replying to bobbingwide:

Similarly, with EDD

This sounds like a bug with those plugins, and not with core.

[m_i_n]

Replying to ericlewis:

I removed 'thumbnail' from the 'supports' array, still cannot reproduce this bug.

Did you rollback your step 3?

[husobj]

In the WordPress SEO plugin (and possible EDD) the issue seems to be that wp_enqueue_media() is called without passing a post ID when editing a post. See fix here:
​https://github.com/Yoast/wordpress-seo/commit/a7d52c2dc481c8099d2245ab1fdcfa45b6869753

From this point of view it would seem not to be an issue with core.

However, say wp_enqueue_media() is called multiple times when editing a post, by WordPress and potentially multiple plugins. If some of those called specify a post ID and some do not I'm not sure which would take precedence?

If wp_enqueue_media() is called multiple times one of which includes a post ID, should it forced to be enqueued with the Post ID?

[husobj]

It looks look wp_enqueue_media() is only allowed to be called once, so if a plugin calls it without the post ID parameter before WordPress calls it with the parameter, then the plugin would take precedence and not correctly setup up media for editing a post.

[momekh]

This may be related:

I used twentyfourteen's script as follows:

<p class="small byline">
  Parent Post (for this attachment):
  <span class="parent-post-link">
   <a href="<?php echo get_permalink( $post->post_parent ); ?>" rel="gallery">
	<?php echo get_the_title( $post->post_parent ); ?>
   </a>
  </span>
</p>

I have thumbnail support enabled.

Now, when I added the function in the theme, all previous gallery attachments are showing post->parent as 0 (linking back to the original attachment).

But when I add new post (post-format: gallery), and add a few images, the above code correctly links to the attachment parent.

Digging around, the two issues above may be inter-related???

I am on WP 4.0 btw.

[wonderboymusic]

if wp_enqueue_media() is called with no post ID, it will resolve to 0 - hence the unattached items. It was obviously being called by plugins that way, which was wrong.

There is nothing for core to do here.