Team update: Editorial

The first cycle finished yesterday. First run patch for supporting HTML in image captions is on #18311. Includes handling of the HTML in both editors and basic UI for inserting a link in the image properties tab in the gallery.

For the second cycle: testing, refining and committing HTML support for image captions, finishing up DFW support for editors not on the write screen, other editor enhancements and code improvements for example using the native MCE dialogs for our plugins instead of thickbox.

Team update: Tableteers

Cycle ending on February 22.
(George Stephanis and Zach Abernathy)

1. Admin Left Nav Menu Scroll Independently ( Enhancement )
The idea is for the Main Left Nav to scroll independently of the body, and metaboxes on the right to create the most usable interface for tablet users. This will create more of an “app” effect best for navigating and using the WordPress admin without the use of an actual app. It was decided not to go this way in #19994.

2. Clean Up Touch UI for Left NavMenu / Flyouts ( Bugfixes )
While the flyout is mostly usable in it’s current state, it is not as intuitive as it needs to be for the best user experience. They are ineffective at best on the Kindle Fire’s Silk Browser, but work pretty well on the iPad.  We need to examine all target devices to ensure interactivity is supported cross-device.

3. Possibly add support for dragging of meta boxes
In the desktop version of WordPress a user has the ability to move metaboxes around to customize their interface. However, touch-and-drag support is not as intuitive on a tablet. There are possible work-arounds that need to be explored. Alternately, there is the possibility of pre-determining the number of columns and not support drag-and-drop.

4. Dashboard and write screen columns (with @media)
Determining the number of columns that are present in landscape view versus portrait view. This would need to be tested on a per device basis to determine the optimum number of columns. In WP 3.3 this effect was generated via JS. We should be able to yield better performance by handling this via CSS.

5. Resolve Amazon Silk Browser ( Kindle Fire ) WYSIWYG Incompatibility
Currently, the WordPress WYSIWYG (TinyMCE) does not work in the Android Fire Silk Browser, but it does on the native Android browser. This is due to the Silk browser still not supporting the `contentEditable` attribute properly.

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.

To all that responded to the idea for CSS cleanup in 3.3: have your say at The big CSS overhaul in 3.3, part II.

jQuery updates in WordPress 3.2

There have been two major releases of the jQuery library during this release cycle. WordPress 3.1 includes jQuery 1.4.4. WordPress 3.2 will include  jQuery 1.6.1. The new jQuery is faster and better but also has some major changes. The two most important changes that all plugin and theme authors must test for are:

• Selectors that include [property=value] now require quotes. So

  $('input[name=submit]')

  will not work. It needs to be

  $('input[name="submit"]')

• All ‘selected’, ‘checked’ and ‘disabled’ properties should use the new .prop() method introduced in jQuery 1.6 instead of .attr(). In most cases .attr() will still work but for example

  .attr('checked', '')

  fails (that used to remove the checked=”checked” from checkboxes). More details and a list of all affected properties are on the jQuery’s blog.

Calling all CSS “Gurus”, well everybody that is interested in CSS to voice their opinions about The big CSS overhaul in 3.3.

The Distraction Free Writing mode has been in trunk since yesterday. Would appreciate comments, suggestions, opinions, etc. Bug reports should probably go on #17136.

To the Directors of White Space

Dear Sirs,

It has come to my attention that our White Space is running wild. Would it be possible to tame that beast back into submission please.

Seriously, I would like to propose adding another rule to the coding standards: when outputting HTML directly, leave all white space in PHP. Currently we do something like this:

if ( something ) {
    ?>
    <div id=...>some more</div>
    <div id=...>even more</div>
    <?php
}

That’s all nicely readable on the PHP side but the outputted HTML is surrounded by quite a bit of redundant space. What I’m proposing is to stop/start PHP immediately around the HTML:

if ( something ) {
    ?><div id=...>some more</div><?php
    ?><div id=...>even more</div><?php
}

This doesn’t impact the readability on the PHP side and produces “tight” HTML with no white spaces as it should be for production. In fact the HTML source would be “pseudo-minified”.

Of course the readability of the HTML source will be affected but not that much. Currently our HTML output is all over the place which makes it pretty hard to read. Considering that most people never look at the HTML source directly any more thanks to FIrebug and friends and all coding oriented text editors have a function to reformat HTML, I believe outputting “minified” HTML is an advantage. This also reduces the size of our output from 3% to 15% depending on the page.

Of course I’m not proposing for everybody to rush and reformat the whole codebase if this is accepted. But we can apply it to new code and clean up functions that are being patched for other reasons.

WordPress Developer News: WordPress 2.9 Beta 2

WordPress 2.9 is currently in beta and is expected to be ready in several weeks.

Major new features for developers:

• comments meta table
• improved support for custom post types
• register_theme_directory() for additional theme locations
• back-ported JSON encode/decode for both PHP and JavaScript

and for users:

• oEmbed support
• “Trash” for posts, pages and comments
• post thumbnails support
• basic image editor

More details are available in the Codex http://codex.wordpress.org/Version_2.9 and on trac.

New feature in the plugin repository: logged in users can enter compatibility information about all plugins – works / doesn’t work for several recent versions of WordPress. It is still in beta and in data collection mode. When it’s released, the collected information will be available from the wordpress.org API.

As with every release there are hundreds of improvements and bug fixes. 410 tickets have been closed so far for the 2.9 milestone.

One significant change is the new “trash” status for posts and comments. It works by changing the post_status or the comment_approved field to ‘trash’. If the post or the comment is restored from the trash that field is set back to it’s previous value. By default items in the trash are deleted after 30 days.

If you use direct SQL queries you may need to exclude posts and comments that are currently in the trash. Simple example: http://core.trac.wordpress.org/changeset/12254

Please ensure that your plugin(s) or theme(s) work as expected in WordPress 2.9-beta-2. If you have questions or comments please post them on the wp-hackers mailing list or in the Alpha/Beta forum on wordpress.org.

Agenda for the December 3rd Dev Chat

• How do we handle security releases in the admin – Matt Martz
• Create a post on the wp.org dev feed that highlights what breaks to plugin devs – Denis de Bernardy (we’ve started the WordPress Developer News email announcements as discussed here couple of months ago that cover this)
• Shall we remove Gears support now or in 3.0
• Minimum intervals between first beta and final release and between first RC and final – demetris