Dev Chat Summary: December 12th

Dev Chat Scheduling

As many folks will be away over the Christmas/New Year period, the next few meetings will be as follows:

  • December 19: Normal meeting.
  • December 26: Normal meeting will not be happening. There are likely to be coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. folks around to answer questions for an open floor session.
  • January 2: Normal meeting.

5.0.2 Schedule and Scope

Please note that WordPress 5.0.1 has just been released, so any previous mentions of scope or schedule for WordPress 5.0.1 should now be read as applying to WordPress 5.0.2.

WordPress 5.0.2 is intended to be released two weeks after WordPress 5.0, which would make the release date December 20. To give a little more space before the Christmas/New Year holiday period, I’ve proposed that it be released December 19.

Milestone Dates

  • 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: December 14, 2018
  • Release Candidate 2 (if needed): December 17, 2018.
  • General Release: December 19, 2018.

The following items are in scope for the 5.0.2 release:

  • Gutenberg 4.7 was released today, the fixes in this 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 release will also be in WordPress 5.0.2.
  • Twenty Nineteen bugs and visual issues.
  • There are a few PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.3 compatibility fixes to be made.

Any other tickets currently milestoned for 5.0.2 will be considered on a case-by-case basis, priority will be given to tickets with patches, testing, screenshots, and any other relevant information to show that they’re ready to land immediately.

5.1 Schedule and Scope

As there are already over 200 tickets fixed in WordPress 5.1, I’d like to propose that WordPress 5.1 has a relatively short release cycle.

Milestone Dates

  • 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: January 10, 2019
  • Release Candidate 1: February 7, 2019
  • General Release: February 21, 2019

A key point from the WordPress 5.0 cycle was that it demonstrated the value of having a hard feature freeze at beta 1, as well as string freezes and strict 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. fixing policies during the release candidate phase. With that in mind, I’d like to propose that we retain these policies for the WordPress 5.1 cycle.

The tickets already fixed in WordPress 5.1 need to be reviewed, to ensure they’re all stable for release in this cycle.

Apart from that, the PHP upgrade warnings and the White Screen of Death protection from the Site Health Check project are currently the only uncommitted features scheduled for WordPress 5.1. The PHP upgrade warnings are currently soft warnings, ahead of the minimum PHP version bump proposed for April 2019.

@matt will be continuing his role as release leadRelease Lead The community member ultimately responsible for the Release. into WordPress 5.1. Any other feature proposals will need to be approved by him.

Please leave feedback on this post, so the scope and schedule can be confirmed in the next day or two.

Focus and Component Updates

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

The REST API group will be re-opening discussion around authentication solutions. They’ll be posting further information about this project on make/core.

Core JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.

The Core JS group didn’t meet this week, due to many folks travelling home from WCUS. They’ll be resuming normal meetings next week.

Core Themes

The current themes focus is on triaging Twenty Nineteen issues for 5.0.2, as well as preparing to move activity from GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ into TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. This move will likely happen immediately after 5.0.2.

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

Backwards Compatibility Breaks in 5.0.1

5.0.1 was just released to fix several security bugs. The Security team tried very hard to mitigate all of the vulnerabilities without any back-compat breaks, but unfortunately there were a few cases where that was not possible.

Security patches are backported to the 3.7 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"., so these BC breaks also apply to versions 4.9.9, 4.8.8, etc.

Form element no longer passes KSES

Prior to 5.0.1, the $allowedposttags array contained an entry for the <form> element and some of its attributes. Because of that, Contributors and Authors could use it in posts.

The element was removed in 5.0.1, except for situations where a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party has explicitly registered input or select fields via the wp_kses_allowed_html 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.. If a Contributor or Author includes <form> in their post, it will be removed when the post is saved. It will also be stripped from arbitrary content that plugins pass to wp_kses_post() or wp_kses_allowed_html( 'post' ).

If a plugin author wants to restore the original behavior, they will need to add form, input or select tags via wp_kses_allowed_html. Please exercise caution when doing so, because this could re-introduce a vulnerability. Make sure only trusted users are allowed to add <form> tags. 

meta_input, file, and GUID inputs are ignored

Prior to 5.0.1, $_POST requests for creating posts could contain values for meta_input, file, and guid. This is no longer true, and values passed for those fields will be ignored.

Plugins should not manually manipulate $_POST, but rather use the appropriate filters, and always validate/sanitize any data coming from an untrusted source.

MIME validation for uploaded files

Prior to 5.0.1, WordPress did not require uploaded files to pass MIME type verification, so files could be uploaded even if the contents didn’t match the file extension. For example, a binary file could be uploaded with a .jpg extension.

This is no longer the case, and the content of uploaded files must now match their extension. Most valid files should be unaffected, but there may be cases when a file needs to be renamed to its correct extension (e.g., an OpenOffice doc going from .pptx to .ppxs).

#5-0, #5-0-1, #dev-notes