Editor chat summary: Wednesday, 4 November 2020

This post summarizes the latest weekly Editor meeting (agenda, slack transcript), held in the #core-editor 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, on Wednesday, November 4, 2020, 14:00 UTC.

Thank you to all of the contributors who tested 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. releases and gave feedback. Testing for bugs is a critical part of polishing every release and a great way to contribute to WordPress.

WordPress 5.6 Beta 3

WordPress 5.6 Beta 3 is now available to be tested. Released on 2nd novemebr.

WordPress 5.6

Project board to track issues for inclusion in WordPress 5.6.

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/ 9.3

Gutenberg 9.3 was released on 4th november

Monthly Plan

November Monthly Priorities.

Updates on the key projects

@youknowriad

  • The pace is increasing on the Full Site Editing related work, now FSE themes don’t need the experimental flag to work properly. A warning message about the experimental state is shown in the adminadmin (and super admin).
  • I expect some of us to focus more on template parts and templates auto-draft behavior (how to load theme templates and templates parts in the site editor).
  • I believe other folks are also working on the UIUI User interface and 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..

@vindl

Full Site Editing – Navigation milestone update:

  • The PR for detaching blocks from Template Parts shipped.
  • Bunch of fixes and tweaks for some minor issues related to the navigation 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. and template parts.
  • PR for adding incorporating search for templates and template parts is now open
  • Here is an attempt to create wp_templates entries on theme updates instead of on each 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. request
  • We started a new and simplified version of framework PR for introducing a custom status for templates provided by themes (or plugins) as HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. files, which haven’t been customized by the user yet

@ntsekouras
FSE: Query block

@jorgefilipecosta

Global Styles:

  • We now support other units and fluid typography on font size presets.
  • We now use the block settings on each global styles panel.
  • We now reference the preset variables on global styles so if for example global background color is set set to color X, and later we change color X, the background color also changes.
  • The UI is improved and we don’t show block panels without content.
  • We should have font family picker in the next few minutes (just finishing a last round of tests)

@nosolosw

  • For Global Styles the current focus is on tighten up things and fixing the flows, specially by testing what we have with the TwentyTwentyOne blocks theme.

Task Coordination

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

@zieladam

Took a deep dive in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. data:

  • Propose an update to useSelect to address every key stroke in the editor re-running all registered selectors.
  • Merged two fixes related to saveEntityRecord ending up with outdated state.
  • Proposed lock mechanism for core-data to ultimately fix all the timing issues.
  • I am also playing with taking screenshots of all e2e failures on 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/ CI.

@youknowriad

  • I’m focusing on FSE efforts as raised above
  • I’m also thinking about 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. for the APIs introduced on WP 5.6 and hoping to find time to write these next week.  I believe we should start publishing some of the block editor dev notes.

@karmatosed

  • Navigation drop down improvements.
  • Link iterations again this one grew from improvments to link UI.
  • I’m trying to do some PR trashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. pickups as go and level up my skills there, thank you to everyone that has supported me (special calls to @itsjonq and @joen) Also continuing to work on options and going to post some flow updates to that this week.
  • Release continues, so I’m also navigation around that.

@annezazu

  • Quieter week for me, Working with others on communication for 5.6.
  • some light triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. for unlabeled items, and some quick FSE focused testing.
  • Excited to take 9.3 for a spin!

@ntsekouras

  •  Query block: Expose initial templates as block variations.
  • Fix double alignment controls in toolbar of Heading block.
  • Allow editing of extracted excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. in Post Excerpt block

@itsjonq

@paaljoachim

@retrofox

@bph

  • Thanks to  @afragen I am  almost ready for Gutenberg-Nightly version for non-dev testers.

@jorgefilipecosta

  • Iterated and merged support for other units and fluid typography on font size presets.
  • Iterated and merged PR to use the block settings on each global styles panel.
  • Iterated and merged PR to reference the preset variables on global styles so if for example global background color is set set to color X, and later we change color X, the background color also changes.
  • Submitted and merged PR to don’t show block panels without conten
  • Rebased and Iterated on font family picker in the next few minutes (just finishing a last round of tests).
  • Reviewed multiple PR including the moment removal PR.
  • Submitted multiple small fixes/enhancements to Global styles

For the next week, I plan on testing 2021 blocks deeply with global styles and submit fixes either for the theme or to Gutenberg. I plan to continue the typography work with font weight and  recheck a possible font loading global styles API.

@kjellr

  • I’ll be focused on Twenty Twenty-One Blocks.

