What’s New in Gutenberg? (May 22nd)

We’ll start making weekly posts here in the name of making the ongoing editor updates more visible outside of the Slack channel and the GitHub development stream. At the moment there are 13 blocks implemented in the project, and a few more being worked on by the team and contributors.


In Progress

We welcome all your feedback and contributions on the project repository, or ping us in #core-editor.

#core-editor, #editor, #gutenberg

Enhanced Settings API: Where we’re at

As outlined in a recent post on the accessibility team blog, enhancing the Settings API is currently a high priority for the team. We have been working on this project for a couple months now, discussing goals and approach in a biweekly meeting on Mondays at 16:00 UTC. The main objectives have been to improve accessibility of the pages generated with the Settings API as well as making it easier to use and more flexible for developers. Over the time we have identified the following list of areas to work on:

  • The HTML table layout that has been present for most admin pages should be replaced with a modern, semantically more accurate markup. As the entire table markup is created by the Settings API, we should be able to change it without major backward-compatibility concerns.
  • We’d like to investigate moving from the current two-column layout to a one-column layout, as we agreed on that it would provide a more streamlined experience and overview. Furthermore the two-column layout makes it hard if not impossible to use fieldset (and legend) to group elements properly.
  • For common fields used in Core and plugins, such as a simple text field, textarea, dropdown, radio or checkbox, default callbacks should be provided so that developers do not need to write every callback for such simple UI components themselves. These callbacks should be flexible and accept a standardized set of arguments that can be passed to add_settings_field(). Furthermore each callback should provide accessible markup out-of-the-box, so that even plugin settings pages can be made accessible easily.
  • Eventually all settings pages that Core creates should be using the enhanced Settings API instead of rendering their markup manually. This ensures a more structured output and allows developers to modify the Core fields as well.
  • It should be a high priority to create a set of standardized patterns for class names, markup and design. Elements that need to be targeted in JavaScript must have classes used explicitly for that purpose only.
  • All markup we create should be generalized enough to not be specific to only the Settings API pages. Several other pages in the admin, for example the user profile or term editing pages could benefit from the improvements as well once they are polished.

This list may possibly be extended at some point, as there were some discussions about further developer-centric improvements, but for now we would like to focus on producing a clean and accessible markup with a better DUX being a side product of these efforts.

Prototype for WCEU

After starting development through patches on #39441, we soon realized that this project would be better off as a separate plugin. Therefore we created a GitHub repository for the project, where all development happens now. The plugin uses prefixed functions to not interfere with Core’s own Settings API, so it can safely be tested. While working on the layout, we identified the need for thorough user tests of the changes, and we set the upcoming WordCamp Europe as our target to get a first testable version of the plugin ready. While we still need more time to get to the point where we can propose it as an actual feature plugin, we would like to get feedback sooner than later to uncover eventual pain points.

We will be starting next week to discuss what needs to happen to get that prototype finished in time. If you’re interested, please attend the meeting, which will take place on Monday 16:00 UTC on Slack in the #core channel, or leave a comment on this post if you cannot make it.

cc @afercia, @rianrietveld, @joedolson, @karmatosed, @johnbillion@sc0ttkclark

#accessibility, #settings

JavaScript Chat Agenda for May 23rd

Please join us for our weekly JavaScript Chat on May 23, 2017 at 13:00 UTC, where we will discuss:

  • Introducing a module pattern for WordPress JavaScript, see #40834.
  • A framework for future WordPress JavaScript. What are the goals and criteria for making a decision, and what do we hope to get out of it? To specific frameworks, which options are we considering, and who can share their experiences in implementing them in the context of WordPress? Finally, how do we make decisions about ongoing development and maintenance of existing Backbone-based features? Note: this discussion item may take more than one meeting.
  • Open floor

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #javascript

Multisite Focused Changes in 4.8

Here’s an overview of the developer facing changes made in multisite for the 4.8 cycle. If you’re interested in more detail, checkout the full list of tickets.

New capabilities

