The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in our bug tracker.
We use Slack for real-time communication. Contributors live all over the world, so there are discussions happening at all hours of the day.
Our core development meetings are every Wednesday at 05:00 UTC and 20:00 UTC in the #core channel on Slack. Anyone can join and participate or listen in!
This is a monthly update containing the high-level items that GutenbergGutenbergThe 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.
5.6 BetaBetaA 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 CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. before Beta 1.
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.jsonJSONJSON, 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 blockBlockBlock 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 sidebarSidebarA 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 UIUIUser 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.
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.
WidgetWidgetA 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
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 customizerCustomizerTool 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.
Ensuring only superadmins can store HTML using the new APIAPIAn 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 a11yAccessibilityAccessibility (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 GitHubGitHubGitHub 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:
Group document settings in the headerHeaderThe 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..
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).
Block & PluginPluginA 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.
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.
Please share any items you’d like to include in the comments below.
Announcements
Highlighted blogblog(versus network, site) posts
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?
What’s next in Gutenberg (September): Comprehensive post about where things are at with the coreCoreCore 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 pluginPluginA 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.
This is a monthly update containing the high-level items that GutenbergGutenbergThe 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.
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:
Providing support for enabling/disabling custom gradients using theme.jsonJSONJSON, 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..
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.
WidgetWidgetA 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:
Ensuring only superadmins can store HTML using the new APIAPIAn 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 a11yAccessibilityAccessibility (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 proper labelling, improved navigation tool, and more.
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 headerHeaderThe 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 sidebarSidebarA 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..
Begin exploring missing functionality for the query blockBlockBlock 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).
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.
You can follow the progress of this project on this project board, review the overview issues (Block Navigation, Navigation Screen) & join the weekly coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. chat.
Areas to be aware of:
Block & PluginPluginA 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:
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.
AccessibilityAccessibilityAccessibility (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.
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.
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 @thewebprincesspost. 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 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 betaBetaA 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 ticketticketCreated 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
GutenbergGutenbergThe 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.orgThe 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 PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 8 support. See ticket for more details.
With 5.6 officially kicked off, time to schedule the 5.6 sessions. These 5.6 specific ticketticketCreated for both bug reports and feature development on the bug tracker. scrubs will happen each week until the final release.
Upcoming Scrubs:
10/19/2020 18:00 UTC day before BetaBetaA 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
What about recurring component scrubs and triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions?
The above 5.6 scheduled bugbugA 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 coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenbergThe 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/).
AccessibilityAccessibilityAccessibility (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? PingPingThe 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 slackSlackSlack 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.
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 candidateOne 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.
see @thewebprincess post on the dev chat – APAC Edition Meeting Summary – August 20 2020. “… the group is discussing changing the timing, and also proposed the probability of renaming both chats to equalise their weight a bit more”. There was a suggestion to identify the dev-chats by time using the UTC timezone. However, some from the group pointed out that because of daylight savings it might be confusing and complicated to identify the dev-chats by time. View the discussion here. The discussion is still ongoing. To make a comment/contribution reply to @thewebprincess post.
Components check-in and status updates
The first CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.CSSCSSCascading Style Sheets.triagetriageThe 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
TicketticketCreated 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 APIThe 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.
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 #coreSlackSlackSlack 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.
While most people here will probably mostly know me as a (PHPPHPThe 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 pluginPluginA 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 ?”.
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 loopLoopThe 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:
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:
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.
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 backportbackportA 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.
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.
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.
So… what do you think ? I eagerly await the reactions of you all!
Today, 22nd July 2020, in the #coreSlackSlackSlack 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 CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. meeting about everything Navigation: the navigation blockBlockBlock 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 triagetriageThe 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:
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, bugbugA 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:
This is a monthly update containing the high-level items that GutenbergGutenbergThe 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.
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 the navigation blockBlockBlock 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.
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.
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 GitHubGitHubGitHub 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:
You can follow the progress of this project on this project board, review the overview issues (Block Navigation, Navigation Screen), and join the weekly coreCoreCore 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.
WidgetWidgetA 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 & PluginPluginA 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.
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 blockBlockBlock 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 noteEach 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 GitHubGitHubGitHub 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.
For updates and discussions on the navigation block as well as progress in a FSE (full site editing) context, head over to the #core-editor channel in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Those chats happen on Wednesdays at 14:00 UTC.
Discussion on the state of the new navigation page can be found in #core during the new sync chat on Wednesdays at 7:00 UTC.
