While perhaps not often used, the same interface in the now-old upload/insert media modal was available as an adminadmin (and super 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 metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes as well as being able to edit the slug for attached items; that is, items that have a post_parent.

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., 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?