Attachment editing: now with full post edit UI!

While perhaps not often used, the same interface in the now-old upload/insert media modal was available as an admin screen by going to the Media Library and then clicking on Edit for an item. With the move away from that interface in the modal, we thought it’d be a good time to treat attachments as what they are: a post type. Some changes users will see are the ability to turn on discussion/comment meta boxes as well as being able to edit the slug for attached items; that is, items that have a post_parent.

Edit Media Screen in 3.5

What this means for developers is that you can now do familiar things like adding meta boxes or perhaps even utilize those fancy new edit screen hooks for editing media library items. There’s also the attachment_submitbox_misc_actions hook for the Publish meta box. Taxonomies will now come with their native meta box UIs if you so choose – for built-in taxonomies, it’s as easy as:

register_taxonomy_for_object_type( 'category', 'attachment' );

Seriously: that’s it. The screenshot above shows just that.

One thing you may notice is that what’s known as the “Description”, which in reality is the post_content, uses a textarea with quicktags enabled. The decision was made to go this route in core for a couple reasons: to keep it lightweight while still making it a bit better (after all, it was just a plain textarea before), and to prevent attachment-ception as a default possibility. If you as a developer want to enable attachments in your attachments, have at it.

attachment_fields_to_edit comes with backwards compatibility and will continue to work – fields added that way will appear below the Description field. However, you may very well find that it makes sense to change the placement of those fields on this screen for sensible editing and structure. There are JS methods for adding to the modal moving forward, but while those guides are worked on and you’ve got some already-existing things to support, the following will help you through.

Previously, you may have done something like checking the IFRAME_REQUEST constant to determine whether or not something should show on the attachment edit screen or in the Thickbox. Since the new media modal is not an iframe, that won’t work anymore. To help with that, we’ve added some new arguments, or flags if you will, to allow you to specify whether or not an added field should appear on this edit screen or in the new media modal: #22759.

This example shows how to add a field that appears in the modal but not in the edit screen. For the other way around, you would set show_in_modal to false. Both args default to true, and there’s no real reason to set both to false, so you’ll only use one or no flags for a given field.

add_filter( 'attachment_fields_to_edit', 'myprefix_attachment_fields_to_edit', 10, 2 );
function myprefix_attachment_fields_to_edit( $fields, $post ) {
        $fields['test-media-item'] = array(
                'label' => 'More Media Management',
                'input' => 'html',
                'html' => '<a href="#">Link One</a>
<a href="#">Link Two</a>',
                'show_in_edit' => false,

        return $fields;

For the low-down on how this came together over the course of 3.5, check out #21391. The possibilities are exciting! Document/asset management with taxonomies, adding that method for detaching or reassigning the post parent for a media item – what else might you come up with?

#3-5, #dev-notes