Updating jQuery version shipped with WordPress

This has been a long time coming; the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #37110 is already few years old.

Following the recommendations of the jQuery team, the updating has to happen in stages:

  1. Remove jQuery Migrate 1.x. This is planned for WordPress 5.5.
  2. Update to the latest version of jQuery and add the latest jQuery Migrate. This is tentatively planned for WordPress 5.6 depending on test results. Updating to the latest jQuery UIUI User interface, version 1.12.1, is also planned for 5.6.
  3. Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing.

As planned, a Test jQuery Updates 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 was released to make it easy to test different versions of jQuery, jQuery Migrate, and jQuery UI. Please install it and thoroughly test if everything works as expected, especially on the front-end, or at the settings pages of other WordPress plugins.

How to help with testing

The plugin has a settings screen found under the Plugins menu in WordPress adminadmin (and super admin). Different versions of the jQuery libraries can be selected there for testing. Please test by:

  1. Disabling jQuery Migrate, and leaving jQuery and jQuery UI at the default versions (for WordPress 5.5).
  2. Selecting jQuery 3.5.1, enabling jQuery Migrate, and selecting jQuery UI 1.12.1 (for WordPress 5.6).
Test jQuery Updates settings screen, under the Plugins menu.

Updating your code

To get ready for this jQuery update, it’s important that you update your code. The migrate plugin will assist you in identifying issues. Additionally, the jQuery Core 3.0 Upgrade Guide and 3.5 Upgrade Guide provide detailed information about what has changed. As the browser supported list is also updated, this is also a great time for you to revisit what versions of browsers are supported by your themes and plugins.

See 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.?

If you find a bug in Test jQuery Updates, or if you run into a jQuery related issue, please report it at https://github.com/WordPress/wp-jquery-update-test. If the issue is with a default script in WordPress, please open a new ticket on Trac.

Thanks @andreamiddleton, @annezazu, and @jorbin for helping with this post.

#5-5, #jquery

#dev-notes

WordPress 5.5.1 RC1

WordPress 5.5.1 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 (RC1) is available for you to test!

Here are two ways to test WordPress 5.5.1 RC1:

  • Use the WordPress Beta Tester 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 (select the point 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. nightlies option)
  • Download the release candidate here (zip)

What’s in this release candidate?

5.5.1 Release Candidate 1 features 28 bug fixes and 4 enhancements, as well as 5 bug fixes for the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.

WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. changes on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.:

  • #50882 – Administration: WP 5.5: Cannot attribute content when deleting users
  • #50998 – Quick/Bulk Edit: Editing posts using bottom “Bulk actions” dropdown menu doesn’t work
  • #38009 – Comments: #reply-title.comment-reply-title not updating when replying to an individual
  • #50845 – Editor: Block patterns: Fix translatable strings (take 2)
  • #50858 – Site Health: Check PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 notices with site_status_tests filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
  • #50887 – Site Health: Add site environment to debug information
  • #50892 – Editor: Some block patterns have text contrast issues with dark themes
  • #50910 – Sitemaps: 5.5 Sitemap URLs are incorrectly paginated
  • #50912 – Site Health: flags define WP_AUTO_UPDATE_CORE value as an error
  • #50919 – Script Loader: Change the jquery handle back to an alias for jquery-core
  • #50933 – Media: Lazy loading in 5.5 causes flashing of custom logo in Firefox
  • #50945 – Site Health: don’t give a warning when upload_max_size is lower than max_post_size
  • #50988 – Upgrade/Install: Pass details about the specific plugin and theme updates attempted to filters
  • #50992 – Bootstrap/Load: Remove the ability to alter the list of environment types in wp_get_environment_type()
  • #50999 – Script Loader: Disable concatenation for scripts with translations to ensure they are printed in the right order
  • #51011 – Upgrade/Install: Empty string comparison on home option during DB upgrades is invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid.
  • #51018 – Editor: PHP Notice thrown when searching for certain terms via 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/ block directory
  • #51151 – Editor: Packages update
  • #51021REST 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/.: Permit uniqueItems keyword in endpoint args
  • #51146 – REST API: Fix multi-type schemas with integer fields
  • #51029 – Filesystem 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.: Typo in variable name causes warning from fclose()
  • #51042 – Post: missing 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.
  • #51050 – Docs: Add docblockdocblock (phpdoc, xref, inline docs) for get_the_archive_title() filter
  • #51052 – Administration: Undefined index: update-supported
  • #51060 – Docs: Update register_rest_route docblock to reflect additions since 5.5
  • #51064 – Bootstrap/Load: Consider adding “local” as environment on WP_ENVIRONMENT_TYPE
  • #51073 – Administration: Extra padding below the adminadmin (and super admin) bar
  • #51075 – Docs: Update docs for custom logo functions
  • #51122 – Docs: add a mention about the use of loading attribute in wp_get_attachment_image function
  • #51127UIUI User interface/CSSCSS Cascading Style Sheets.: Remove non-color related styling from Modern color scheme
  • #51129 – Upgrade/Install: Only display the auto-update links on the Networknetwork (versus site, blog) Admin > Themes screen for themes that support the feature
  • #51337 – Template: wp_terms_checklist not checking selected taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. items with selected_cats option

