Image Post

What to watch for: Javascript and Editor changes in WordPress 3.3

Updated December 8.

There was an earlier post on JavaScript changes in 3.3, but a lot has changed, so here it is again (and updated).

If JavaScript or visual editing broke in your plugin, start here.

jQuery 1.7.1

This release had strong backwards compatibility over jQuery 1.6.1 (which was bundled in WordPress 3.2) but there is still a chance that plugin JavaScript has broken. We will always attempt to bundle the latest jQuery version with every major release of WordPress, so if you plan to use jQuery, you should follow that project as well.

jQuery UI 1.8.16

jQuery UI has been updated to the latest version, and all UI components are now included in core, 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. (For reference, WordPress 3.2 included part of 1.8.12.)

The wp_editor() API

Since the last post there have been some bug fixes for wp_editor(). 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. Plugins will be able to use the WordPress editor anywhere — including rendering the Visual/HTML tabs and the links to upload files and show the media library.

Example usage:

$content = 'The  content.';
$editor_id = 'foo';
$args = array(); // Optional arguments.
wp_editor( $content, $editor_id, $args );

Yeah, that’s it (though of course, you need to save it as well). Of note, there’s one pretty big gotcha: If you use wp_editor() to render the visual editor in a meta box, you risk problems. TinyMCE does not support being detached/moved in the DOM, which would occur when a meta box is dragged. (I’d look into the edit_form_advanced hook to render additional editors.)

For more, there’s a nascent Codex page on the API.

QuickTags

Since the previous post there have been a few improvements for Quicktags (the HTML editor toolbar), including better loading of the default buttons and “safe” close_all_tags() functionality. The major issue here is that we updated a JavaScript “API” that was almost as old as WordPress, so maintaining compatibility has been difficult.

Quicktags was refactored to make it fully multi-instance compatible (#16695). I think it still needs a Codex page, and I’ll ask @azaozz to post a tutorial here on how to use the new methods, and what before/after looks like in terms of converstion.

wp_localize_script() and wp_add_script_before()

When switching it to json_encode(), we opened up the possibility for encoding errors, so some changes were made to make this more backwards compatible. If you have previously used wp_localize_script() to pass arbitrary data (rather than localized strings), consider switching to wp_add_script_before().

Edit, December 8: wp_add_script_before() was removed.

Plupload

The old SWFUpload has been replaced with Plupload. Nothing here has really changed since the previous post, other than strings and the presentation of the drop zone.

wp_enqueue_script() now works mid-page

Yes: wp_enqueue_script(), called mid-page, will now enqueue the script into the footer. This isn’t new from the previous update.

Agenda for April 13 Dev Chat

• 3.2 check-in
• GSoC update

Sometimes not everyone is able to get to the dev chat due to time zones, work schedules, nap time, etc, so I think it would be useful to do a pre-meeting run-through of what we’ll cover. If any of these things apply to you (you’re working on it) and you won’t be at the dev chat, please leave a comment here before the meeting so we’ll know the status.

3.2 check-in

Freeze is 3 weeks from today, so if anyone has been putting off work on their assignments, now’s the time to get cracking. Quoting from Mark’s scope post for reference:

people stay on target and making sure we don’t try to slip “one more thing” in.

Just remember, if we stay on schedule (or better, get ahead of it), then the next release cycle will be here before you know it. No slipping things in.

List Tables API improvements (Westi and Koop) — finalize the API for third party use and more flexibility.
List Table XHR loading — to be investigated only after List Table API has stabilized. Make sure it’s worth it before we burn time on it.

@westi said last week that he needed to “sit down and summarise the changes I think we should make to make it more extensible and start on them.” Progress report?

PHP 5.2 (5.2.4, specifically) to be required. Drop compat. But don’t go adding a bunch of PHP5 stuff. This release is about dropping the old, not adding the new. More red than green.
MySQL 5 to be required. This quite literally involves no work beyond changing the requirements. Do not change queries.

@ryan: I think you were talking about starting on this before getting pulled onto some other stuff last week. Is this still something you’re handling?

IE6 EOL for the admin. If BrowseHappy is updated in time, we can consider adding a “use a real browser” nag for IE6 users. We probably can’t drop much CSS, as IE7 shares a lot of the issues. This is mostly symbolic, and reduces the platform combos we need to test. This also means any security issues that are shown to only affect IE6 only can be lowered in priority.

Who owns this?

Distraction Free Writing. This is our headline “ooh, shiny” user feature. Replace our current fullscreen implementation with something more beautiful, more useful (in terms of line-length and font size), and simpler (only limited RTE functionality). Look at WriteRoom, OmmWriter, http://www.quietwrite.com/ for inspiration. Koop is investigating this, and may crank out a quick plugin to jump-start development efforts.

@azaozz and @dkoopersmith were working on this, but I haven’t seen a plugin yet. Status?

Upgrade improvements. Changed-files-only upgrades can be done with zero changes to core. For the first effort, let’s just do updates to the latest point-point from within the same major version. So, 3.2 to 3.2.2 and 3.2.1 to 3.2.2. Optionally consider scanning for changed core files and offering them a full upgrade to overwrite those changed files. Skip the wp-contents directory when upgrading (no more upgrading the default theme or bundled plugins).

@dd32: Status?

Speed improvements. There are a bunch of little things we can do to make WordPress load or at least “feel” faster. Nacin is looking at PHP lazy loading. He also is working on a patch to make the admin menu load faster by doing the expansion in PHP.

Second one is in, first one is not, according to @nacin.

Speed improvements. We can make the dashboard faster by not doing async requests for panes if the cache is hot.

Who’s on this?

Speed improvements. Dion has some FTP improvements that should make upgrades a lot faster for people using a certain FTP server.

@dd32: update?

Speed improvements. Everyone can get involved here. Pick sometime small and manageable that will make WordPress a little faster. Together, they’ll add up to a bullet point in the release post.

Anyone working on any patches that fall under this category? Let’s get them on the list.

Not on the original post by Mark, but being actively pursued:

• Low-hanging XML-RPC tickets by @josephscott. Needed to go through them and identify likely candidates. Joseph: any update?
• TinyMCE update being added to trunk by @azaozz, autop also needs an update. @azaozz asked for help with writing tests for autop. @azaozz: any update?

GSoC

By the time of the dev chat, all mentors should have rated/commented on all the student applications and come up with their list of the projects/students they would be willing to mentor. If we have more selected projects than we are likely to have slots, we can discuss the potential projects to see how much community interest there is in each idea. Note that we would have this discussion about projects, not students.