Impromptu 3.5.1 meeting in 30 minutes 19:00 UTC…

Impromptu 3.5.1 meeting in 30 minutes (19:00 UTC) in #wordpress-dev. Still upwards of 16 tickets to lock down. Would like to hit 3.5.1 beta by the end of the week.


For Wednesday, let’s plan on a 3.5.1 ticket triage meeting

For Wednesday, let’s plan on a 3.5.1 ticket triage meeting at 19:00 UTC (2 p.m. Eastern). Please be around if you can (#wordpress-dev of course), especially if you have something in progress for 3.5.1, so we can hammer things out and start thinking about timing.

The dev chat is normally two hours later, at 2100 UTC. I won’t be available, and will leave that to @markjaquith and co. I expect it will be a light meeting again. 3.5.1 timing should be discussed, which should be easier with the triage session happening earlier.

#3-5, #agenda

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

Post-3.5 IRC meeting

Here’s the agenda for the December 12 developer chat in IRC. 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?
  • Triage 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 plugin or theme author! You possibly found this post after searching the Internet for the error above: “PHP 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

WordPress 3.5 admin columns for custom taxonomies

WordPress 3.5 is here!! If you haven’t played with it yet, go get it!
I’m proud to be listed as a contributor on this release and want to highlight a new feature geared towards developers that I helped work on. If you have checked the register_taxonomy() codex page recently, you may have noticed a new optional argument, ‘show_admin_column.’

From the codex:

(boolean) (optional) Whether to allow automatic creation of taxonomy columns on associated post-types.
Default: false

As stated, this new argument allows easy registration of taxonomy columns on post (and custom post type) list table screens much like the default tags’ and categories’ columns.

'show_admin_column' in action

This should make plugin and theme developers happy as they’ll no longer need to build these columns manually.

The new argument in action:

// hook into the init action and call create_activity_taxonomies when it fires
add_action( 'init', 'create_activity_taxonomies' );

// create taxonomy, "fitness-type" for the post type "activity"
function create_activity_taxonomies() {
	// Add new taxonomy, make it hierarchical (like categories)
	$labels = array(
		'name' => _x( 'Fitness Types', 'taxonomy general name' ),
		'singular_name' => _x( 'Fitness Type', 'taxonomy singular name' ),
		'search_items' => __( 'Search Fitness Types' ),
		'all_items' => __( 'All Fitness Types' ),
		'parent_item' => __( 'Parent Fitness Type' ),
		'parent_item_colon' => __( 'Parent Fitness Type:' ),
		'edit_item' => __( 'Edit Fitness Type' ),
		'update_item' => __( 'Update Fitness Type' ),
		'add_new_item' => __( 'Add New Fitness Type' ),
		'new_item_name' => __( 'New Fitness Type Name' ),
		'menu_name' => __( 'Fitness Type' ),

	register_taxonomy( 'fitness-type', array( 'activity' ), array(
		'hierarchical' => true,
		'labels' => $labels,
		'show_ui' => true,
		'show_admin_column' => true,
		'query_var' => true,
		'rewrite' => array( 'slug' => 'fitness-type' ),
	) );

Another key addition is the “manage_taxonomies_for_{$post_type}_columns” filter. This allows developers to add a taxonomy column to a post type outside of the register_taxonomy() function:


add_filter( 'manage_taxonomies_for_activity_columns', 'activity_type_columns' );
function activity_type_columns( $taxonomies ) {
	$taxonomies[] = 'activity-type';
	return $taxonomies;

#3-5, #admin-columns, #dev-notes, #register_taxonomy, #taxonomy

WordPress 3.5 RC6 is out Please if you…

WordPress 3.5 RC6 is out. Please, if you can (and earlier the better), hammer on TinyMCE with the most ridiculous object and embed tags you can find, and anything HTML5. (Here’s a zip for the nightly build.)

What’s important in RC6? After a good first attempt last week (#22790), we took another stab (#22842) at fixing TinyMCE’s handling of, well, ridiculous object and embed tags. Our goal right now is to ensure that nothing breaks in 3.5 that worked in 3.4.2. So, go find your best embed spaghetti* and make sure nothing breaks.**

  • Very easy to test: Go to the “Text “tab, paste something in, head to the Visual tab, confirm things don’t look broken, head back to the “Text” tab, see if it looks mangled, head back to Visual, confirm things don’t look broken. Remember, we are looking for regressions, so also check 3.4.2 to see if it occurs there.

** Breaks means the embed disappears in whole or part, or there’s a JavaScript error, or your computer starts smoking. Whitespace and other HTML changes do/will happen (contents may settle during shipping). Of course, your content should never be damaged, as that’s just no fun.

What happened to the last two RCs? We generally try to do a “soft” or “silent” RC at the very end of a cycle. We’re confident we’ve gotten the testing it needs, but we’d like to enter a 24-hour period where there are no more changes to trunk. Having a cleaner version number provides for a good line in the sand, and can help in case some blocker bug report comes in. Of course this time, we’ve stuttered a few times. TinyMCE hell was RC4. A few final changes on Friday (after we decided to not release) resulted in RC5. And the second round of TinyMCE hell is RC6.

This also means our new target is Tuesday, December 11. We’ll again convene at 10 a.m. Eastern to see if the winds are blowing in our direction. (Even NASA needs good weather.)

And hey, on the bright side:

#3-5, #tinymce

The new target for WordPress 3.5’s release is…

The new target for WordPress 3.5’s release is Monday, December 10, at 11 a.m. Eastern time.

I badly wanted to release today, just as I did yesterday, and the day before. I want this thing kicked out to the curb as much as you want it running on your sites. But the entire core team is exhausted, and we’ve made too many changes this week on too little sleep to risk dropping 3.5 without an adequate code freeze and a few days of quiet. #22803 was downright frightening to see, while #22790 was just absurd on a number of levels. I wanted to go to bed at 11 p.m. last night and instead four of us worked until 7 a.m. The responsible voice in my head says without a doubt, that code needs to soak longer (and should probably sit in a corner with a dunce hat on).

Plus, let’s face it, it’s late Friday afternoon on the east coast of the United States. I don’t want to do that to support teams, hosting companies, or translators. In the end, the extra few days can only help.

So: we’re going to branch 3.5 now. I’m currently aiming for a code freeze that lasts 65 hours and fifty-five minutes in length. We will reconvene on Monday at 10 AM Eastern time (1500 UTC) and start working our way through the release checklist.

Tomorrow evening, a few of us will touch base to see if anything has come up we need to deal with. By Sunday morning, we will know whether anything needs to change. Until then, we rest. I know, it’s lame we’re not shipping 3.5 yet. But a few more days will be forgotten sooner than potential egg on our face if we ship it without clear heads.

In the meantime: Go update your profile with your full name so it can make it on the credits page. And enjoy the weekend!

I’ll leave you with this:


WP_Image_Editor is incoming!

In WordPress 3.5, GD has been abstracted out of core’s image manipulation functions.
What does that mean for you, you ask?

What’s cool?

  • We add support for Imagick by default, giving better image quality to those who have it available on their host. This is particularly important if you’re using images with extended color profiles, since GD discards them outright.
    • Imagick support requires Imagick 2.2.0+ compiled against Imagemagick 6.2.9+, for full support. If the required functions aren’t available, WordPress will default back to GD.
  • You can create your own image manipulation engine, or extend ours in plugins to easily add additional functionality to WordPress.

Watch out for:

Any function or filter that receives or returns a GD Image Resource should be avoided if possible, since 3.5 represents core’s move away from GD’s direct use.

Deprecated Filters

Several filters have been deprecated, and will no longer function as they did previously. This includes any filter that expected to receive a GD Image Resource, as we can’t pass a GD Image Resource to it if another backend is being used. Instead, new filters are introduced that expect a WP_Image_Editor object.

It’s worth noting that if you’re using these filters, your plugin shouldn’t create a fatal error – it just won’t modify core’s functionality like it used to, and will fail silently.

Deprecated Filters

  • image_save_pre is now image_editor_save_pre
  • wp_save_image_file is now wp_save_image_editor_file
  • image_edit_before_change is now wp_image_editor_before_change

While jpeg_quality is backward compatible in 3.5, if you want to change compression quality globally, you should use wp_editor_set_quality in the future, since it applies to other editors and formats that support quality setting as well (like PNG with Imagick). To change the quality on a single image you’re editing, see WP_Image_Editor::set_quality().

New Filters

  • wp_image_editors – modify array to re-order or add additional editor/engine classes.
  • image_editor_default_mime_type – string; set default mime-type for WP_Image_Editor.

Deprecated Functions

  • wp_load_image() – use wp_get_image_editor() to load files instead.
  • image_resize() – use WP_Image_Editor::resize()
  • gd_edit_image_support() – use wp_image_editor_supports()

Need to Deprecate

There isn’t yet an alternative for load_image_to_edit(). This is because there is work towards creating an image container for a future version of WordPress. In the meantime, while decidedly not ideal, I’d suggest doing what core does: wp_get_image_editor( _load_image_to_edit_path( $post_id ) );

How do I use it?

A complete tutorial on the use of WP_Image_Editor is forthcoming, but this should get you started:

$image = wp_get_image_editor( 'cool_image.jpg' );
if ( ! is_wp_error( $image ) ) {
	$image->rotate( 90 );
	$image->resize( 300, 300, true );
	$image->save( 'new_image.jpg' );

You can see full class documentation by taking a look at:

Known issue

#22663 – Non-Square Rotates (non 90*x), followed by a crop, can cause improper results.

#3-5, #dev-notes

All hands on deck Within the next few…

All hands on deck! Within the next few hours, we need to get to basically zero tickets.

Some of these patches will have a bit of a learning curve, but you can help with testing! And are there a lot of things to test — a near constant stream of patches. We will be in #wordpress-dev for the rest of the day.

We are hoping to do a soft RC4 early evening (so, five or six hours), which still means we can release tomorrow if the stars align. Cross your fingers. Actually, if you can help while crossing your fingers, you can improve the success rate of your own finger-crossing! Woo.