Open Floor

@tomjn

  • Asked what’s the best way to register block for particular post type.
  • Current option is to 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. through blocks and unregister undesored blocks for the posttype.
  • Some discussion around defining posttype via block.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. but no decision.

@meszarosrob

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

WP5.6 | Auto-Update Implementation Change

Hey Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.! Last week in 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/. there was a lively (and lengthy) discussion on the auto-updates UIUI User interface (transcript). This post summarizes the discussion and most reasonable options for moving forward, considering timing, availability, and level of effort for suggested changes.

Summarized Concerns

  • Is this implementation aligned with our long term goals: to have auto-updates widely available in order to increase the collective health of all WordPress sites, minimize the maintenance burden for users, and have greater security across the entire ecosystem.
  • Is this implementation aligned with our short term goals: to continue our existing progress around auto-updates for minor releases, plugins, and themes.
  • A desire to avoid reverting elements of the UI and auto-updates after the release.
  • There were a vast array of concerns around the implementation.

Path Forward

One of the clearest things that came up in the conversation during coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. chat is that this is a complex technical task, and there will be a need for some long term, dedicated time to keep driving this work forward. Specifically, there is a shared concern that there is a technically non-trivial combination of reassurance and repair features that need to be defined and executed on and will need a dedicated product owner (transcript).

This Release and Next

  • WP5.6: Provide some updates to the design of the UI.
  • WP5.6: For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).
  • WP5.6: For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.
  • WP5.6.1: Revisit the UI to revise based on feedback.
  • WP5.7Add a nudge on the Site Health screen for anyone opted out of major updates.
  • WP5.7Add auto-updates opt-in to installation flow.

Future Release Suggestions

  1. WP5.x: Add a nudge to opt-in on the updates page and a path to opt-out on Site Health.
  2. WP5.x: In a future release, have a renewal flow after a certain period of time.

Planning for the Future

The subject of auto-updates has resulted in many complicated discussions. As I reminded the release squad, decisions like these require us to remember that we’re contributing to over 30% of the web, and we have to balance our immediate needs with long term planning.

It’s important that whatever we implement isn’t taking us further away from our long term goals of having seamless, auto-updates across the project. Auto-updates can help us have a more secure WordPress ecosystem, and in turn can help change the public perception of WordPress being an unsecure choice for users of any skill level.

To provide some clarification on the nine project goals set out in 2019, the wording there is specific about implementing “opt-in to automatic updates of major Core releases”. However, the long term goal (for Matt as well as many of the contributors to WP3.7) was to have all installations opted-in to auto-updates of WordPress core by default, and that is still the long term goal.

Props to the WordPress 5.6 release squad for bringing such care to this discussion, and to @helen for helping me on the implementation wording. Special thanks to @audrasjb and @davidbaumwald for editing, and @andreamiddleton, @daisyo, and @cbringmann for proofreading!

#5-6, #auto-updates

A Week in Core – November 9, 2020

Three years after the last post published using the #week-in-core tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team Reps @francina and @audrasjb wanted to restore the Week in Core tradition, thanks for @helen reminder that such thing existed. The idea is to provide a general overview on what changed on core from one week to another. So let’s take a look on what changed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between November 2 and November 9, 2020.

  • 35 commits
  • 57 contributors
  • 47 tickets created
  • 6 tickets reopened
  • 79 tickets closed

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers based on the Trac timeline for the period above. The following is a summary of commits, organized by component.

Code changes

About/Help

  • Optimize freedoms sprite and add 2 column layout – #46363

Build/Test Tools

  • Check if all the required PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher extensions are loaded before running the test suite – #50640
  • Disable update attempts while running unit tests – #51670
  • Clean up the new contributor welcome message – #50401
  • Remove PHP >= 5.3 check – #51737
  • Remove duplicate fields key in WP_Query test – #51344

Bundled Themes

  • Sync Twenty Twenty-One with the latest changes from 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/#51526
  • Correct list 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. alignment in editor styles – #51157
  • Twenty Thirteen: Correct alignment of blocks inside a full-width or wide-width group block – #51440
  • Twenty Twenty: Correct heading blocks alignment in editor styles – #51148
  • Twenty Twenty: Correctly indent nested unordered lists in RTL editor styles – #51574

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.

  • Customize: Ensure menu items expand horizontally on large screens – #51647

