Jonathan Desrosiers 9:01 pm on February 20, 2019
Tags:   

WordPress 5.1.1

A part of last week’s devchat contained a discussion about short-cycle maintenance releases and how they are handled. Another post will be published to discuss this longer term. But, a short term plan for 5.1.1 needs to be established so component maintainers and committers can prioritize their efforts in the coming weeks.

Keeping with the recent 2-week minor release cadence used in the 5.0.x releases, and with the proposed 5.2 release schedule in mind, this is the proposed release schedule for WordPress 5.1.1:

  • March 4, 2019: 5.1.1 RC
  • March 7, 2019: 5.1.1 Release Date

Given the shorter release timeline and the quick turnaround of 5.2, 5.1.1 should only consist of:

  • Important bug fixes.
  • 5.1 regressions.
  • Small block editor improvements.

If 5.1.2 is deemed necessary, the same 2 week cadence will be followed, making the preliminary, if necessary release date for 5.1.2 as March 21, 2019.

Release leads have not yet been determined for this release. If you are interested, please comment below. Since this is a smaller release, it is a great opportunity for someone interested in helping with their first release.

#5-1

Jonathan Desrosiers 8:08 pm on February 20, 2019
Tags: ,   

Reverting the Bulk Ticket Closing

Recently, a bulk modification was performed on Trac affecting 2,300+ tickets that had not seen any activity in 2 years or more. These tickets were closed and marked as wontfix. To read a more detailed breakdown, check out the previous post on the subject.

After discussing, it has been determined that the bulk action should be reverted, but only for tickets that have not had their status changed or otherwise confirmed via comments that closing is acceptable since the bulk closure. It can be safely assumed that closed tickets updated after the bulk edit have been appropriately groomed and should remain in their current state. A full list of tickets slated to be reopened can be found using this Trac query.

Tickets should only be closed if they have been individually evaluated and it is determined that they are either no longer relevant, have been fully and properly addressed, and any changes have been adequately communicated to the community.

These tickets will be reopened during the week following the 5.1 release (February 24-March 2) by @jeffpaul and myself (@desrosj). All reopened tickets will be placed in the Awaiting Review milestone so that they can be properly triaged by component maintainers and the Triage Team in the coming months.

#trac, #triage

Riad Benguella 10:37 am on February 20, 2019
Tags: , ,   

What’s New in Gutenberg? (20th February)

More than 51 contributors participated in this release. It marks an important milestone for Phase 2, as it’s the end of the porting widgets to blocks project. Next releases will be focused on explorations around the Widgets screen.

Widgets 2 Blocks

This release also includes a big refactoring to the formatting buttons and the RichText component, allowing us to fix a significant number of issues and to improve the writing flow.

Core blocks (aside from the Classic block) are not using TinyMCE under the hood anymore. This change should not have any perceivable impact, as the APIs of the RichText component and the custom formats registration have not changed.

In addition, contributors have worked on a number of improvements to existing blocks and UI micro-animations.

Enhanced Menus
Click to activate embed blocks

5.1

Features

Enhancements

Bug Fixes

Various

Chore

Documentation

Mobile

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 5.1.0 9.4 seconds 16.4ms
Gutenberg 5.0.0 10.4 seconds 16.4ms
Gutenberg 4.8 (WordPress 5.1) 13.6 seconds 158.2ms
Gutenberg 4.7 (WordPress 5.0) 15.1 seconds 203.5ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Jorge Costa 10:28 am on February 20, 2019
Tags: , , ,   

JavaScript chat summary, February 19th, 2019

Below is a summary of this week’s JavaScript chat (agenda, Slack Transcript). Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: NPM Mono-Repo Subdirectory Declaration

https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

@adamsilverstein quoted @aduth‘s note that we should consider implementing the npm monorepo declaration in the WordPress npm packages.

@aduth added that implementing this declaration would be a straightforward task that would help make npm more “aware” of where to find the specific source for a package in a mono-repository, hopefully improving links.

The idea was well received.

@aduth has created issues related to this task:

Feel free to share your thoughts and provide feedback related to this subject in the issues.

Agenda: Feature Flags

https://github.com/WordPress/gutenberg/pull/13324

Feature flags were merged in the Gutenberg repository. Quoting @gziolo:

feature flags in Gutenberg, it’s very simple approach which will allow us to enable new features only for the plugin while keep it completely removed from WordPress core using dead code elimination.

We went into more detail of what feature flags are and what they allow.

@atimmer noted that most commonly feature flags allow to enable or disable specific features while Gutenberg feature flags apply to a whole set of features e.g.: “phase 2 features”.

@aduth referred that the reason behind this decision may be related at least partly to the objective of simplifying dead code removal.
More information can be found at https://github.com/WordPress/gutenberg/pull/13324.

@adamsilverstein shared that he wants to introduce a feature in the hooks package whose code should only be included when the SCRIPT_DEBUG flag is set. Any feedback to this is welcome and can be provided in https://github.com/WordPress/gutenberg/pull/12038.

