What’s next in Gutenberg? (October)

This is a monthly update containing the high-level items that GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ contributors are focusing on for October. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so. 

How to follow along with Gutenberg: 

Here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development related posts and a new Site Editing Milestone overview issue that breaks down the upcoming work into more concrete next steps. 

5.6 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 Preparation 

With October 20th marking the cut off for WordPress 5.6 Beta 1, there’s going to be a shift in approach this month to focus on what can or cannot be ready for 5.6 since, after the Beta 1, there’s not a way to merge additional features. As part of this preparation, a decision was made by the people working on the Navigation and the editor tech lead for 5.6 to exclude the Navigation Screen from 5.6. Outside of this decision, this focus mainly impacts projects like the Widgets Screen and various editor focused APIs as they will each need to reach a certain threshold in order to be included. Expect there to be lots of effort here to fine tune and make decisions in preparation for an exciting 5.6 release! 

Delaying 9.2 Release:

As mentioned in the latest core editor meeting, since Beta 1 for WordPress 5.6 is due on October 20, it’s likely that the next Gutenberg release will be delayed by one week in order to match the dates and include as many features as possible. This means that Oct 19th will likely be the RC for 9.2 and the stable release will be done on Oct 21 since the packages can be incorporated into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. before Beta 1.

Follow along:

Outside of following individual features and their progress, you can follow where things stand on this WordPress 5.6 Must Haves project board.

Global Styles & Editor focused APIs

Global Styles refers to the system that defines and manages global aesthetics allowing overall site styles, theme styles, and blocks to work well together. While great progress was made in September, the editor focused APIs are still in experimental status and a decision will need to be made about what can be included in 5.6. It’s anticipated that the theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. APIs might not be ready for 5.6 but the block.json one might be instead. Outside of decisions around 5.6, some of this work in the month ahead will include the following:

  • Adding support for themes to control the editor in a global context, and in a per blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. context.
  • Expand the global styles sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. with new options and improve its UIUI User interface.
  • Expand the typography controls and allow users to pick a custom font family and font-weight, and allow themes to configure which font families are available.
  • Add functionality that allows users to use the global styles sidebar to control the editor’s behavior like which color palette is active.

Follow along:

You can follow the progress for this overall system in this overview issue. For more recent and immediate next steps, you can follow this issue describing the current state of work. 

WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Screen

With the new Widget screen moved out of experimental status last month in Gutenberg 8.9, lots of work has gone towards addressing the feedback that’s come in as people have begun exploring this new screen. Right now, inclusion in 5.6 depends on the state of the Widget Screen before Beta 1 on October 20th. In an effort to successfully have this feature included in 5.6, efforts that were previously put towards the Navigation Screen are now being redirected here. As a result, expect that this area of work will be a big focus and decision point for the month ahead.

Along with handling any additional feedback that comes in, the following are specific items that will be worked on:

  • Deciding a path forward for how best to handle customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. & the widget screen interaction.
  • Creating updated designs for an improved user experience.
  • Exploring how third party widgets can be integrated.
  • Ensuring only superadmins can store HTML using the new APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoint.
  • Addressing a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) feedback around improving the navigation tool.

Join the Widgets Screen weekly meeting:

In light of the decision mentioned above, the previous meeting on the Navigation Screen project will now focus on Widgets. As a reminder, the meeting happens in #core every Wednesday at 7AM UTC. These meetings will be focused on triaging issues in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ with the [Feature] Widget Screen label and discussing any big structural issues. 

Help with testing:

As part of the vision for the Widgets Screen to ease adoption for everyone, modernize the experience outside of just site editing, and upgrade what’s possible by enabling third party extensibility, feedback is still needed to help this become a reality. If you haven’t had a chance to yet, please follow this call for testing and share any bugs or enhancements on GitHub. Thank you to everyone who has given feedback already and helped move this work forward! 

Follow along:

You can follow the progress of this work on this project board and by joining the weekly chat in #core every Wednesday at 7AM UTC.

Full Site Editing