Block editor 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/:

  • PR24609 – Fix missing selected block highlighting in list view
  • PR24599 – Fix specificity for buttons with outline style and background colors
  • PR24533 – Fix incorrect aria description in List View
  • PR24516 – Fix regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. 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. for categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. select in QueryControls component
  • PR24478 – Fix tiny editor preview when using Mobile or Tablet options with metaboxes enabled

What’s next?

The dev-reviewed workflow (double committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. sign-off) is now in effect when making any changes to the 5.5 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..

As per the proposed WordPress 5.5.1 schedule, the final release is expected for Tuesday September 1, 2020 at 18:00 UTC. Please note that this date/time can change depending on possible issues after RC1 is released)

The 5.5.1 release is being lead by @audrasjb, @azhiyadev, @davidbaumwald, @desrosj, @johnbillion, @planningwrite, @sergeybiryukov and @whyisjake.

#5-5, #5-5-1, #minor-releases, #releases

WordPress environment types

In WordPress 5.5 we introduced the new wp_get_environment_type function which allows retrieving the type of environment the current system is. We originally allowed changing the environment types, which we’ve decided is a mistake. It makes it so that plugins and themes can’t rely on any given environment being one of a limited and known list of types, and thus can’t rely on the feature.

For this reason, as of WordPress 5.5.1 it will no longer be possible to override the list of possible environment types.

Which environment types do we have?

The following environment types will be supported as of 5.5.1:

  • production – this is the default. A site that is running live, connected to the internet and reachable on the internet.
  • staging – this is what you would use for staging environments, probably both connected to and reachable on the internet.
  • development – this is what you would use for development environments that are reachable on the internet, we automatically enable WP_DEBUG on environments where this is the environment type.
  • local – added in 5.5.1, this (usually development) environment can reach the internet but is not be reachable from the internet.

By limiting the set of environment types in this way, WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, and themes can change their behavior depending on this setting.

What happens if you changed the setting?

If you’d already set an environment variable to allow changing the environment types, this will no longer function. If you’d set the WP_ENVIRONMENT_TYPE constant to something else than one of the four allowed environment types, it will reset to production.

Props @johnbillion, @audrasjb, and @sergeybiryukov for reviewing.

#5-5-1, #dev-notes

Editor chat summary: 26th August 2020

This post summarizes the weekly editor chat meeting (agenda here) held on 2020-08-26 14:00 UTC in Slack. Moderated by @andraganescu .

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 8.8 has been released

Gutenberg 8.8.0 is now available. Release leadRelease Lead The community member ultimately responsible for the Release. @itsjonq joined us and provided his highlights:

  • forward movement + momentum on some of the bigger projects of Gutenberg, like Widgets, Full site editing, and the Post 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. suite
  • Improved UIUI User interface for 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) and mobile, especially surrounding Toolbar and pop-up like components (like menus and Popovers)
  • there also appears to be a tiny performance improvement compared to 8.7.

@itsjonq ended the overview of this new release by giving huge personal thanks to everyone who helped me before/during the release process to help get 8.8 out.

Monthly Plan & Key Projects