During the discussions, it was referred that, although dead code removal is a common and used by famous libraries like React, there are no good resource/references available online to help developers understand how dead code removal works.
If you know any good resource feel free to share the link in the comments or the core-js channel.

Agenda: Build support for wordpress/scripts

Relevant PR’s:

According to @gziolo both PR’s are almost ready, but they need additional testing given the complexity of running the scripts with default configuration in various external projects.

@adamsilverstein noted that webpack setup is a significant barrier to entry for new developers and the more we can improve our tools the better.

@gziolo referred that a tutorial was already created and it will be simplified after latest changes are published.

Open floor

@nerrad referred that he would like to use the new version of React, more specifically React hooks, and asked when a React upgrade should be considered and when a WordPress release will contain the next version of React.

Answering to @nerrad, @aduth noted that upgrading React should be a non-issue although we may need some scrutiny on what is exposed. Regarding the WordPress releases, @aduth expects that anything merged to Gutenberg repository between now and mid-March should be part of the WordPress 5.2 release, but this specific subject will be clarified during the next #core-editor meeting https://make.wordpress.org/core/2019/02/19/editor-chat-agenda-february-20th/.

@nosolosw announced that in the past days the first auto-generated API documentation was merged to the Gutenberg repository: https://github.com/WordPress/gutenberg/pull/13856.
The tool that autogenerated the documentation is proposed in https://github.com/WordPress/gutenberg/pull/13329.
The next package/component that will be used as a testbed for the tool is not yet decided and every suggestion is welcome.

#core-js, #javascript, #meeting-notes

Heather Burns 9:40 am on February 20, 2019
Tags:   

#core-privacy Office Hours Minutes – 13 February 2019

The following is a summary of the weekly core-privacy office hours held on 13 February 2019. Weekly privacy office hours are held every Wednesday at 19:00 UTC. A full transcript can be found here in the #core-privacy channel in the Make WordPress Slack.

Participants: @desrosj @dejliglama @idea15 @pepe @lakenh @chriscct7 @postphotos

Admin pointers