As with the prior months, work on this major focus for phase 2 is ongoing and is expected to continue iterating over the coming months. Currently, 5 out of the 6 milestones for site editing are marked as In Progress with overview tracking issues created for each milestone to better plan next steps. With that said, work this month will continue to focus on finishing up Milestone 1 – Site Editing Infrastructure and UI and Milestone 2 – Site Editor Navigation. As in prior months, it’s expected that this work will continue into the months ahead:

We’re watching the Theme Experiments repo as well to see how themers are attempting to build block-based themes. Please continue to share there and know we appreciate it!

Follow along:

You can follow the progress of this project on this project board. To help break down this work more, a new overview issue with key milestones for site editing was also created. For each major milestone, there are related issues for each milestone that are recommended to follow if you want a more granular look at each next step (example from Site Editor Navigation).

As a reminder, if you’re interested in being a part of testing Full Site Editing, check out the experimental outreach program to learn more

Areas to be aware of:

Block & PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Developers:

There’s a new experimental light box wrapper API that allows for a new way to define blocks in order for the markup in the editor to match the front end. While documentation is planned, it hasn’t been written yet. In the meantime though, you can check out the current PRs as this is now ready to be used by plugins: creating edit/save symmetry and stabilizing the API

Theme Developers:

@joen did a wonderful show & tell session including in progress work on a Full Site Editing theme.

Additionally, any theme authors experimenting with Full Site Editing should check out the post from @aristath on a New JSON structure for FSE theme.json files.

Ways to Get Involved:

While the above items are our focuses, don’t forget that you can always help with triage, needs testing issues, good first issues and reviewing PRs. In particular for this month, focusing efforts around testing the Widgets Screen would be very helpful and high impact. 

If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

Meetings to join:

While you can view all meetings here, here are specific meetings to join depending on your interest. Remember that you need a WordPress.org slack account to participate: 

  • Core Editor weekly @ 14:00 UTC in #core-editor focused on all things Gutenberg. 
  • Widget Sync weekly @ 07:00 UTC in #core focused on triaging and discussing Widget Screen work. 
  • Block Based Themes meeting twice monthly at Wednesday @ 16:00 UTC in #themereview focused on preparing for Full Site Editing. 

#core-editor #gutenberg-next

Dev Chat Agenda: September 9th 2020


Here is the #agenda for this week’s meetings happening at: Wednesday, 9 September 2020, 0500UTC and Wednesday, 9 September 2020, 2000UTC

Please share any items you’d like to include in the comments below.

  • Announcements
  • Highlighted blogblog (versus network, site) posts
  1. Core Chat – Timezones and Daylight savings – Action Required: Decision time – in relation to Daylight Saving adjustments, are we keeping the meeting time consistent with UTC? Or changing call times to stay consistent with calendar time?
  2. WordPress 5.5 Retrospective: We want to hear from you! – Action Required: Please add your response to the retrospective form with your thoughts from the 5.5 release – deadline Saturday September 12 07:00 UTC
  3. What’s next in Gutenberg (September): Comprehensive post about where things are at with the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor – There may be action required of you are a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme dev, or if you want to get involved.
  • Calls from component maintainers and/or focus leads
  • Open Floor

    If you have something else you want to include to the agenda, please mention it in the comments below.

The #dev-chat meetings will be held on Wednesday, 2 September 2020, 05:00UTC and Wednesday, 9 September 2020, 2000UTC. These meetings are held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

#5-6

What’s next in Gutenberg? (September)

This is a monthly update containing the high-level items that GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ contributors are focusing on for September. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so. 

How to follow along with Gutenberg: 

Here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. There is also an index page of Gutenberg development related posts and a new Site Editing Milestone overview issue that breaks down the upcoming work into more concrete next steps. 

Global Styles & Editor focused APIs

Global Styles refers to the system that defines and manages global aesthetics allowing overall site styles, theme styles, and blocks to work well together. Currently, the hope is that work on editor focused APIs can be wrapped up in the month ahead if all goes well. Some of this work will include the following:

Follow along:

You can follow the progress for this overall system in this overview issue. For more recent and immediate next steps, you can follow this issue describing the current state of work. 

WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Screen