As part of the goal to remove all calls to is_super_admin() in favor of capability checks, two new meta capabilities have been introduced in this release:

  • upgrade_network is used to determine whether a user can access the Network Upgrade page in the network admin. Related to this, the capability is also checked to determine whether to show the notice that a network upgrade is required. The capability is not mapped, so it is only granted to network administrators. See #39205 for background discussion.
  • setup_network is used to determine whether a user can setup multisite, i.e. access the Network Setup page. Before setting up a multisite, the capability is mapped to the manage_options capability, so that it is granted to administrators. Once multisite is setup, it is mapped to manage_network_options, so that it is granted to network administrators. See #39206 for background discussion.

Both capabilities work in a backward-compatible fashion, so no changes should be required in plugins that deal with those areas. The capabilities however allow more fine-grained control about access to their specific areas. As an additional reminder: Usage of is_super_admin(), while not throwing a notice, is discouraged. If you need to check whether a network administrator has access to specific functionality in your plugin, use one of the existing network capabilities or a custom capability. See #37616 for the ongoing task.

New Hooks

  • deleted_blog fires after a site has been deleted. See #25584
  • signup_site_meta filters site meta in wpmu_signup_blog(). See #39223
  • signup_user_meta filters user meta in wpmu_signup_user(). See #39223
  • minimum_site_name_length filters the minimum number of characters that can be used for new site signups. See #39676

Network-specific site and user count control

With WordPress 4.8, several functions related to network site and user counts now support an additional $network_id parameter that allows to read and update those counts on a different network than the current one. While this mostly increases general flexibility, the new parameter can be leveraged to fix inconsistencies, for example prior to 4.8 the creation of a new site on another network would falsely trigger a recalculation of the current network instead of the network being actually modified. See #38699 for the bug ticket and resulting task.

The functions that now support a $network_id parameter are:

  • get_blog_count(). See #37865.
  • get_user_count(). See #37866.
  • wp_update_network_site_counts(). See #37528.
  • wp_update_network_user_counts(). See #40349.
  • wp_update_network_counts(). See #40386.
  • wp_maybe_update_network_site_counts(). See #40384.
  • wp_maybe_update_network_user_counts(). See #40385.
  • wp_is_large_network(). The filter wp_is_large_network now passes the network ID as fourth parameter as well. See #40489.

#4-8, #dev-notes, #multisite

Removal of core embedding support for WMV and WMA file formats