@desrosj has created a patch (#45999) to remove the admin pointers for the privacy features which were added in 4.9.6. The attendees agreed that the pointers’ usefulness peaked around the GDPR deadline time when the features were new, but they are no longer necessary.

Workplan for 5.2

The team agreed ten tickets to focus on for release 5.2, all of which are bugfixes or enhancements of existing tools.

The bug scrub for Monday 25 February will focus on 5.2 tickets, and the bug scrub for Monday 4 March will focus on component tickets marked awaiting review.

Component roadmap

@desrosj and @dejliglama have cleaned up the draft roadmap for the component’s work in 2019. The group will finalise all outstanding issues on the roadmap during office hours on Wednesday 20 February, and will post the final roadmap to Make.

Candidates for feature plugins

The roadmap process has included discussions of which new features would be best delivered as plugins. These include embed privacy controls, WP-CLI support, multisite support, and Gutenberg blocks for data export and erasure requests.

Google Fonts

In response to privacy and performance concerns about Google Fonts (#46169, #46170), @pepe is creating a proof of concept patch to add a customizer option to disable Google Fonts for the older (pre-Twenty Nineteen) default themes.

Upcoming WordCamp/conference privacy talks

Cross-CMS privacy working group report

The cross-project privacy team is creating a draft workflow to audit project plugins, modules, and extensions for best privacy practice. The workflow is designed to be adapted to each project’s specific needs. Please review and comment on the first draft.

#core-privacy

Josepha 12:14 am on February 20, 2019  

Dev Chat Agenda: February 20

Below is the agenda for the weekly devchat meeting on Wednesday, February 20, 2019 at 21:00 UTC:

  • 5.1 updates:
    • Last minute requests for help
  • 5.2 updates:
    • Please read this post for context before our meeting! https://make.wordpress.org/core/2019/02/19/wordpress-5-2-schedule-and-scope/
  • Updates from focus leads and component maintainers
  • Open Floor

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

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

#5-1, #agenda, #core, #dev-chat

Tammie Lister 1:45 pm on February 19, 2019  

Editor Chat Agenda: February 20th

This is the agenda for the weekly editor chat meeting on Wednesday, 20th February 2019, 14:00 GMT.

  • Gutenberg Release 5.1
  • WordPress 5.2 Planning
  • @joostdevalk would like to propose updating wordpress.org/gutenberg
  • Tasks Coordination
  • Open Floor

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

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

#agenda, #editor-chat

Gary Pendergast 12:48 am on February 19, 2019
Tags: 5.2   

WordPress 5.2 Schedule and Scope

With WordPress 5.1 RC1 being released, and trunk being reopened for work on WordPress 5.2, let’s discuss what the release schedule should look like, and what can be done in that time.

During the core chat earlier this week, I proposed a “late April” release date. This is primarily driven by the proposal to bump WordPress’ minimum PHP and MySQL version requirements, which suggested April as an initial target.

Proposed WordPress 5.2 Schedule

To give something a little more specific than “late April”, I’d like to propose the following key dates for WordPress 5.2.

  • Beta 1: March 14, 2019.
  • Release Candidate 1: April 10, 2019.
  • General Release: April 23, 2019.

The end of April does have quite a few observed holidays to account for. The weekend of April 20/21 is Easter, the week of April 20-27 is Passover, and the weekend of April 27-28 is Orthodox Easter. The following week includes May Day, and is the week before the start of Ramadan.

I would like to propose April 23 as a reasonable compromise that isn’t an observed holiday for most people, and allows several days after the release for sites to test and upgrade.

Proposed WordPress 5.2 Scope

Given the timeframe, there are several projects in progress that would fit nicely.

Gutenberg

With the widgets to blocks being complete for Gutenberg 5.1, the Gutenberg work is ready to move into the next item on the 9 projects for 2019 list: the block directory. The way authors discover and use new blocks is shaping up to be an important part of the block editor experience, so join in the #meta and #core-editor channels to discuss this important part of our future infrastructure.

With the explosion of new blocks comes the need to manage them. There are a lot of plugins which add dozens of blocks, but authors may only need one or two of them. Being able to hide the ones they don’t use can only make the editing experience easier. The CoBlocks plugin recent introduced a Block Manager feature along these lines.

Additionally, the Gutenberg team have made more UX and performance improvements, which you can see in recent Gutenberg plugin releases.

Site Health Check

The Health Check plugin has been coming along nicely, and is looking like it will be ready to merge before beta 1. This is another of the 9 projects for 2019.

PHP Error Protection

While it missed WordPress 5.1, the core PHP team have been reworking the PHP Error Protection feature, and are on target for releasing it in WordPress 5.2.

Update Package Signing

Auto-updates are featured as two of the 9 projects for 2019, but to ensure these are completed in a safe and reliable fashion, there are a few steps to take beforehand. The first step involves implementing update package signing, which ensures sites have downloaded a valid update package. Once package signing has proven itself when running against WordPress 5.2.x releases, the next steps include improving the error detection and fallback mechanisms for the plugin and theme updaters, as well as making UI options available for enabling auto-updates.

Pending WordPress.org work and Systems approval, package signing could reasonably be ready for WordPress 5.2.

Everything Else

Of course, there’s always room for small enhancements and bug fixes. If there’s something you’re working on that could be ready for WordPress 5.2, please list it in the comments!

Proposed WordPress 5.2 Leads

@matt will continue his role as Release Lead, defining the scope of the release.

@chanthaboune will act as Release Coordinator, ensuring each of the WordPress 5.2 projects are communicating and running to schedule.

To avoid bottlenecks in the form of an unnamed Australian (who happens to be the author of this post), I’d like to propose we continue something that worked well during WordPress 5.0: a “feature release lead” role, with each of the projects having a point person to keep track of project status. For each of the proposed features (as well as any that are proposed in the comments), please put some thought into who could be a feature release lead, and include them in your comments.

#5-2

Mel Choyce 8:40 pm on February 18, 2019
Tags: , ,   

Porting Widgets to Blocks: Feb 18, 2019

All widgets we plan on porting to blocks have been merged! 🎉

Completed

Iterations

We have a couple of the more advanced widget blocks with v2 designs. These are “nice to haves,” but not necessarily scoped to any particular release.

In Progress

Needs Feedback & Dev

Notes

#blocks, #gutenberg, #widgets

Ajit Bohra 8:22 pm on February 15, 2019  

JavaScript chat summary, February 12th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

“React As UI Runtime” Article

@nerrad shared “React As UI Runtime” article by Dan Abramov. Its good resource for folks who are familiar with React and want to deep dive into internal working. It will give you insight into the various aspect of React how things work and why they work in a certain way.

Custom ESLint Rules

Two new ESLint rules have been implemented:

Icon Package

The design team is exploring improvements for the Dashicons project and proposed the following:

  • The current workflow for adding icons and updating the font is not ideal and doesn’t scale for a big number of icons.
  • Gutenberg requires a big number of icons to avoid duplicates, it relies on SVGs instead of fonts and an option being explored is to take Material Icons as a basis and extend it with WordPress specific icon sets.

Some ideas were explored but final decision pending, until some better ideas and direction by the design team is finalized:

  • Exposing icons to global script handle though that could be huge to load.
  • @nosolosw suggested:
    • Getting some inspiration from GridIcons.
    • wp_enqueue_icon a function to declare the icons for use and make them available under wp.icons.* (for the ones enqueued)?
  • @youknowriad suggested:
    • Bundling all the icons as a separate package one big set to choose from.
    • Using the build process and tree shaking to include icons in use.
    • Getting inspiration from FeatherIcons.
    • Lazy loading icons if feasible.

Open floor

  • @welcher shared a resource he put together for various slot-fill and filter.
  • @gziolo suggested to include them in the official handbook.

#meeting-notes, #core-js, #javascript