Dev Chat Agenda for July 22

Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

During Beta Notes @iseulde would like to discuss headings and whether to convert on space or enter in #31441. Please download the latest nightly and test the feature before Dev Chat, so we can talk about it.

Time/Date: July 22 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – If @helen can make it
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Component Updates
  4. Open Floor

#4-3, #agenda

This week in 4.3: July 20 – 26

This is the jump-start post for the eleventh week of the WordPress 4.3 release cycle.

Beta4 will land on Wednesday. Our target until then is to get the ticket count in the 4.3 milestone down to 10.

Priority Tickets this week:

Core Meetings this week:

4.3 Feature Chats this week:

#4-3, #jump-starts

New Customizer Media Controls in 4.3 and 4.2

Over the past several releases, the Customizer API has drastically improved its built-in media controls, empowering developers to leverage the power of the WordPress media management experience in themes and plugins with ease. WordPress 4.1 refactored the image and upload controls to leverage the media modal for the first time (see #21483). 4.2 abstracted this functionality to a new base media control class. And now in WordPress 4.3, we’ve added a control for cropped images. In this post, I’ll outline the recent changes in Customizer media controls and explain the differences between the available controls.

WP_Customize_Media_Control

Before WordPress 4.2, all Customizer media controls saved the file url to their corresponding settings. While this facilitates quick access when using the value of the setting in themes and plugins, it makes it more difficult to access other information about that attachment, such as its title/caption, mime type, or in the case of images, accessing specific image sizes.

WP_Customize_Media_Control was introduced to allow this paradigm to change while maintaining backwards compatibility for the existing WP_Customize_Upload_Control and WP_Customize_Image_Control, which now extend the media control class (see #29215). The media control will save the attachment id for the selected media file to the Customizer setting, rather than the file URL. However, note that the default value of the setting must still be a URL, since a default attachment id doesn’t really make sense.

The media control can be used for any type of media, be it an image, audio, video, PDF document, or any other file format that your server supports. To restrict a media control instance to a particular type of content, use the mime_type parameter when adding the control:

$wp_customize->add_control( new WP_Customize_Media_Control( $wp_customize, 'audio_control', array(
	'label' => __( 'Media Control (audio)' ),
	'section' => 'media',
	'mime_type' => 'audio',
) ) );

When working with a setting corresponding with a media control, the sanitize_callback should generally be absint(), since a numerical id is expected. When using get_option() and get_theme_mod(), functions such as wp_get_attachment_url(), wp_get_attachment_image(), wp_get_attachment_image_src(), and even get_post() are useful depending on your needs, with each function taking the attachment id (value of the setting) as a parameter.

The full power of WP_Customize_Media_Control is realized when the control is extended to implement additional custom functionality in a custom child control. WP_Customize_Cropped_Image_Control is a great example of this in core. The core Customizer control classes provide several working examples of this; see wp-includes/class-wp-customize-control.php and wp-admin/js/customize-controls.js.

WP_Customize_Cropped_Image_Control

New in WordPress 4.3, WP_Customize_Cropped_Image_Control extracts functionality from the header image control to allow an image to be cropped to specific dimensions (see #29211). This offers a better user experience than automatic cropping in many cases when images of a certain size or aspect ratio are required in themes and plugins. In core, the new site icon feature relies heavily on the cropped-image control, implementing a child custom control to add additional site-icon-specific functionality.

The cropped image control comes with four custom parameters in addition to those available in the media control. These are used to specify the required (or recommended) image dimensions, as well as specifying whether alternative dimensions are allowed (the flex options). Here’s a typical usage when adding a cropped-image control:

$wp_customize->add_control( new WP_Customize_Cropped_Image_Control( $wp_customize, 'cropped_image', array(
	'section'     => 'background_image',
	'label'       => __( 'Croppable Image' ),
	'flex_width'  => true, // Allow any width, making the specified value recommended. False by default.
	'flex_height' => false, // Require the resulting image to be exactly as tall as the height attribute (default).
	'width'       => 1920,
	'height'      => 1080,
) ) );

The cropped-image control creates a child attachment of the original image attachment object for the cropped image, preserving the original version. The cropped-image attachment is given a context based on the control id (with _ replaced by -). The core control doesn’t currently use this, but it could be leveraged to query for previously-cropped images for a specific control to add a library feature in the future or in child controls. Be mindful that a version of the control id is stored in the database for cropped image attachments.

As with the media control, the cropped-image control saves the attachment id instead of the image URL. This can be useful for querying specific sizes of the image, but you’ll typically want the full size image at the cropped dimension. wp_get_attachment_image_src( absint( get_option( 'cropped_image_setting' ) ) ) should do the trick if that’s the case, when outputting the value of the setting.

#4-2, #4-3, #customize, #dev-notes, #media, #media-modal

Dev Chat Agenda for July 15

Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

During Beta Notes I’d like to discuss how the installation flow feels now with the new Passwords UI enabled. Please download the latest nightly and create a new install with it before Dev Chat, so we can talk about it.

Time/Date: July 15 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Component Updates
  4. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

#4-3, #agenda

This week in 4.3: July 13 – 19

This is the jump-start post for the tenth week of the WordPress 4.3 release cycle.

Beta3 will land on Wednesday. Our target until then is to get the ticket count in the 4.3 milestone down to 40.

Priority Tickets this week:

Core Meetings this week:

4.3 Feature Chats this week:

#4-3, #jump-starts

Editor changes in WordPress 4.3

The editor initialization was updated. The main change is that the content for both Visual and Text editors is prepared/escaped the same. We used to run the content through the PHP wpautop() when the default editor was TinyMCE. This is no longer needed as we run the textarea content through the JavaScript wpautop() before initializing TinyMCE.

In that terms wp_richedit_pre() and wp_htmledit_pre() were deprecated together with the richedit_pre and htmledit_pre filters. They were replaced by format_for_editor() and the format_for_editor filter. For more information see #32425.

Another change is the complete removal of the code for the old Distraction Free Writing mode. This code was disabled and has been unused since WordPress 4.1. We left it in core so the authors of plugins that were using it would have plenty of time to update.

If this is essential for some plugins, the files from WordPress 4.2 can be reused. For more information see #30949.

If you are the author of a plugin that uses any of the deprecated functions or filters, please update it now. If your plugin uses wp_editor(), please test it in the latest beta.

As always, feedback is very welcome.

#4-3, #dev-notes, #editor, #tinymce

Dev Chat Agenda for July 8

Here’s the agenda for tomorrow’s Dev Chat in the #core channel on Slack.

Time/Date: July 8 2015 20:00 UTC:

  1. Beta Notes
  2. Feature Updates
    1. Admin UI – @helen
    2. Menu Customizer – @westonruter
    3. Passwords – @markjaquith
    4. Site Icon – @obenland
  3. Feature Plugin Chat Next Week@samuelsidler
  4. Component Updates
  5. Open Floor

Feature Leads: Let’s review last weeks goals and set new ones for next week.

#4-3, #agenda

Comments are now turned off on pages by default

In [33041] and [33054] for #31168, we’ve turned comments off on new pages by default.

I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin, turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.

In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.

In trunk, you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status filter, which receives the status, post type, and comment type as arguments. If you’ve been directly checking options such as with get_option( 'default_comment_status' ), you will likely want to replace those calls with get_default_comment_status(). We recommend explicit registration of post type support for comments, but as an example of using the filter, you can restore current behavior using the following:

/**
 * Filter whether comments are open for a given post type.
 *
 * @param string $status       Default status for the given post type,
 *                             either 'open' or 'closed'.
 * @param string $post_type    Post type. Default is `post`.
 * @param string $comment_type Type of comment. Default is `comment`.
 * @return string (Maybe) filtered default status for the given post type.
 */
function wpdocs_open_comments_for_myposttype( $status, $post_type, $comment_type ) {
    if ( 'myposttype' !== $post_type ) {
        return $status;
    }

    // You could be more specific here for different comment types if desired
    return 'open';
}
add_filter( 'get_default_comment_status', 'wpdocs_open_comments_for_myposttype', 10, 3 );

#4-3, #comments, #dev-notes, #post-types

Singular.php: New Theme Template in WordPress 4.3

A new theme template has been added to the theme hierarchy as of r32846: singular.php.  This template follows the rules of is_singular and is used for a single post, irregardless of post type.  It comes in the hierarchy after single.php, page.php, and the variations of each. Themes that used the same code for both of those files (or included one in the other) can now simplify down to the one template.

#4-3, #dev-notes, #templates, #themes

This week in 4.3: July 6 – 12

This is the jump-start post for the ninth week of the WordPress 4.3 release cycle.

Beta2 will land on Wednesday. Our target until then is to get the ticket count in the 4.3 milestone down to 90.

Priority Tickets this week:

Core Meetings this week:

4.3 Feature Chats this week:

#4-3, #jump-starts