Documentation

  • Improve return value description for esc_url()#50585
  • Fix typo in a comment in Walker::display_element()#51713.
  • Improve documentation for is_archive()#50545
  • Change the @since entry for template and template_lock post type arguments to 5.0.0#46261
  • Document the $linkdata parameter of wp_insert_link() using hash notation – #50853.
  • General: Make some inline comments more descriptive – #51683
  • Clean up the new contributor welcome message – #50401

Editor

Feeds

  • Don’t treat media URLs with fragments as unique for enclosures – #47421

Formatting

  • Update docs for $context in sanitize_title_with_dashes()#50569

Internationalization

  • Merge duplicate “Column” strings, remove unnecessary context – #47259
  • Unify various “Back to…” vs. “Return to…” vs. “Go to…” strings – #47235

Login and Registration

  • App Passwords: Further 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) improvements – #51580

Media

  • Restore the ability of WP_Image_Editor_Imagick->save() to create a missing directory when needed – #51665
  • Adjust box-sizing for audio players – #51685
  • Adjusts alignment of file name text in browser uploader – #41648

Networks and Sites (Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site)

  • Assign the array of site or networknetwork (versus site, blog) data returned from filters to the respective class property – #51333

Privacy

  • More precise checking of user request action names – #46536

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/.

  • Use _n() in some error messages for proper plural forms support – #51727.

Site Health

  • Validate the test result data format in JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. before using it – #50145.
  • Site errors are for *this* site, not necessarily *your* site – #51524

Upgrade/Install

  • Change the notice displayed after saving auto-update settings to .notice-success#51701
  • Update help tab text to include major WordPress updates – #51653
  • Prevent removal of additional data from 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 update info – #51609

Props

Thanks to everyone who contributed to WordPress Core last week:

@sergeybiryukov (18), @audrasjb (11), @sabernhardt (7), @helen (6), @desrosj (5), @stevenlinx (4), @garrett-eclipse (4), @johnbillion (3), @TimothyBlynJacobs (4), @ryelle (2), @ocean90 (2), @kjellr (2), @ramiy (2), @Clorith (3), @justinahinon (2), @amolv (1), @francina (1), @david.binda (1), @antpb (1), @Lumne (1), @metalandcoffee (1), @peterwilsoncc (1), @techboyg5 (1), @ayeshrajans (1), @poena (1), @luminuu (1), @aristath (1), @felipeelia (1), @jrf (1), @valentinbora (1), @tobifjellner (1), @mikeschroder (1), @noisysocks (1), @ravipatel (1), @alexstine (1), @afercia (1), @archduck (1), @dshanske (1), @joedolson (1), @jeffpaul (1), @eemitch (1), @hellofromTonya (1), @whyisjake (1), @p00ya (1), @kharisblank (1), @yakimun (1), @spacedmonkey (1), @dogwithblog (1), @kraftbj (1) and @joostdevalk (1).

Core committers: @sergeybiryukov, @helen, @desrosj, @noisysocks, @antpb, @TimothyBlynJacobs and @johnbillion.

Dev Chat Summary – 28 October 2020

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 celebrating the release of WordPress 5.6 Beta 2, please test and review 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. version and share any bugs/issues.

Announcements

WP Version 5.5.2 is scheduled for release on October 29th

Highlighted Posts

@helen is running code review/commit office hours for 5.6, you can get more information about it here.

@chanthaboune outlined the rationale behind dropping the Widgets screen from 5.6 catch up on that and the plan going forward here.

Dark Mode for Twenty Twenty-One
Discussions are ongoing and the team has outlined some options that your input could help narrow down.

Calls for maintainers and focus leads

PHP 8 call for testing
@sergeybiryukov highlighted again that there is need for more testing on PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8, we have to expand test coverage and creat tickets for any issues found. A thorough report has been written by @omarreiss, @jrff, and @herregroen about the current state of PHP 8 and its compatibility with WP.

Build/Test Tools
Docker environment was updated to allow for using multiple PHP Unit versions, get more details on that here. (Note: this is currently temporarily reverted to investigate test failures) Also, some changes were made to account for the recently released Composer 2.0.

Upgrade/Install Component Update
@audrasjb is drafting on a dev notedev 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. for #50907. It should be ready for review by the Docs lead/cohort/mentor.

Open Floor

Take part in the 2020 WP English Survey, if you are interested to see 2019 survey results, or get links to the 2020 survey in French, German, Japanese, Russian, or Spanish, you can find all that here!

Block Pattern Directory Ideas and Discussion
@daisyo surfaced the post for feedback.

