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 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.

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 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?

#3-5, #dev-notes

Post-3.5 IRC meeting

Here’s the agenda for the December 12 developer chat in IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on That’d be #wordpress-dev on freenode at 21:00 UTC. Should be a fairly low-key meeting:

  • Congratulations on WordPress 3.5, everyone.
  • Fallout of 3.5. How’s the support forums? Any common issues? What can we learn from plugins that broke?
  • Can we help with any common issues? Can documentation (like field guide posts) help?
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. 3.5.1 tickets. What does our timeline currently look like?
  • Discuss plans for the month of December, and 3.6.
  • Stare at the download counter.

Thank you so much for a great release. Really proud of what we accomplished. — @nacin, @koop

#3-5, #agenda

PHP Warning: Missing argument 2 for wpdb::prepare()

Hello pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party or theme author! You possibly found this post after searching the Internet for the error above: “PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher Warning: Missing argument 2 for wpdb::prepare().”

So, this is a new warning in 3.5. No sites are broken, everything is fine as before. But, this is indeed something you need to look at, because you may be exposing your users to a possible SQL injection vulnerability. Now that’s no fun!

First, if you’re a user and you want to get rid of these errors, you should turn off the displaying of errors in PHP. There are many ways to do this, such as in php.ini, .htaccess, etc. For this, you can just put this in wp-config.php. (Note that hiding errors on production sites is good practice anyway.)

@ini_set('display_errors', 0);

If you’re a user, you can stop here. (If you need more help, please don’t comment here, try the helpful Support Forums.) Just be sure to send a link to this post to the developer of the theme or plugin referenced in the error.

Now, developers: Here’s how $wpdb->prepare() is supposed to work:

$wpdb->prepare( "SELECT * FROM table WHERE ID = %d AND name = %s", $id, $name );

See how $id — an integer, presumably — was passed as the second argument? That corresponds to the first placeholder, %d. Then, $name (a string) was passed as the third argument, thus the second placeholder, %s. This makes sure your query is safe, and prevents something like little bobby tables. (Note: the comic is wrong, don’t sanitize — always prepare your queries.)

The problem is, a number of people were calling $wpdb->prepare() with only one argument, like so:

$wpdb->prepare( "SELECT COUNT(*) FROM table" );

See, there’s no parameter (%d, %s, or for floats, %f) in this query. This happens to work fine, but the prepare call isn’t doing anything. You should instead the query directly, as there are no inputs.

But here’s where the problem lies:

$wpdb->prepare( "SELECT * FROM table WHERE id = $id" );

See the problem? That query isn’t secure! You may think you are “preparing” this query, but you’re not — you’re passing $id directly into the query, unprepared. And this, right here, is why $wpdb->prepare() now issues a warning if it isn’t called with more than one argument. Because you can’t prepare a query without more than one argument. Here’s a correct example:

$wpdb->prepare( "SELECT * FROM table WHERE id = %d", $id );

This wasn’t a decision done lightly. We don’t like shoving PHP warnings into the faces of users and developers. But given the potential security risks, we wanted everyone to immediately look at how they are running queries. And, of course, always prepare them properly.

For more: wpdb Codex reference, #22262, and [22429].

#3-5, #dev-notes, #sql, #wpdb