After months of work, this new screen has been launched out of experiments in the latest Gutenberg 8.9 release. This should allow for plenty of time for feedback before the 5.6 release. With blocks firmly paving the way for the future, this work on the widget screen is meant to help modernize the experience outside of just site editing, ease adoption for everyone, and upgrade what’s currently possible by enabling third party extensibility. This vision can’t be accomplished without feedback so please test and share any bugs or enhancements on GitHub. Work this month will include the following along with the feedback received from users: 

Follow along:

You can follow the progress of this project on this project board.

Full Site Editing

As with the prior months, work on this major focus for phase 2 is ongoing and is expected to continue iterating over the next months. Keep in mind that much of this work relates to other areas like Global Styles & Editor Focused APIs! With that in mind, work this month will mainly focus on the following based on the Milestone 2 – Site Editor Navigation. Note that timing for this work will  likely need to be adjusted depending on progress made meaning this work might start in September but continue going forward.

  • Group document settings in the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.
  • Indicate current template and template part when in site editor.
  • Move templates and page navigation into the main W sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme..
  • Allow browsing all templates and parts. 
  • Incorporate “Add New Page” Flow into “Add Template”.
  • Begin exploring missing functionality for the query blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. as part of milestone 5. 

We’re watching the Theme Experiments repo as well to see how themers are attempting to build block-based themes. Please continue to share there and know we appreciate it!

Follow along:

You can follow the progress of this project on this project board. To help break down this work more, a new overview issue with key milestones for site editing was also created. For each major milestone, there are related issues for each milestone that are recommended to follow if you want a more granular look at each next step (example from Site Editor Navigation).

As a reminder, if you’re interested in being a part of testing Full Site Editing, check out the experimental outreach program to learn more

Navigation Screen

Similar to the Widget Screen, efforts have begun to launch this new screen to the world in order to gather more feedback. Right now, this effort has a few blockers but, if you’re able to, testing this screen and reporting feedback would be a huge help (Install Gutenberg and head to Gutenberg > Experiments to enable this screen). The aim is that this new screen will help expand what’s possible with menus while bringing block functionality to yet another part of WordPress in order to allow for more adoption and to offer a more modern experience.  

Follow along:

You can follow the progress of this project on this project board, review the overview issues (Block Navigation, Navigation Screen) & join the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat.

Areas to be aware of:

Block & PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Developers

Since the block directory is still a new feature in the WordPress world, the following includes the prior links once more along with two additional issues to chime in on: 

Theme Developers

Review the latest Gutenberg Themes roundup and, in particular, check out @tomjin’s PHP theme template compatibility proposal as it relates to Full Site Editing. Please chime in with your thoughts! Outside of this proposal, here are two other items that might be of interest:  

Ways to Get Involved:

While the above items are our focuses, don’t forget that you can always help with triage, needs testing issues, good first issues and reviewing PRs. Focusing efforts around Widgets and Navigation in particular this month would be very helpful as both screens are on their way to no longer being experimental features. 

If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

Meetings to join:

While you can view all meetings here, here are specific meetings that touch on Gutenberg development to join depending on your interest and availability. Remember that you need a WordPress.org slack account to participate: 

  • Core Editor weekly meeting on Wednesdays @ 14:00 UTC in #core-editor focused on all things Gutenberg. 
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) weekly meeting on Fridays @ 15:00 UTC in #accessibility focused on wrangling accessibility related work across Core and the block based editor.
  • Navigation Sync weekly meeting on Wednesdays @ 07:00 UTC in #core focused on triaging and discussing Navigation screen work. 
  • Block Based Themes meeting twice monthly on Wednesday @ 16:00 UTC in #themereview focused on preparing for Full Site Editing. 

#core-editor #gutenberg-next

Dev Chat Summary: (5.6 Week 3)

This post summarizes this week’s meetings happening on Wednesday, September 2, 2020, 07:00 AM GMT+2 and Wednesday, September 2, 2020, 10:00 PM GMT+2 on the agenda.

0500 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. devchat

0500 Full meeting transcript on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.: https://wordpress.slack.com/archives/C02RQBWTW/p1599022834165200

@thewebprincess facilitated the meeting and took notes.

2000 core devchat

The meeting was facilitated by @thewebprincess while @thelmachido took notes. Full meeting transcript on slack