@audrasjb is working on a technical proposal for dropping support/security backports for very old versions of WordPress. He is going to publish a Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post and open a ticketticket Created for both bug reports and feature development on the bug tracker. with a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. proposal very soon. The topic should be ready for discussion during the next dev chat. Comments are welcome here. Follow the conversation on slack

Join the team for the next bug scrub on Friday

WP 5.6 Beta 3 is Scheduled for next Monday.

Next Dev Chat meetings

The next meetings will take place on Wednesday, November 4, 2020, 07:00 AM GMT+2 and Wednesday, November 4, 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, #core, #dev-chat, #summary

Dev Chat Agenda: October 28th 2020:

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

  • Announcements –
    • 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. 2 of 5.6 released – please test and review and bring any issues/bugs to chat to discuss
    • WP 5.5.2 minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. planned for Thursday, 29 October 2020 1700UTC details here
  • Highlighted blogblog (versus network, site) posts
  • 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, 28 October 2020, 05:00UTC and Wednesday, 28 October 2020, 2000UTC. These meetings are held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack .

#5-6, #agenda

Widgets Screen Not Shipping in 5.6

The Widgets Screen project was pencilled in for 5.6, but as of 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, work on its major features was not complete, so Release LeadRelease Lead The community member ultimately responsible for the Release. @chanthaboune, CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Lead @helen, Editor Tech Lead @isabel_brison and some of the contributors working actively on the project — @noisysocks, @talldan and @kevin940726 — decided to exclude it from 5.6. Thank you to everyone who tested and gave feedback as it helped inform this decision! 

The Reasoning

Making the Customizer work with the block editor is a challenging process, and one that needs  substantial and thoughtful work to make sure that we deliver the best possible user experience. At the current stage of this project a bulk of that work is done, but more focused testing revealed notable concerns for overall usability (including 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. interactions, some confusions between 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. & legacy widgets, and UXUX User experience disparities between the old and new screens). You can read more in the ticket.

Next Steps

We will continue working on the Widgets screen, and will keep the new screen as the default option when using the 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/ 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 to encourage more feedback.  At the top of the year, we’ll explore where this fits in the larger roadmap for future releases. For those looking to get involved until then, check out the options below: 

  • It’s been tentatively added to the WP5.7 milestone, with an early tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) so that it comes up in scrubs as quickly as possible.
  • If you’re interested in following the status of the project, you can find the top priority issues and current focuses on the Widgets Editor project board in GitHub
  • If you can help with development, we encourage you to attend or review the weekly triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions in the #core Slack channel on Wednesdays at 7am UTC.
  • If you can help with testing, please feel free to leave comments on the Call for Testing for us to review or to open issues directly in GitHub. In particular, we’d love to hear from plugin and theme authors. 

Thanks in advance for everyone’s help making sure that this key element is a success!

#5-6, #5-7

Discussion: How best to gather Component/Focus Updates as we head towards release

The Challenge

One interesting challenge in the leadership and coordination of the release process is getting a clear and comprehensive understanding of the landscape of the release. The squad have some mechanisms in place to help reveal that landscape, devchat being one of the main cogs in that mechanism. In past release cycles, there have been other initiatives to try and make that landscape ‘higher resolution.’

In order to feel confident that the release is moving forward according to plan, it’s important for the release leads and wider release cohort to understand the progress with components and focus areas of the 5.6 release whether or not there are any areas that are under supported and need assistance, and what, if anything is going to threaten the timeline and/or scope of that release.

In order to do this, the squad relies on regular and timely updates from component maintainers, focus leads, and feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. leads as the cohort moves towards the release date. So far, we have resorted to pinging @maintainers during devchat, and while that does occasionally elicit a response, it can be intrusive, especially if that component is not currently active, or if there’s no significant development happening for that component in relation to the release. There is also a chance that important information is missed if someone doesn’t respond to the 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.”

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. problem is, how do we make sure we receive important updates from  components and focus teams without creating an environment where the release squad is required to ping regularly and ask for updates? What kind of system can we implement that will work for the release squad and component maintainers?

Possible Solutions

Different release co-ordinators/leads have used different approaches such as pinging in devchat, or messaging 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/. groups to ask for updates. There have been other options proposed at various times, like async reporting on weekly agenda posts, or a dedicated ‘check in post’ such as is used in the community team, or even a dedicated slack channel for component maintainers.

Each option has its pros and cons. So this post has been created to actually ask the component maintainers and focus squads what makes the most sense to them?

Share your thoughts!

This post invites discussion on how to explore ways that best encourage proactive sharing of progress/blockers so that the release team and other interested cohort members can be empowered to resolve issues, and be confident in the progress towards the goal. 

