WordPress 5.4 – Open Call for Tickets

Since we have a plan for the next releases, it’s time for an open call for tickets!

Although iterating and stabilizing the new block editor is still top of the list, I’d like to open this call for additional high priority items.

Please leave a comment that links to tickets that need some attention in this release cycle. 

Component Maintainers: please comment with features that you might have in the works.

Thanks!

Note: Adding your ticket here won’t necessarily guarantee inclusion. Still, no one can fix things they can’t see, so bravely and kindly share.

#5-4

Proposed JavaScript Coding Standards Revisions for Prettier Compatibility

(The following standards revision proposal was drafted by @jsnajdr. Jarda maintains the wp-prettier Prettier fork and has been working to introduce it to the Gutenberg repository. You’re invited to provide feedback to this proposal in the comments below, or to join an upcoming JavaScript meeting in #core-js, where this will be discussed)


Across the JavaScript community, the Prettier code formatter has become immensely popular over that last three years since it was originally released. It automatically performs high-quality formatting of your JavaScript code: when you press Save, your code is instantly formatted. This removes a distraction for contributors who write or review code, and allows them to focus on the more valuable aspects of their work without having to discuss the JavaScript WordPress Coding Standards so often. That’s why we’d like to adopt it in the WordPress JavaScript code bases, too.

The official Prettier formatter is very opinionated and has very few options. The reasons are both technical and cultural. The complexity of the formatting algorithm would explode exponentially with too many options and their combinations, and a part of the project vision is to establish an unified JavaScript formatting standard.

The WordPress formatting standard has one major incompatibility with the Prettier convention: it requires spaces inside all kinds of parens — (){}[], inside template strings, JSX attributes and expressions, everywhere:

function Label( { text, icon } ) {
	if ( ! [ 'left', 'right' ].includes( icon ) ) {
		return null;
	}

	return (
		<label className={ `icon-${ icon }` }>
			{ text }
		</label>
	);
}

To teach this convention to Prettier, we had to create a fork that adds an extra option and modified the paren-formatting code, and publish it on NPM under the name wp-prettier (@wordpress/prettier would arguably be even better name!). At this moment, we’ve been using that fork for 2.5 years in the Calypso and Jetpack projects, have maintained and updated it over countless upstream releases, and are confident that we can recommend it to anyone who wants to format their JavaScript code the WordPress way.

In a Gutenberg pull request, we are proposing adopting the WordPress Prettier tool in the project.

After adding support for the WordPress style paren spacing, there remain several very minor cases where Prettier formats JavaScript code slightly differently from what the current WordPress JavaScript Coding Standards recommend. They don’t diverge from the essence and spirit of the WordPress coding standards. Further patching of Prettier would be, on our opinion, not worth the coding and maintenance effort. And in some cases is outright impossible, because the recommendation asks for human judgment that an algorithm cannot implement.

In this post, we propose several small changes of the coding standards that align them fully with the Prettier convention.

Formatting ternaries and binary ops

The standard says that when breaking a long statement, the “operator” should be at the end of line, and doesn’t distinguish between binary and ternary operators. But Prettier does. When breaking a binary operator, it indeed puts the operator at the end of line:

const result =
	partOne +
	PartTwo;

But the parts of a ternary operator are put on the start of the new line (after the indentation):

const result = isRtl
	? 'right'
	: 'left';

Also, the standard recommends that long “lines should be broken into logical groups if it improves readability”. That doesn’t happen with Prettier — it wraps the lines if and only if the line would be longer than maximum line length otherwise. We propose to remove that ambiguous and subjective formulation from the standard.

Wrapping chained n-ary operators

Another difference related to binary operators and the Multi-Line Statements section is that Prettier puts each operand on separate line, even the left side of an assignment. It doesn’t do the “fluid text wrap” style like this:

const result = a + b +
	c + d;

but this:

const result =
	a +
	b +
	c +
	d;

To address all these differences, we propose to reformulate the Multi-Line Statements section of the standards document as follows (the last paragraph about conditionals is unchanged):

Before:

When a statement is too long to fit on one line, line breaks must occur after an operator.

// Bad
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c
	+ ' is ' + ( a + b + c ) + '</p>';
 
// Good
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c +
	' is ' + ( a + b + c ) + '</p>';

Lines should be broken into logical groups if it improves readability, such as splitting each expression of a ternary operator onto its own line, even if both will fit on a single line.

// Acceptable
var baz = ( true === conditionalStatement() ) ? 'thing 1' : 'thing 2';
 
// Better
var baz = firstCondition( foo ) && secondCondition( bar ) ?
	qux( foo, bar ) :
	foo;

When a conditional is too long to fit on one line, each operand of a logical operator in the boolean expression must appear on its own line, indented one extra level from the opening and closing parentheses.

if (
	firstCondition() &&
	secondCondition() &&
	thirdCondition()
) {
	doStuff();
}

After:

When a statement with operators is too long to fit on one line and is broken into multiple lines, line breaks must occur after a binary operator. Each operand with the operator that follows it must be on a separate line.

// Bad
const html = '<p>The sum of ' + a + ' and ' + b + " plus " + c
	+ ' is ' + ( a + b + c ) + '</p>';
 
// Good
const html =
	'<p>The sum of ' +
	a +
	' and ' +
	b +
	' plus ' +
	c +
	' is ' +
	( a + b + c ) +
	'</p>';

On the other hand, when a long statement with a ternary operator is broken into multiple lines, the parts of the ternary operator should be after the line break:

// Bad
const baz = true === conditionalStatement() ?
	'thing 1' : 
	'thing 2';

// Good
const baz =
	true === conditionalStatement()
		? 'thing 1'
		: 'thing 2';

When a conditional is too long to fit on one line, each operand of a logical operator in the boolean expression must appear on its own line, indented one extra level from the opening and closing parentheses.

if (
	firstCondition() &&
	secondCondition() &&
	thirdCondition()
) {
	doStuff();
}

Chained method calls and context

The standard recommends that when one method in a chain “changes the context”, it should add an extra indentation:

elements
	.addClass( 'foo' )
	.children()
		.html( 'hello' )
	.end()
	.appendTo( 'body' );

But Prettier doesn’t know what the context is — it’s an ambiguous concept even for a human. So it indents everything equally:

elements
	.addClass( 'foo' )
	.children()
	.html( 'hello' )
	.end()
	.appendTo( 'body' );

It also adds one extra touch: if the initial identifier is just one or two characters long, it will keep the first method call on the same line:

el.addClass( 'foo' )
	.children()
	.html( 'hello' )
	.end()
	.appendTo( 'body' );

To address these differences, we propose to reformulate the Chained Method Calls section of the standards document as follows. The new formulation removes the requirements that can’t be reasonably implemented, focuses on the main points, i.e., breaking into multiple lines and consistent indentation, and modernizes the jQuery-based example to show more contemporary, functional JavaScript code.

Before:

When a chain of method calls is too long to fit on one line, there must be one call per line, with the first call on a separate line from the object the methods are called on. If the method changes the context, an extra level of indentation must be used.

elements
	.addClass( 'foo' )
	.children()
		.html( 'hello' )
	.end()
	.appendTo( 'body' );

After:

When a chain of method calls is too long to fit on one line, it must be broken into multiple lines where each line contains one call from the chain. All lines after the first must be indented by one tab.

findFocusable( context )
	.filter( isTabbableIndex )
	.map( mapElementToObjectTabbable )
	.sort( compareObjectTabbables )
	.map( mapObjectTabbableToElement );

#javascript, #standards

What’s new in Gutenberg? (11 December)

Gutenberg 7.1 is a big release with 161 pull requests merged. Thank you to all the contributors of this release!

The release contains many refactors to the code base to make future changes possible, e.g., refactors to functional components so it is possible to use new hooks that are available.

This release tries to make block development using standard features like color picking UI easier. To do that the release expands the useColors hook to have new functionalities like color contrast checking and default color detection.

There was huge progress on the full site editing work, with the merge of the template part block. Documentation efforts for the FSE (full site editing) work are now in progress.

Gutenberg 7.1 brings a new welcome UI for new users:

This release also Introduces table captions and implements a UI mechanism to toggle between edit and select modes:

The last two enhancements to note are the new fixed-mobile toolbar and the improved multi-block selection experience:

7.1 🇲🇽

Features

Enhancements

Bug Fixes

APIs

Experiments

Documentation

Performance

Various

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 7.1.0 7.45s 88.56ms
Gutenberg 7.0.0 6.84s 94ms
WordPress 5.3 6.33s 75.19ms

#core-editor, #editor, #gutenberg

Editor chat summary: Wednesday, 11 December 2019

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, December 11, 2019, 14:00 UTC.

Gutenberg 7.1.0

  • Gutenberg 7.1.0 is released.
  • Massive progress on full site editing experience.
  • Some of the feature highlights:
    • New welcome UI in place of tips.
    • Table captions and UI to toggle between edit and select mode.
    • New fixed toolbar for mobile.
    • Improved multi-block selection experience.
  • This is a big release with 161 pull requests merged, for details checkout release post.

Weekly Priorities

  • Full site editing / block content areas
  • Block patterns API
  • Improvements to the Block UI  
  • Tightening up items

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

@youknowriad

@karmatosed

@mkaz

@aduth

@gziolo

  • Refactoring to the block toolbar, including some visual tweaks
  • Iterations to Build Tools: Integrate DependencyExtractionWebpackPlugin in the JS build https://core.trac.wordpress.org/ticket/48154
  • Reviews, including some learnings about TypeScript, JSDoc, etc.
  • Ported wp-cli scaffold block to npm init wordpress-block – this generates ES5 JS code, I plan to provide ESNext +JSX template as an option next week

Open Floor

#meeting-notes, #core-editor, #editor, #gutenberg

Admin form controls height and alignment standardization in WordPress 5.3.1

WordPress 5.3 introduced some notable Admin CSS changes to improve administration accessibility and consistency with the block editor.

These changes made more obvious that form controls heights and alignments were not consistent across WP Admin.

Before WordPress 5.3, there were already some inconsistencies between form controls. For reference, WordPress 5.2 form controls various alignments and heights are grouped in the screenshot below:

Form controls alignment and height inconsistencies in WordPress 5.2

WordPress 5.3 Admin CSS changes brought more attention to those general inconsistencies on form controls. And several users and contributors reported these inconsistencies as regressions from 5.3.

Example of form controls inconsistencies in WordPress 5.3

Although these inconsistencies cannot be considered as regressions from 5.3 since they existed before 5.3 Admin CSS changes, WordPress 5.3.1 introduces some fixes on heights and alignments.

5.3
5.3.1
5.3
5.3.1
5.3
5.3.1

WordPress 5.3.1 changes include:

  • Standardized height basis of 30px for all form controls
  • Consistent line height basis of 30px across the interface
  • 14px font size basis for select controls option text
  • Remove various top/bottom margin and padding

These changes are part of a continuous effort to improve styling and consistency of all form controls in the WordPress admin pages. In general, plugin authors and WordPress developers are encouraged to:

  • remove any fixed height: flexible heights are now the WordPress recommended standard to allow form controls to better scale with text zoom
  • remove any custom top and bottom padding values
  • remove any custom line-height value
  • remove any custom min-height value
  • update custom focus/hover styles on custom UI components to match the new WordPress focus/hover styles

For full details about these changes, see the related changeset on WordPress Trac. WordPress developers and plugin authors may also want to visit the related Trac ticket: #48420

#5-3-1, #core-css, #dev-notes

Alternate color schemes changes in WordPress 5.3.1

WordPress 5.3 added some noteworthy CSS changes to WordPress Admin. These changes also impacted alternate color schemes, especially concerning secondary buttons.

Indeed, secondary button borders unexpectedly inherited their scheme’s primary color, which resulted in arguable visual aspect and poor readability for most color schemes.

“Blue” alternate color scheme in WordPress 5.3
“Coffee” alternate color scheme in WordPress 5.3
“Midnight” alternate color scheme in WordPress 5.3

A bug also occurred on :active state, where the background color of the button was quite the same than the text color.

On the right: secondary button with :active state on “Blue” color scheme in WordPress 5.3
On the right: secondary button with :active state on “Midnight” color scheme in WordPress 5.3

WordPress 5.3.1 will fix these issues by unifying WP-Admin secondary buttons for all alternate color schemes.

Secondary button styles will be the same for all bundled alternate color schemes. This change also fixes the :active state CSS issue.

Please note this change also introduces some hardcoded colors for both gray borders and texts. Plugin authors who provide specific support for alternate color schemes can use these new hardcoded colors.

New secondary button CSS/Sass styles in WP 5.3.1:

.button {
	border-color: #7e8993;
	color: #32373c;
}

.button:hover {
	border-color: darken( #7e8993, 5% );
	color: darken( #32373c, 5% );
}

.button:focus {
	border-color: #7e8993;
	color: darken( #32373c, 5% );
	box-shadow: 0 0 0 1px #32373c;
}

See /wp-admin/css/colors/_admin.scss.

New CSS styles for secondary buttons in alternate color schemes:

Secondary buttons in WordPress 5.3.1
“Midnight” alternate color scheme in WP 5.3.1
“Coffee” alternate color scheme in WP 5.3.1

For reference, see the related Trac tickets: #48585 and #48598.

#5-3-1, #accessibility, #core-css, #dev-notes

Editor Chat Agenda: 11 December, 2019

Note taker: @ajitbohra

This is the agenda for the weekly editor chat scheduled for 2019-12-11 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Gutenberg 7.1.0
  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda#core-editor#editor-chat

PHP Native JSON Extension Now Required

The PHP native JSON extension has been bundled and compiled with PHP by default since 5.2.0 (2006). However, a significant number of PHP installs did not include it. In order to ensure a consistent experience for JSON related functionality in all supported versions of PHP, WordPress Core has historically included a large number of workarounds, functions, and polyfills.

In 2011 (WordPress 3.2), an attempt was made to remove JSON related compatibility code. However, it was discovered that a fair number of distributions were still missing the PHP JSON extension by default, and the removed code was restored to ensure compatibility.

In WordPress 5.2, the minimum version of PHP supported was raised from 5.2.6 to 5.6.20. In the 8 year period since the last attempt was made to encourage use of the PHP native JSON extension, the number of distributions with this extension disabled has significantly decreased.

Because of this, the PHP native JSON extension is now required to run WordPress 5.3 and higher.

To prevent compatibility issues, a site that does not have the PHP native JSON extension enabled will see an error message when attempting to upgrade to WordPress 5.3. The update will be cancelled and the site will remain on the current version (see [46455]). This is to prevent potential compatibility issues on servers running custom PHP configurations.

Here’s a summary of what has changed.

Deprecated

The following functions and classes will remain in the code base, but will trigger a deprecated warning when used (see [46205]):

  • The Services_JSON and Services_JSON_Error classes and all methods
  • The wp-includes/class-json.php file
  • The (private) _wp_json_prepare_data() function

Removed

The following functions, and classes have been removed entirely from the code base (see the [46208] changeset):

  • json_encode() function polyfill
  • json_decode() function polyfill
  • _json_decode_object_helper() function polyfill
  • json_last_error_msg() polyfill
  • JsonSerializable interface polyfill
  • $wp_json global variable
  • JSON_PRETTY_PRINT constant polyfill
  • JSON_ERROR_NONE constant polyfill

Unchanged

The wp_json_encode() function will remain with no intention to deprecate it at this time. This function includes an extra sanity check for JSON encoding data and should still be used as the preferred way to encode data into JSON.

For more information about these changes, check out #47699 on Trac and the relevant changesets ([46205], [46206], [46208], [46377], and [46455]).

Props @jrf & @jorbin for peer review.

#5-3, #dev-notes, #php

Introducing Twenty Twenty

The Block Editor will soon celebrate its first birthday in Core and with every update it grows more capable. The promise of the block editor is to give users the freedom to design and structure their sites as they see fit. The responsibility of a theme is to empower users to create their inspired vision by making the end result look as good, and work as well, as the user intended.

With that in mind, WordPress 5.3 will include a new default theme: Twenty Twenty. The Twenty Twenty team is @anlino as design lead, @ianbelanger taking charge of development, and @poena representing the Theme Review team.

The sub page view in Twenty Twenty.

A sub page in Twenty Twenty.


Twenty Twenty is designed with flexibility at its core. If you want to use it for an organization or a business, you can combine columns, groups, and media with wide and full alignments to create dynamic layouts to show off your services or products. If you want to use it for a traditional blog, the centered content column makes it perfect for that as well. 

As befits a theme called Twenty Twenty, clarity and readability is also a big focus. To that end, the theme will include the typeface Inter, designed by Rasmus Andersson. The tall x-height of Inter makes it highly legible in the smallest of font sizes, and provides a strong personality when used in big headings. 

Inter comes in a Variable Font version, a first for default themes, which contains all weights and styles of Inter in just two font files. In modern browsers, this will help keep the number of requests and the page size down. Older browsers will fall back to loading each weight as a separate file. Running text will be set in a stack of serif system fonts to keep load times short and data caps distant.

The single post view in Twenty Twenty.

A blog post in Twenty Twenty.


Twenty Twenty will include full support for the Block Editor, as well as editor styles that make sure the editing experience matches the end result. In order to speed up development, Twenty Twenty will be based on the WordPress theme Chaplin, which was released on the WordPress.org theme directory earlier this summer.

You can find full page mockups of Twenty Twenty here:

Timeline

As mentioned in the release plan, WordPress 5.3 is targeted for release on November 12th, 2019. The first release candidate is targeted for October 15th.

Get Involved

If you are interested in contributing to Twenty Twenty, make sure you are following this blog. During the design and development process, there will be weekly meetings starting Monday at 19:00 UTC in #core-themes.

Theme development will happen on GitHub and in the interest of time, an in-progress version of the theme code has been uploaded here: https://github.com/WordPress/twentytwenty. Once the theme is stable, it will be merged into core and the GitHub repo will be deprecated.

Learn more

If you’re interested in learning more about default themes, you can read the following posts:

Devchat summary: December 04, 2019

@francina led the chat based on this agenda.

Announcements

@audrasjb gave an update of bug scrubs for 5.3.1 minor release. The current status is 3 scrubs already done and 3 others scheduled for the rest of the week. The agenda of the scrubs for the release is available here. There are currently 20 tickets closed as fixed and 29 open for the milestone. Audras Jb also confirmed that targeted date for the release is December 11 or 12.

There was also a small discussion with @audrasjb, @marybaum, @azaozz and @johnbillion about the correct appellation of the testing phase before the minor release, either Beta of Release Candidate.

@azaozz also stated that a good date for the first Release Candidate can be early in the week of Monday 9, and that the team can organize another scrubs if any new bugs appear.

@francina gathered opinions about the release team. The team for WordPress 5.3.1 release is officially constituted by @sergey, @audrasjb, @amy kamala, @marybaum, and @whyisjake.

@francina reminded about 5.4 release which is still  in early stages, and shared the link of its open call for tickets. Everyone interested is invited to add their comments.

Highlighted Blog Posts

@francina shared this post about WordPress 5.3 retrospective recap and next steps.

Open Floor

Another discussion about a possible date for 5.4 and releases cycles duration happened. @francina reminded that the targeted date for now is March 31st 2020, after @jorbin asked if it can take place in January.

Francina also precised that there is currently an ongoing discussion about shortening the futures releases cycles.

@azaozz stated that “historically” the holiday season has been slow on the “development” side and quite lively on “organizational” side, and that this can be a good time to speed things up.

@jorbin stated that the short cycle for 5.1 last year showed that we can get a beta out in January and release in February without much difficulty.  @francina then point us to this Matt’s message, where he mentioned that the team is trying to get as much as possible into point releases, including possibly Gutenberg updates; point releases being only about regressions.

@jorbin reminded that during the 4.9 release cycle, the decision was made to start backporting some features. And that he thinks that this is only needed if we keep the slow major releases that we have had historically.

@francina then proposed a working group that will evaluate how we can reduce the manual work for the futures releases. And asked if there are already tools or procedures for that.

@johnbillion precised that his tought  is that a release schedule makes releases and makes time planning easier for everyone.

Important reminder from @nacin about the biggest focus area if the team want to speed up things should be automated testing and updates process.

The devchat hour ended up with @francina allowing attendees to continue the discussion for an extra time as it might be a kind of blocker now.

The rest of the discussion about releases cycles can be found starting by here in #core.

Details about others aspects of this have been discussed in the following posts:

#devchat, #summary