Both groups followed the pre-prepared agenda and started the chat by acknowledging the adjustment to the new timing of the chat having moved it a day earlier.

Announcements

The group was excited about the release of version 5.5.1. @audrasjb thanked everyone who contributed to the release, specifically @winstina and @hauwaabashiya who hosted their first release parties.

Highlighted blogblog (versus network, site) posts

  • The discussion then turned to how best to accommodate Daylight Savings time changes – whether to shift the meeting or keep it at the UTC times which means time changes for participants.
    “ … how do we adjust for daylight savings?” see  @thewebprincess post. In recent years, the switch was made after all countries shifted to DST. What’s being proposed is that we switch that in favour of consistency with UTC. There’s a loosely described process on the matter in the handbook Daylight Saving Time (DST), however, given the more diverse geography attending dev chat, it may be time to reassess the process.
    We need to decide and document it in time for the first change due to take place on September 27 when NZ adjusts their clocks. The group agreed that the decision will be made next week in the meantime if you have something to add to help inform that decision, please leave comments on the post.

Then in the open time, two issues were discussed.

  • Then this issue https://make.wordpress.org/core/2020/06/29/updating-jquery-version-shipped-with-wordpress/ was raised by @markparnell, asking the question ” what’s the feeling about this given the volume of jQuery issues after 5.5? are we ready to take the next step, or should we take things a little more slowly?” After some discussion, the conclusion was made that it’s too early yet for a decision and that timing of that point would be best before the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. release (@pwcc) so the group will revisit in a couple of weeks. View slack archive.
    Afterwards, @timothyblynjacobs made a comment on the ticketticket Created for both bug reports and feature development on the bug tracker. “If we upgrade to jQuery 3.0 do we anticipate using any jQuery 3.0 features? Or if WordPress Core won’t be reliant on jQuery Migrate, … follow the conversation on Update jQuery step two ticket.
  • Awareness was raised on  Writing Developer Notes handbook for all contributors interested in writing dev-notes for future releases. Also, view the handbook on Leading Bug Scrubs that was based off a post during version 4.7 it was published recently.

Component maintainers

There is nothing of note from Build/Test Tools this week, but if anyone is interested in helping out with adding end to end / functional tests to the core then check out the post from a couple of weeks ago by @francina.

The Site Health team is assessing focuses for version 5.6 in their meeting next week.

@whyisjake – “While the release team is wrapping up the 5.5 processes, they want to reach out to the wider community for perspectives on the process and what could be done in the future to make releases smoother for everyone. Comments can be publicly shared directly on the post that is to come later, or as part of this form. All responses will be catalogued and then shared.”

Closing Remarks 

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 8.9 was released yesterday by @jorgefilipecosta! Of note, the new widgets screen was moved out of experimental. There will be more to come in the “What’s New” post for the release. A call for testing will be published on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ after some design changes are done.

@sergey This is for anyone working on unit tests in core, stricter type checking by using assertSame() should generally be preferred now to assertEquals() where appropriate, to make the tests more reliable. This is helpful in the ongoing work on PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 8 support. See ticket for more details.

Next Dev Chat meetings

The next meetings will take place on Wednesday, September 9, 2020, 07:00 AM GMT+2 and Wednesday, September 2, 2020, 10:00 PM GMT+2 in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account. 

#5-5, #5-5-1, #5-6, #core, #dev-chat, #summary

Bug Scrub Schedule for 5.6

With 5.6 officially kicked off, time to schedule the 5.6 sessions. These 5.6 specific ticketticket Created for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.

Upcoming Scrubs:

Check this schedule often, as it will change to reflect the latest information.

Past Scrubs:

What about recurring component scrubs and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?

The above 5.6 scheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs are separate and in addition.

For your reference, here are some of the recurring sessions:

  • Design Triage: Every Tuesday 14:00 UTC in the #design channel (for both coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/).
  • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Scrub: Every Friday 14:00 UTC in the #accessibility channel.
  • APAC-friendly Scrub: Every Tuesday at 05:00 UTC in the #core channel. This scrub will continue during the cycle, alternating focus between core and editor.
  • Testing Scrub: Every Friday 13:30 UTC in the #core channel.

Want to lead a bug scrub?

