Javascript changes in 3.3

Now that WordPress 3.3 is in feature freeze, it’s time to have a look at some new Javascript goodies for developers:

• jQuery 1.6.4 and jQuery UI 1.8.16. And that’s the full UI including widgets and effects. This will make it a lot easier and simpler for plugins using UI components that are not used in core as they will be able to just enqueue whatever they need.
  Note: there is a known bug/regression in UI Draggable since version 1.8.13. When connecting a draggable item to a sortable container, the HTML ID of the item is removed, #17952.
• WordPress Editor API. This is an updated API for both TinyMCE and Quicktags that outputs all parts of both editors in the same way as used on the Add / Edit Post screens, #17144. Plugins will be able to use the WordPress editor anywhere including the Visual/HTML tabs and the links to upload files and show the media library.
• Quicktags refactoring. This was necessary in order to make it fully multi-instance compatible, #16695.
  Note: if your plugin adds a Quicktags button please enhance it to use the new methods in quicktags.js.
• New multi-file uploader. Plupload was included as a result of  Google Summer of Code project, #18206. It’s more stable and has a lot more features as well as chooses the best available interface that the current browser supports: HTML 5, Silverlight or Flash.
  Note: two actions that were specific to SWFUpload were renamed and there is a new filter ‘plupload_init’ that gives access to all initialization options.
• Other enhancements: wp_enqueue_script() now works mid-page and prints the late enqueued scripts in the footer #9346, wp_localize_script() uses json_encode to properly escape and output all strings, #11520.

Freeze (just in time for fall!)

It’s that time in the dev cycle again: feature freeze. As usual, we are running a bit behind. We were supposed to have freeze a week ago for everything being worked on by contributors, then a week for the core team to do a scrub and commit or punt all those enhancement/feature request tickets as well as finishing up their own 3.3 feature dev before full on freeze today. We gave contributors some extra time at last week’s dev chat as there were some features not quite ready (HTML emails, Settings CSS, etc). Sadly, the extra time didn’t lead to commits, and now we’re just a week behind. So!

This is freeze.

1. All enhancements and feature requests that do not have a ready patch will be punted.
2. All enhancements and feature requests that have a patch but no comments showing that the patch has been adequately tested will be punted.
3. All enhancements and feature requests that have a patch that has been adequately tested will be reviewed by the core team and either committed or punted.
4. No more enhancements or feature requests will be added to the 3.3 milestone.
5. The core team will commit their remaining new features, and Jane + some UX volunteers will do some testing of UI changes over the coming week. Core team (and anyone who volunteers to help) will revise UI of new features based on findings during testing on a rolling basis.

Then comes beta, during which we’ll be in bug-fix-only mode. Yes, there is such a thing as a UI “bug,” but “we should have done this sooner” is not a bug.

This cycle has already seen two deadline pushes, so from now on we’re going to do our best to be mercilessly strict with the deadlines, even if it means cutting things. Anything that isn’t ready will be cut. “not done” is not the same as “has bugs,” and we need to be better about respecting that difference. We had plenty of time to get these things in; we all made decisions about priorities over the last few months.

It is now too late to ask us to get something in for 3.3. Start working on it for early 3.4.

Write a tutorial for setting up a local dev environment

A section of the core contributor handbook will be about how to set up a local test install, including a web server, Subversion, and WordPress. Because of the various operating systems and software packages out there, we’re going to need a few different tutorials.

I need some people willing to write up procedures for a number of standard setups. This includes:

• WordPress on XAMPP (both Windows and Mac) MAMP, and MacPorts
• TortoiseSVN and a tutorial on command-line Subversion usage, including co, up, revert, diff; patch; conflicts, etc.
• Whatever you Linux guys use

I’d also love an article on getting the test suite up and running. Anything I’m missing?

So, for these procedures, people can volunteer (probably for their current setup). Once steps are written, others will need to test them. Many procedures may heavily borrow from or link to outside resources (such as the vendor sites themselves) — this is fine. And, there may already be some good things in the Codex or on other sites about getting WordPress running. Again, fine. (There are SVN articles by both @westi and @markjaquith, and those are probably great to start from.) Gather links, screenshots, further reading, whatever will help.

So, who is in?

A Challenge!

I will bake (and send) brownies to the first person to solve (patches) the problem in Ticket #18561 in an awesome, non-hacky way that gets the thumbs up from the core team (leads+committers) and is committed to core, thus ending my teeth gnashing.