Questions:

  • If you are a component maintainer, what kind of process would you like to follow that would enable you to share regular updates?
  • If you are a part of the release cohort, how would you like to receive that information? 
  • Do you have any other thoughts or suggestions on how we can improve the flow information generally, without overwhelming a channel full of contributors, or even individual contributors?

Please share your thoughts in the comments below by Wednesday September 30th 05:00 UTC.

Props to @angelasjin, @cbringmann, and @audrasjb for editing support.

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 or higher) 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

Dev Chat Summary, August 12th, 2020

@whyisjake hosted this agenda and @marybaum edited.

Component check-in and status updates

  • End-to-end testing
    • @whyisjake opened the chat by sharing @francina‘s post on E2E testing. She’s looking for feedback and would like to see more of that testing in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

  • 5.5 has landed! The release happened yesterday, on August 11, 2020.
    • @whyisjake thanked 800-plus contributors that made it, in his view, the greatest release of WordPress ever
  • Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. discussed 5.5 focal points and areas for improvement
    • @whyisjake and @marybaum addressed the enduring struggle to sync the about.php page with translators, when the squad often doesn’t get late-breaking info around the jazzer until the very last minute.
    • @audrasjb and @desrosj discussed a 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. with the placeholder video and inline image editing tools
    • @whyisjake began a lively conversation on the impact jQuery Migrate had on 5.5 planning with @jorbin, @ipstenu, @corinth, and @johnbillion. @Helen expressed a desire for clear messaging and more developer outreach on the topic, @jorbin noted that the marketing lead for future releases could increase awareness, and @marybaum, @webcommsat, and @annezazu discussed existing and planned marketing efforts.

Upcoming Releases

  • 5.5.1 release
    • @davidbaumwald offered to lead the minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.. @audrasjb, @johnbillion, @desrosj, @sergeybiryukov, @whyisjake, @azhiyadev, and @planningwrite and several others will join him. If you are interested in being part of the 5.5.1 release team, please note your interest in this post.
  • 5.6 release kickoff meeting will be August 19th during dev chat.

Open Floor

The next Core dev chat will be on Wednesday August 19, 2020 at 20:00 UTC

These meetings are held in the #core channel in the Making WordPress Core Slack instance.

Props to @audrasjb for review.

#5-5, #dev-chat

WordPress 5.6 Release Planning

Kudos to the wonderful group of people who contributed to the successful release of WordPress 5.5 yesterday!  We now turn our focus to the final major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of the year with WordPress 5.6.

Release Squad

As @chanthaboune noted back in March, WordPress 5.6 will feature an all-women release squad with the hope of increasing the number of women who have experience on a release squad and return as contributors to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and elsewhere.  Then in May when the 5.5 release squad was announced it also noted many of the 5.6 release squad members who would shadow the 5.5 team and learn the release process.  With @chanthaboune on sabbatical until 21 September 2020, I have the pleasure of sharing the 5.6 release leads and the various cohort groups who will be supporting those leads, as well as the release scope and schedule for 5.6.

Release Scope

The following are the remaining goals for the year that are targeted as part of WordPress 5.6.

  • Complete: Convert the widgets-editing areas complete.
  • Complete: Remove support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.6.x.
  • Ship: Navigation menus 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 screen in Core.
  • Ship: Automatic updates for major WordPress Core releases (opt-in).
  • Ship: New features from the block editor upgrades.
  • Ship: Widgets-editing and 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. support in Core.
  • Ship: Default theme, including an FSE compatible version.
  • Ship: PHP 8 support.
  • Ship: Public 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. of Full Site Editing.

Release Schedule

The schedule from today, 12 August 2020, until the WordPress 5.6 release can be found on the 5.6 development cycle page.  In summary, some key milestones for the release are:

  • Kickoff: 19 August 2020
  • Beta 1: 20 October 2020 (~9 weeks from kickoff)
  • 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). 1: 17 November 2020 (4 weeks from Beta 1)
  • General Release: 8 December 2020 (3 weeks from Release Candidate 1)

If you want to dive deeper into 5.6, development is discussed at a weekly meeting 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 and occurs next at Wednesday at 20:00 UTC. Wish us luck!

This post was compiled with the help of @jeffpaul and reviewed for clarity and accuracy by @cbringmann.  Props to @cbringmann, @angelasjin, @francina, and @desrosj for helping assemble this fantastic release squad and to @chanthaboune for the inspiration to lead the project in this direction!

#5-6, #planning