More hooks on the edit screen: edit_form_after_title and edit_form_after_editor

In 3.5, we’ve introduced two new hooks for the add/edit post screen: edit_form_after_title and edit_form_after_editor. Previously, there was the edit_form_advanced hook (or edit_page_form for pages), which appeared between the normal and advanced sections of metaboxes below the editor. Now you’ll be able to use edit_form_after_title and edit_form_after_editor, both of which are available even if the post type doesn’t support the title or editor.

While lots of things are appropriate in the various metabox areas, sometimes your customizations to the screen might need to go elsewhere. TinyMCE is a prime example, as it doesn’t like being moved in the DOM, such as in a draggable metabox. Core itself is now using edit_form_after_title on attachment editing to display the image and some fields for editing.

Example Code:

add_action( 'edit_form_after_title', 'myprefix_edit_form_after_title' );
function myprefix_edit_form_after_title() {
	echo '<h2>This is edit_form_after_title!</h2>';

add_action( 'edit_form_after_editor', 'myprefix_edit_form_after_editor' );
function myprefix_edit_form_after_editor() {
	echo '<h2>This is edit_form_after_editor!</h2>';

add_action( 'edit_form_advanced', 'myprefix_edit_form_advanced' );
function myprefix_edit_form_advanced() {
	echo '<h2>This is ye olde edit_form_advanced!</h2>';


Edit Form Hooks in 3.5

#3-5, #dev-notes

New Color Picker in WP 3.5

You may have noticed that WordPress 3.5 is sporting a new color picker. We originally developed it for the Custom Colors feature on We offered it to WordPress Core, and 4 months, eleventy million tests and iterations later, there’s a shiny new, HiDPI-ready, CSS gradient-based color picker called Iris in your WordPress. But how do you use it?

The easiest way possible is in the Customizer. Keep registering your color controls the same way you always have and they’ll now sport a slick new Iris-based color picker interface. Otto’s great Theme Customizer tutorial shows you how to register controls, including a color control, so I won’t repeat that information here.

Want to use the new color picker somewhere else? Here’s a quick guide:

1. Enqueue the ‘wp-color-picker’ script and style

add_action( 'admin_enqueue_scripts', 'mw_enqueue_color_picker' );
function mw_enqueue_color_picker( $hook_suffix ) {
	// first check that $hook_suffix is appropriate for your admin page
	wp_enqueue_style( 'wp-color-picker' );
	wp_enqueue_script( 'my-script-handle', plugins_url('my-script.js', __FILE__ ), array( 'wp-color-picker' ), false, true );

My plugin now has a my-script.js file that has declared wp-color-picker as a dependency. We can now use the wpColorPicker jQuery method inside it.

2. Add an input to your admin page

I’m not going to tell you how to code an admin page. Somewhere on it, you’ll want:

<input type="text" value="#bada55" class="my-color-field" />

You can also prime a default color for the field if you want:

<input type="text" value="#bada55" class="my-color-field" data-default-color="#effeff" />

3. Call ‘wpColorPicker’ from your script

Remember that we enqueued my-script.js above? Open it up, and be prepared for some long coding:


What, you wanted more? There’s a lot more you can do, but that will get the job done for most cases. (Note that only IE8 and up are supported. IE7 and under will fail gracefully, leaving you with a perfectly usable text input.)

4. Advanced usage

wpColorPicker supports a few options. You can supply an options object when calling it:

var myOptions = {
	// you can declare a default color here,
	// or in the data-default-color attribute on the input
	defaultColor: false,
	// a callback to fire whenever the color changes to a valid color
	change: function(event, ui){},
	// a callback to fire when the input is emptied or an invalid color
	clear: function() {},
	// hide the color picker controls on load
	hide: true,
	// show a group of common colors beneath the square
	// or, supply an array of colors to customize further
	palettes: true


5. More advanced usage

wpColorPicker is set of UI controls wrapped around the underlying Iris color picker. We did things this way so that, if a better color picker comes along, we can more easily swap it out. But, if you want to just play with Iris itself, just declare iris as your script dependency instead. I’m not going to document the options here, but Iris’s GitHub repo should see some actual docs in the future.

#3-5, #dev-notes

The short road to 3.5

Good dev chat today. The plan is for RC1 tonight (more on that in a moment). Here’s the current assignments for who is working on what, based on the main 3.5 report. Feel free to help with testing and patching across the board.

  • A number of IE7/8/9 issues with media, of varying severity. A number of people are working on this, and more are welcome. The focus is currently IE9 and IE8. Until those are fully working, IE7 should be untouched, as we may just severely degrade the media UI in IE7. #22446
  • Mark Jaquith is working on the SimplePie/DOMDocument/kses ticket. #21990
  • Dion was to work on the get_home_path() ticket, which is now fixed. #20449
  • The general IE audit for 3.5 was done with one more commit. #22467
  • The about page and feature pointers need an initial commit. #22455, #22454
  • The help text changes need a final review and commit. #22451
  • The WP_Image_Editor architecture ticket is still an ongoing conversation between scribu, Marko, and Mike Schroeder. #22356
  • Dominik (ocean90) has a patch ready to close out the attachment post type UI ticket. #21391
  • Koop is working on the media upload tickets. #22243, #22480

Ongoing things:

  • The Tumblr Importer needs beta testers! It now uses their OAuth API, which requires you to create a (simple) app. Link to the beta version. #22422
  • Want to test WordPress 3.5? Consider testing the more interesting scenarios: mobile devices, desktop browsers (IE!), right-to-left languages.

Lower priority tickets:

  • westi is working on the _wp_translate_postdata() ticket. #22417
  • The media tickets here will be worked on over the next few days. #22524, #22282, #22494, #22532#22512, #22517
  • The child theme installation bug is now fixed in trunk. There is a patch with some additional error handling. #22515

Decisions reached:

  • Twenty Ten will not be shipped with fresh downloads of WordPress 3.5. It will still be supported (and still reside in core SVN) and will continue to receive updates through the themes directory. #22500

Schedule from here on out:

  • Release Candidate 1 today, once we have no more tickets of major severity open.
  • Eat turkey tomorrow. I won’t be opening my computer tomorrow. If you’re with family, you shouldn’t either.
  • Release Candidate 2 on Monday. At this point, report/6 should ideally be empty (no tickets). is also planning to merge 3.5 on Monday, which should significantly increase our test coverage (and bug reports) for media come next week.
  • Release Candidate 3 (assuming there are major bugs fixed after 2) no later than Monday, December 3.
  • Which sets us up for a December 5 release, assuming we don’t reach a critical mass of critical issues next week.

[IRC logs]


Countdown to 3.5 Beta 1

As I covered at the end of the dev chat yesterday (logs), we’re planning for 3.5 Beta 1 next week. This gives us a week to land a lot of things.

I’ve updated the teams and tasks page. Everything is moving along nicely! Solid pace everywhere. There’s also a UI-specific progress report from @lessbloat on make/ui.

Ship early, ship often. This is expected to be a very rough cut beta. I called it “scrappy,” and not in the pugnacious way. After that, the plan is for a new beta every week. By beta 3 or so, major features should be pretty well shored up.

Some background on this: As I mentioned during the chat, I really want to make sure we have strong pre-release participation. After studying the last five release cycles, I noticed that earlier and less stable betas can encourage this. When we ship more polished betas, it seems people pick up on that, and it feels like less testing occurs. Additionally, we’ve sometimes gone a month or more between the first and second beta. Rather than slowing down, beta should be the time we speed up!

So, by week 6 or so, we should be ready to transition out of bug-fix mode and into RC mode. I’m excited! Who’s with me?


Timeline for Twenty Twelve 1.0 — final testing window

During the dev chat yesterday (logs), it was determined that the timeline for Twenty Twelve’s release to the theme directory will be next week.

That means if you have any bugs to report against Twenty Twelve, please do so now! It’s time for final reviews. Once 1.0 is released, it will be very tough for us to make style or code changes, as we will then need to avoid breaking child themes (both code wise, and stylistically).

So, if you haven’t looked at Twenty Twelve yet, now’s the time. Here’s the demo site: Also, if you’re using the Beta Tester plugin instead of a checkout from Subversion, you may not have Twenty Twelve installed and up to date. In that case, here’s a direct link to download a ZIP.

(@westi, @dd32, we should adjust how beta theme installs are handled…)

#3-5, #bundled-theme, #dev-chat, #twentytwelve

Suggest agenda items for September 5 chat

Please suggest agenda items for today’s chat. We will be going over every 3.5 project and task today, to decide if our time and energy is best allocated across what remains on the table.

#3-5, #agenda

External Libraries in 3.5

We work hard to keep our external libraries as up-to-date as possible with each major release. Here’s what you can find today in trunk, all of which are the latest version:

Edit: jQuery 1.8.1 (due out this week) and jQuery UI 1.9 (due out next week) are now both in trunk.

And, Backbone.js 0.9.2 and Underscore.js 1.3.3 were both added to core last week.

If you’re a plugin developer using a bundled library, we strongly suggest you follow their development as well, to ensure code you write will be compatible in the future. The projects we have adopted have very similar backwards compatibility policies as ours (which would be strive to always be compatible), which make this pretty easy to do.

Additionally, Prototype and have been removed from core. They are still registered; enqueueing them will pull from This is only being done for backwards compatibility and doesn’t indicate a change in policy. It was just a lot of bloat to keep shipping when core hasn’t used either for four years. (Both were updated to the latest versions in the process, something we can/may continue to do.)

See also the conversion to .min.js from .dev.js.

#3-5, #javascript

Minified versus development scripts and .min.js

For some time (since r10291), WordPress has shipped minified scripts and styles as .js and .css, with the non-minified, “development” versions at .dev.js and .dev.css.

These weren’t great for discoverability and it has become clear that these are non-standard. So, we’ve moved to using .min.js and .min.css for minified files. You can now find the “development” versions at .js and .css. This also works nicely with tools like ack, which are coded to ignore .min.js.

This was implemented in #21633. Now if only we can get TinyMCE to move away from _src.js. 🙂

A note, for some external libraries, we don’t include the un-minified versions. In this case, you can find them on their respective websites and also in the sources repository. (This is linked from, which in turn is referenced at the bottom of our license file.) @scribu and I were talking about writing a developer plugin to use un-minified versions of these libraries, which would be cool.

More on external libraries in 3.5 here.

#3-5, #javascript

Agenda for August 1 project meeting * 3.4.2…

Agenda for August 1 project meeting:

  • 3.4.2 — review the ticket queue. Quick triage.
  • WordCamp SF — Dev Day is this Sunday. If @beaulebens is around, he can share his plans.
  • Retina tasks — status check. Hope to have a discussion on what our goals are: retina admin, versus retina uploads. I think uploads (images, custom headers) are a more complicated issue that may be a better plugin for now. Or, at the very least, we need some proposals on how we may solve and implement this. #16461 #21388 #21389 #21038 #21019
  • Need some people to step up, study, and present some thoughts/solutions on a number of tickets, including:
    • #21391 — possibly using a standard post type UI for attachments, which could result in some CPT API improvements
    • #16379 — better UI for page on front. Can someone try out implementing the ideas here?
  • General status checks on other tasks in progress, such as ImageMagick support, welcome/NUX improvements, Twenty Twelve, removing Links

#3-5, #agenda

A collection of tickets for 3.5 that need…

A collection of tickets for 3.5 that need contributors!

Retina and UI

  • #21019, Retina everything
  • #16461, CSS3 gradients for buttons and other graphical elements
  • #21388, retina theme screenshots
  • #21389, retina custom headers


  • #21390, media catch all ticket
  • #21391, converting the attachment UI to a proper post type UI
  • #6821, ImageMagick handling
  • #13461, preserving transparency when creating thumbnails
  • #21038, retina images?

Multisite (and media)

  • #19235, turning off ms-files.php by default

Twenty Twelve




Links, the removal of

  • #21307, remove it
  • Look through all existing Links tickets

(more to follow)