Did you know that anyone can lead a bug scrub at anytime? Yes, you can!

How? PingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me (@hellofromtonya) on slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and let me know the day and time you’re considering as well as the report or tickets you want to scrub.

Planning one that’s 5.6-focused? Awesome! We’ll add it to the schedule here along with your name. You’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

Where can you find tickets to scrub? All open tickets for 5.6, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

Need a refresher on bug scrubs? Checkout Leading Bug Scrubs in the core handbook.

Questions?

Have a question, concern, or suggestion? Want to lead a bug scrub? Please leave a comment or reach out directly to me (@hellofromtonya) on slack.

#5-6, #bug-scrub

#core

Dev Chat Summary: August 26 (5.6 Week 2)

This post summarizes the dev chat meeting from August 26th facilitated by @thewebprincess on this agenda.

Full meeting transcript on slack

General Announcements

See @audrasjb post for details on the scheduled maintenance release for WordPress 5.5.1 after a handful of bugs were identified on WordPress 5.5 “Eckstine”. The first Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). is planned to be on Thursday, August 27, 2020, and the Final release planned to be on Tuesday, September 1st, 2020 estimated time 20:00–21:00 UTC or later depending on work to be done on the remaining tickets.

Highlighted blogblog (versus network, site) posts

Components check-in and status updates

The first CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSSCSS Cascading Style Sheets. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. is being hosted today at 4pm EDT in the #core-css channel. One hour before the weekly Core CSS chat.  

@carikee flagged milestone tickets for privacy initiatives that still open and need to be looked at #51092, #51110 & 51144.

There is nothing of note from the Build/Test Tools component at the moment other than the before mentioned post about PHP updates.

Open Floor

The meeting pivoted into a 5.5.1 pre-RC scrub run

Ticketticket Created for both bug reports and feature development on the bug tracker. #50910 has had some testing but could use some more tests.  It is hopefully going to land for 5.5.1-RC1, so the more eyes the better similarly for #51129.  

@carikee asked committers for their input on whether to use the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. to expose user consent on the front-end. Also, the need to add the extra 10KB or so to expose wp.data to the front end.

@audrasjb flagged  5.5.1 milestones that need to be cleared and @pbiron also flagged 5.5.1 tickets that are still open.  

The meeting continued as a 5.5.1 pre-RC scrub run by @desrosj.

Next Dev Chat meeting 

The next meeting will take place on Wednesday, September 3, 2020, 10:00 PM GMT+2 in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account. 

#5-5, #5-5-1, #5-6, #core, #summary

Proposal: Dropping support for old PHP versions via a fixed schedule

While most people here will probably mostly know me as a (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme builders, the web agencies and the users who often run their business via their WordPress website.

In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.

A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.

With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.

Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.

Chicken vs egg

The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.

Current situation: Classic Chicken vs Egg


WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.

This is circular logic, which as most developers know, never ends well as you end up in an infinite loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. where, in the end, neither moves forward.

So who are these users who don’t upgrade ?

Well, while we can’t know for sure, if we look at the figures, we can see some patterns:

Pie chart with the statistics for which version of WordPress is used by which percentage of users.
In the chart it is highlighted that there are 3.7% of users still on WP 5.1 (PHP stragglers), a whopping 10.6%on WP 4.9 (Gutenberg dislikers) and a similar percentage of users on WP versions older than WP 4.9, a  lot of which may be zombie-sites.

Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.

So let’s look at some likely personas for users who don’t upgrade:

Image showing four persona's:
1. The zombie thinking "Huh, what notice ? what website ?"
2. The overwhelmed person thinking "Admin notices are so noisy, I just ignore them all".
3. The laid-back person thinking "No rush, I'll do it later (when it's needed)".
4. The business person thinking "We'll take the costs last minute and not a minute before".

We have the “zombie” persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without adminadmin (and super admin) involvement, or spam sites etc.

We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.

Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.

And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.

As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out.
For those users, I like to use the car analogy:

A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.

Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).

Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hackedhacked /can’t upgrade anymore). If was your responsibility as a user to act on them after all.

But Juliette, get to the point: how do you think we can get out of this situation ?

Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.

A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.

These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.

The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.

So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.

That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.

Timeline from December 2016 to December 2024 showing the WordPress version released that December and the minimum supported PHP version as of that WordPress version.
WordPress 5.6 in December 2020 would get a minimum of PHP 7.1.
WordPress 5.9 in December 2021 would get a minimum of PHP 7.2, etc
Below the timeline it shows for each PHP version when it was released and until when it will be supported by WordPress.

Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.

For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.

But all those users on old WordPress versions…

Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. security fixes for WordPress versions up to four years back.

Timeline from December 2016 to December 2024 showing that during the lifetime of the upcoming WordPress 5.6 release, the 5.6 release would get active support, but that WordPress 4.7 (released December 2016) up to WordPress 5.5 (released this month) would get security releases (if needed).

What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.

Slide: Example: user on PHP 7.4
* WordPress will offer 5 years of support for the PHP version.
* WordPress will offer 4 more years of security updates for WP versions before the version bump dropping PHP 7.4.
* In total this adds up to 9 years of support.

And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.

Now how does that sound ? Is that a liberal enough policy ?

Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.

But what about the users currently on old WordPress versions ?

To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.

Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.

Slide showing an "Urgency nudges" proposal:
* For websites running on a PHP versions no longer actively supported, an admin notice will be shown.
* As of six months before the planned drop of a PHP version, the admin notice on those sites would change colour to draw more attention to it.
* After the PHP version drop, the proposal is to show a big pop-up on admin login for the first and second year after. The notice is dismissable but will come back once a month.
* For the third and fourth year after support for the PHP version has been dropped, this pop-up will show every time an admin logs into the website.

So… what do you think ? I eagerly await the reactions of you all!

Props to @sergeybiryukov, @joostdevalk and @matt for looking this article over before publication.

#core, #core-php, #php, #request-for-comment

Navigation sync notes

Today, 22nd July 2020, in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel the weekly navigation sync meeting was held. This is a CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. meeting about everything Navigation: the navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and the navigation screen.

The agenda for today was:

  • Navigation screen project triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.
  • Open floor

We triaged all the issues in the Inbox column of the Navigation screen project.

During the open floor the following items were raised:

  • @andraganescu highlighted the Navigation: Non-link blocks should be wrapped in a
  • issue
    • We discussed the idea of adding a ClassicMenu block to enable the Navigation block to manage blocks and classic menus easier in the Navigation screen.
    • @ashiishme offered to create an issue for a new ClassicMenu block
  • It was discussed that during this chat we should also triage issues labeled [Block] Navigation that were opened in the last week, to check for items to add to the Navigation screen project.

Lastly, if you want to get involved in any way – design, code, bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub, testing – check out:

Thanks!

#meeting-notes

What’s next in Gutenberg? (July)

This is a monthly update containing the high-level items that GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ contributors are focusing on for July. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project. 

Preparing for WordPress 5.5

On July 6th, Gutenberg 8.5 RC is planned to be released! This is the last Gutenberg release going into WordPress 5.5 and is the major focus for this month so 5.5 can be set up for success. Keep in mind that this means that all features and enhancements that need to go into WordPress 5.5 must be ready for this upcoming release. After the 8.5 release, ideally only fixes for regressions or fixes for bugs in new features will be added in. You can read the latest news about what editor features are planned for inclusion in 5.5 here.

Follow along:

You can follow the progress for this effort on this project board.

Full Site Editing

Work on this major focus for phase 2 is ongoing and is expected to continue iterating over the next months. We’ve wrapped up the major work needed to build the technical foundation of this project and are now moving towards expanding the UX & UI:

  • Refining and pruning block patterns.
  • Refining the navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and navigation screen.
  • Building out flows for new template creation.
  • Improving the flow for inserting new or selecting existing template parts, currently being explored as “sections” in the block editor. The exact naming is being discussed further here.

We’re watching the Theme Experiments repo as well to see how themers are attempting to build block-based themes. Thank you to everyone participating there as it’s a super useful way for us to determine prioritization. 

Follow along:

The high level, important tasks have been split into sections and highlighted on this overview issue. If you’re interested in being a part of testing Full Site Editing, check out the experimental outreach program to learn more