With the introduction of the video widget (#39994) and audio widget (#39995) it was discovered that the WMV and WMA file formats are no longer supported by MediaElement.js as of v3. While core is currently shipping with MediaElement.js v2.22, these file formats only play if the Silverlight plugin is installed, something which is less and less common since the plugin is no longer supported as of Chrome 45 and as of Firefox 52. So with the planned upgrade of MediaElement.js from 2.22 to 4.x (see #39686), it is a good time with the WP 4.8 major release to remove support for the formats. This has been done in [40813] for #40819.

Plugins may continue to add embedding support for these file formats by re-adding them via the wp_video_extensions and wp_audio_extensions filters, for example:

function add_wmv_to_wp_video_extensions( $extensions ) {
    $extensions[] = 'wmv';
    return $extensions;
}
add_filter( 'wp_video_extensions', 'add_wmv_to_wp_video_extensions' );

function add_wma_to_wp_audio_extensions( $extensions ) {
    $extensions[] = 'wma';
    return $extensions;
}
add_filter( 'wp_audio_extensions', 'add_wma_to_wp_audio_extensions' );

Plugins would also need to implement fallback rendering routines via the wp_video_shortcode_override and wp_audio_shortcode_override filters, or else use a different library than MediaElement.js altogether via the wp_video_shortcode_library and wp_audio_shortcode_library filters.

Note that there is no functional difference before and after the removal of WMA and WMV support. When MediaElement.js doesn’t support a format, it displays a download link. Before and after [40813], the following is ho  the audio and video shortcodes look like with WMA and WMV files respectively:

In the admin, the functional difference is that these formats are not listed as being available for selection in the Video and Audio widgets. Additionally, when you Add Media in the post editor, there is now no option to embed the player for these formats; only a link to the media will be provided, just as when attempting to add non-media files to content.

#4-8, #core-media, #dev-notes, #mediaelement

Preferred Languages: The Prototype

A bit over six months ago I set the foundation for the Preferred Languages feature project. After highlighting the problems many WordPress users around the world are facing, some time was spent on researching popular platforms and other systems to see how they handle the issue of setting multiple preferred languages. However, this didn’t really help to move one step forward and the project became dormant — until now.

Personally, I’ve been experiencing the same problems with so-called language fallbacks over and over again. During WordCamp Bilbao I decided to revive the Preferred Languages project. In order to do this I used the previously mentioned GitHub repository to build a super-simple proof-of-concept plugin to have a new basis for discussion. As originally envisioned, this repository can be used as a playground for discussions, prototypes, and eventually a working solution.

This new plugin lets you select multiple preferred languages in your settings. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list.

A sneak peek of an early version quickly made the rounds on Twitter:

After some very positive feedback I worked a bit more on it and wanted to share the latest version here with a larger group of people. Here’s what it currently looks like on both the settings screen and when editing your profile:

Without much further ado, please check out the plugin on GitHub, test it on your local WordPress site, and leave some feedback!

#feature-projects, #i18n, #preferred-languages

Editor API changes in 4.8

A new editor API was added in #35760. It makes it possible to dynamically instantiate the editor from JS. There are two parts to it:

  • All editor related scripts and stylesheets have to be enqueued from PHP by using wp_enqueue_editor().
  • Initialization is left for the script that is adding the editor instance. It requires the textarea that will become the Text editor tab to be already created and not hidden in the DOM. Filtering of the settings is done on adding the editor instance from JS.

There are three new methods added to the wp.editor namespace:

  • wp.editor.initialize()
  • wp.editor.remove()
  • wp.editor.getContent()

(See wp-admin/js/editor.js for more info.)

The default WordPress settings are passed to the initialize() method automatically, and can be overridden by passing a settings object on initialization, similarly to using wp_editor() in PHP.

In addition there are several custom jQuery events that are fired at different stages during initialization:

  • wp-before-tinymce-init is fired before initialization and can be used to set or change any editor setting. It passes the settings object.
  • tinymce-editor-setup is fired after initialization has started but before the UI is constructed. It passes the editor instance object.
  • tinymce-editor-init is fired when the TinyMCE instance is ready (same as the init event in TinyMCE).

Here’s an example of how to add few of the default TinyMCE buttons to the toolbar:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	editor.settings.toolbar1 += ',alignleft,aligncenter,alignright';
});

Here is another example of how to add a custom button:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
	editor.settings.toolbar1 += ',mybutton';

	editor.addButton( 'mybutton', {
		text: 'My button2',
		icon: false,
		onclick: function () {
			editor.insertContent("It's my button!");
		}
	});
});

For more information please see the TinyMCE documentation.

#4-8, #editor, #tinymce

Increased Concurrent Jobs on Travis CI Builds

https://travis-ci.org/WordPress now has 15 concurrent jobs instead of the default 5 available to all open-source projects.

This covers all projects under https://github.com/WordPress, so it will help with daily development of Gutenberg, build times for our official wordpress-develop build (especially during releases), and ensuring that builds for these two projects don’t interfere with each other.

Dev Chat Summary: May 17th (4.8 week 3)

This post summarizes the dev chat meeting from May 17th (agendaSlack archive).

4.7.5 Release

  • 4.7.5 was released; six security issues and three maintenance fixes, thanks to everyone who pitched in to get that out!

4.8 Timing

  • Beta 1 went out on Friday, May 12th
  • Beta 2 is due out this Friday, May 19th; potentially shepherded by @matias between 16:00 and 18:00 UTC
  • Please plan anything important before Beta 2 in by Thursday evening, May 18th

4.8 Bug Scrubs

4.8 Dev Notes / Field Guide

Location identification in Events widget

General announcements

  • Anything outside Customize, Editor, REST API, and CLI has lower priority focus in 2017
  • Major work on other components will likely not be merged or considered

#4-7, #4-7-5, #4-8, #dev-chat, #summary

4.8 Bug Scrubs for RC 1

The following bug scrubs will help us drop to 0 tickets in the 4.8 milestone by RC1 on Thursday, May 25th:

Reminder that Thursday, May 25th is 4.8 Release Candidate 1.

As a refresher, here’s a post from the 4.7 release cycle answering questions about bug scrubs.

#4-8, #bug-scrub