Task Coordination

  • @annezazu
    • I’ve been focused on triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., light testing, and working on this Guide for Devs Working in the WordPress.org Community. Slower moving than I want to be on the guide a bit right now but feedback welcome.
  • @youknowriad
    • I’ve landed some PRs to use allow the usage of _fields  in  core-data improving some of the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. calls performance in the editor.
    • Next couple weeks, I want to make a push on the Block Editor Controlling 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. (part of theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.)
  • @jorgefilipecosta
    •  I reviewed global styles related PR’s. I am working on implementing font family controls on the global styles context.
  • @michael-arestad
    •  I’ve started in on Block Directory work. I’m starting in on updating the current install flow (via block inserter search). I’ve already got some good feedback that I am using to make a new iteration that should be posted in an hour or two. I will also be exploring block management in and out of the editor.
  • @nosolosw
    • I’ve been focused on other tasks the past week. For the next week, I’m continuing work on the global styles sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. at site edit & controlling the block editor.
  • @zieladam
    • Last two weeks I was focused on addressing security issues in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and in the 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, unfortunately I don’t have any links to share.
    • Starting this week I’m back on the widgets editor. After merging the initial version@noisysocks composed a list of all the reported issues that I’m going through and publishing multiple PRs  Also, @mapk is exploring the design of the widget editor. While these explorations are still in progress, I already started prototyping a few suggesstions.
  • @ari
    • I’ve been focusing on exploring FSE and ways to improve it…
      • performance (switch from post-metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. to a taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. for the theme)
      • allowing the use of arbitrary units in columns
      • More styles cleanups for front-facing styles
      • Other minor bugfixes wherever I encounter them
      • Triage
    • Next week I’ll keep working on front-facing styles and start diving deep in global-styles as much as I can
  • @mapk
    • Iterated on WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor designs and Legacy Widget block.
    • Provided some feedback and design work on a text-only toolbar.
    • Trying to triage our 2400+ issues.
  • @itsjonq
    • I’ve continued focusing on the “G2 Components” project.Enough of the foundations have been designed/built, so I’m starting to explore large things like:
      • Prototyping/Building large/complex UI
      • Documentation (to support prototyping/building)
      • Tooling to improve design/dev experience
    • I’ve continued to host Zoom sessions where I collab design/dev things in G2.  I plan on continuing! They’re wonderful .I’m blogging all notable updates here.

Thank you for the work that is happening and does not make it into this list!

Open Floor

  • @desrosj
    • I’m here to flag that 5.5.1 will be released a bit more quickly than usual because of some pesky bugs that were discovered. It would be great if some block editor 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. fixes were included! Happy to help if needed. The proposed schedule was just published.
  • @annezazu
    • Woohoo! I’m starting the “What’s Next” post for September and wanted to check in with this crew collectively to see what will be the focus for the month including any specific PRs, discussion issues, etc you’d like to flag. Don’t need to cover it all in this meeting but high level items would be lovely
      • @andraganescu the work on the new editors (Navigation and Widgets) will continue in September
      • @youknowriad I see a continuous effort on “Controlling Block Editor APIs” as well, I’m hoping to “finish it” on September if things go well.
  • @andraganescu
    • I want to raise that we want to move those editors out of experimental. There is a great deal of work still happening and still needed, but it’s important that  they become visible sooner rather than later.
      • @mapk With Matias’ recent feedback on the Widget Editor, I think this can happen. It appears we’re keeping a closer tie-in with my initial designs which are pretty much implemented.
  • @paaljoachim I was thinking about the general importance of drag & drop. How we can improve it in Gutenberg?
    • A discussion followed suggesting we add drag and drop in select mode and debating how it should work when writing
  • @itsjusteileen
    • Wondering if, in conjunction with any documentation being done for getting setup to do testing, if there wouldn’t be someone willing to do a zoom for folks interested in getting all the tooling needed to get started. It’s a bit of a barrier of entry for some folks.
  • @mkaz announced in a follow-up that he’ll be hosting a “hallway hangout” session on contributing documentation to Gutenberg repository. It will be an introduction covering 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/ PR workflow and environment setup.  The session will be on Tuesday, Sept 1st @ 1600 UTC / 9:00am PDT. It will be recorded and posted for those who can not make it.

Thanks to everyone who attended.

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

Dev Chat Summary: August 26 (5.6 Week 2)

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

Full meeting transcript on slack

General Announcements

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

Highlighted blogblog (versus network, site) posts

Components check-in and status updates

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

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

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

Open Floor

The meeting pivoted into a 5.5.1 pre-RC scrub run

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

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

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

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

Next Dev Chat meeting 

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

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

CSS Chat Agenda: 27 August 2020

Note: One hour before the meeting this week, @kburgoine will lead the first coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSSCSS Cascading Style Sheets. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.!

This is the agenda for the upcoming CSS meeting scheduled for Thursday, August 27, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

If there’s any topic you’d like to discuss, please leave a comment below!

  • Housekeeping
  • Updates
    • CSS Audit (#49582) – Updating counts and sharing with community
    • Color Scheming (#49999)
  • Open floor + CSS Link share

#agenda, #core-css

WordPress 5.5.1 maintenance release schedule

Shortly after WordPress 5.5 “Eckstine” was released, a small handful of tickets were opened reporting identified bugs. Because a few of them are particularly inconvenient, 5.5.1 will be a short-cycle release so that they can be addressed more quickly.

After two 5.5.1 focused bug scrubs, the following release schedule is being proposed:

The full list of the tickets targeted for this maintenance release is available on the 5.5.1 tickets report on Trac.

The 5.5.1 release is being lead by @audrasjb, @azhiyadev, @davidbaumwald, @desrosj, @johnbillion, @planningwrite, @sergeybiryukov, @whyisjake.

#5-5, #5-5-1

Dev Chat Agenda for August 26, 2020

Here is the #agenda for this week’s meeting happening later today: Wednesday, August 26, 2020, 10:00 PM GMT+2. Please share any items you’d like to include in the comments below.

  • Announcements
  • Highlighted blogblog (versus network, site) posts 
  1. Discussion on the proposal to drop support for old PHP versions via a fixed schedule
  2. Request for Input: Consent Preferences for Logged In Users (Consent API)
  3. Request for comments on Dev Chat – APAC Edition Meeting Summary – August 20 2020
  4. Timing of release WordPress 5.5.1
  • Calls from component maintainers
  • Open Floor

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

The #dev-chat  meeting will be held on Wednesday, August 26, 2020, 10:00 PM GMT+2. This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

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

CSS Chat Summary: 20 August 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1597957254000500

I (@notlaura) facilitated the meeting.

Updates

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSSCSS Cascading Style Sheets. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.

We discussed doing a triage every two weeks one hour before the weekly meeting. @kburgoine will lead the first one this week, on August 27 at 4pm EDT!

CSS audit updates

@isabel_brison added the media query counts to the CSS audit doc, the last remaining item! She mentioned finding that the audits were running on .css.orig files which was bloating the counts. We discussed that these and .rtl files should not be included in the counts because they are not authored files.

@kburgoine asked if the audit counts are including blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor CSS. We discussed that for now, the audit only includes wp-admin and wp-includes, but the tooling we have can be used for other code-bases. @ryelle suggested documenting the steps for running audits similar to these steps for pulling color data.

The next step for the audit is to update the counts excluding the .css.orig files, and @isabel_brison volunteered to do that in the coming week.

Color scheming updates

@ryelle re-ran the core color extraction steps using the approach referenced above, and the list of unmatched colors is now much more concise. This is quite a useful tool! @ryelle identified that the excess colors were coming from 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/. Since the colors are much more manageable now, it will make sense to go to design for feedback a bit later in the process once the PostCSS piece is in place and we can see the reduced colors in wp-adminadmin (and super admin).

@kburgoine asked if there was any way to break down this task into smaller pieces – it is a lot of work for one person. @ryelle said that later in the process, once we have files with the reduced colors, there will be many smaller tasks such as manual cleanup and testing that will be fit for more contributors.

Open Floor / CSS Link Share

There were no open floor topics.

@kburgoine shared a very slick Codepen that changes the font weight of a menu item on hover, without causing a reflow/jump on following menu items!

That was all for this (well, last) week!

#core-css, #summary

Editor Chat Agenda: 26 August, 2020

Facilitator and notetaker @andraganescu.

This is the agenda for the weekly editor chat scheduled for 2020-08-26 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  • Gutenberg 8.8
  • Monthly Plan for August 2020 and key project updates. With focus on issues, what is being done and help that is needed.
    • Global Styles.
    • Navigation screen and Navigation blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience..
    • Widgets screen.
    • 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. screen.
    • Full Site Editing.
  • Task Coordination
  • Open Floor

Even if you can’t make the meeting, you’re encouraged to share anything relevant for the discussion:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda

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

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

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

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

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

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

Chicken vs egg

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

Current situation: Classic Chicken vs Egg


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

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

So who are these users who don’t upgrade ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But all those users on old WordPress versions…

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

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

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

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

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

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

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

But what about the users currently on old WordPress versions ?

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

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

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

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

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

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