Navigation Screen

As @andraganescu mentioned here, those who have been working on a new, block-based, menus page (nav-menus.php) in wp-adminadmin (and super admin) are starting a new weekly chat in #core to begin better syncing up efforts. The meeting will happen in #core every Wednesday, July 8, 2020, 01:00 AM MDT, starting next week, on July 8th. These meetings will be focused on triaging issues in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ with the  [Feature] Navigation screen or [Block] Navigation labels but are also open for discussing improving the navigation creation process in WordPress, increasing compatibility with Full Site Editing, and maintaining backward compatibility.

To help get everyone thinking more about navigation, check out the following related issues that are currently being explored:

Follow along:

You can follow the progress of this project on this project board, review the overview issues (Block Navigation, Navigation Screen), and join the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat.

Miscellaneous Focuses

Because preparing for 5.5 is such an important piece of this month to get right, the items below are still focuses but are more minor than they have been these last few months. Once work for 5.5 is in a solid place, it’s expected that greater attention will return to these areas:

Global Styles

As a reminder, Global Styles refers to the system that defines and manages global aesthetics allowing overall site styles, theme styles, and blocks to work well together. You can follow the progress for this overall system in this overview issue. For more recent and immediate next steps, you can follow this issue describing the current state of work. 

WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Screen

As part of expanding the block editor to other screens in the admin, work slowly but surely continues to improve the widget screen. You can follow the progress of this focus by reviewing issues with the [Feature] Widgets label.

Areas to be aware of:

Block & PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Developers

There is a new block creation tutorial done by @mkaz in light of the block directory’s experimental status being removed. Expect new block guidelines, more documentation, and a  block validator tool coming your way this month. For now, anything that can be done to test the block directory and give feedback would be greatly appreciated to make this a success. 

Theme Developers

Last week, an awesome Q&A from the Gutenberg Times (hat tip @bph) was done on block-based themes featuring @itsjusteileen @kjellr. You can see some pretty neat demos in there including the theme export button. If you’re curious about or working on block based themes, check out the recorded discussion.

Ways to Help:

While the above items are our focuses, don’t forget that you can always help with triage, needs testing issues, good first issues and reviewing PRs. If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.

#core-editor #gutenberg-next

Editor features for WordPress 5.5 – update

As a continuation of the previous post outlining the WordPress 5.5 Editor features, here’s an update on which of those features will be in 5.5, and which will not. In the previous post, there were two “sets” of features. The first was “definite for inclusion,” and the second was “features that need help.”

Currently the release includes the following list of new additions and improvements to the editor:

  • A new blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor design.
  • Introducing block patterns and the block patterns APIs for themes and plugins.
  • A new block inserter panel with streamlined categories, collections, native support for patterns, and block directory integration.
  • An improved editing experience, with refined drag and drop, block movers, parent block selection, device previews, contextual focus highlights, multi-select formatting allowing changes to many blocks at once, ability to copy and relocate blocks easily, and better performance.
  • An expanding set of design tools with inline image editing, theme support for link color, multiple alignment options and customizable padding in cover block, mobile support for auto-playing videos, extended background and gradient support to other blocks (group, columns, media & text), broader unit control beyond pixels (rems, %, vh, vw), line height adjustments, and more.
  • Over 1500 additional changes to the editor experience.

That is an impressive list! It also includes most of the items that needed help: block patterns, block directory and block design tools. Keep an eye on this blogblog (versus network, site) in the coming weeks for dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. detailing each feature listed above.

Thank you to every contributor that took the time to push these features over the finish line! 🎉

However, even though lots of work went into these features and considerable progress was made, there are some features previously planned for 5.5 that could not be included:

  • The navigation block
  • The new navigation screen
  • The new widgets screen

To monitor progress and participate there are a few places to start:

  • Navigation and the navigation screen issues are tracked in the Navigation project within the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository. There are also issues not tracked in the project but labeled accordingly.

To test the current status of these projects, remember to turn them on within the Gutenberg plugin experiments screen.

Thank you for your support, contributions, and all other kinds of participation in this amazing new incoming WordPress release!


Update July 15th 2020 – removed the “theme support for link color” feature as per this comment

#5-5