The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Proposed JSDoc guidelines were merged since the last meeting. They are available in a readable format in its own section in the Coding Guidelines for Gutenberg.
Discussion:
In the previous week, we talked about having some new conventions to support what we need for the types effort summarized in the tracking issue on GitHub.
@aduth shared that as he’s been working through these tasks (PR for Priority Queue package), he’s already found a few other things that might be worth contemplating. He has a sense this could be an evolving standard or at least a need for some additional clarity in specific cases as noted in the agenda:
Explicit recommendation on types capitalization ({Object} vs. {object}).
@see vs. @link correctness – the current guidelines are mistaken in treating @link as a non-inline tag.
The eslint-plugin-jsdoc plugin we now use in Gutenberg has most of the “defaults” we had already been preferring for some time. The point is to make this explicit in the recommendations, as well.
There have been a couple of comments on the post already. Still, they don’t seem to be directly relevant for what’s being considered in these revisions, and more to the quality of the document generally-speaking.
There is also this question of how we document the expected way of using Prettier. @aduth assumed there’s some need for editor integration or pre-commit script for these formattings to take effect. He also emphasized that when doing anything on that front, we should be preemptive about making this as minimally-disruptive as possible.
Actions:
Let’s wait until next Tuesday to make any “decisions” since one day of soliciting feedback might not be enough.
@davilera tried to use wp.date and encountered an issue, which somebody had already reported. We need some feedback on the proposed PR from those who worked on dates more closely in the past. In the current shape, the library is currently hard to work with, and therefore developers are forced to implement workarounds.
Open Floor
Currently, there is only simple support for block scaffolding in WP-CLI that generates code that runs in the browser without the need for a build step. It’s documented here.
@gziolo ported this script to work with Node.js without the need to have an active installation of WordPress. The plan is to introduce the concept of templates and provide the default support for ESNext, JSX and all modern JavaScript tooling installed out of the box with the single command from CLI:
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
@gwwar asked what’s the planned schedule for the plugin release in the upcoming holidays season. Some discussion about delaying it with no decicion. Kindly share your thoughts in comments
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.35.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
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:
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.
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.3On 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.
@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 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:
