Matias Ventura 3:24 pm on December 13, 2018
Tags: , ,   

5.0.2: Editor Performance and Bug Fixes

With 5.0 released to the world, attention is now placed on preparing the follow up minor releases. The first one, scheduled for December 19th, focuses on performance improvements — particularly around typing with many blocks present on the page — and bug fixes.

The cumulated performance gains are around 330% faster for a post with 200 blocks. This might be even bigger for certain setups and plugin configurations — seeing the same test post be 540% faster with Yoast, for example.

The Gutenberg update can already be tested in the 4.7 plugin release and will be part of the upcoming 5.0.2 beta.

Performance 💨

Bug Fixes 🐛

Tests

#core-editor, #editor, #gutenberg

Felix Arntz 11:18 am on December 13, 2018
Tags: , , ,   

PHP Meeting Recap – December 3rd

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • @drewapicture announced that he’d start working on a proposal to add modern PHP best practices to the core handbook at WCUS contributor day.
  • The discussion about feature flags from the previous week was picked up again, particularly regarding the trade-offs of relying on a (network) option vs relying on a constant or environment variable.
    • Since some of the processes to be tested are executed very early in the WordPress bootstrap process, a variable that can be set in wp-config.php or earlier should be used. There possibly could be a wrapper function to access that value, including a filter that would allow adjusting the constant value dynamically by code that would run later.
    • WP-CLI could also be used to “more dynamically” set the constants.
    • It was mostly agreed that the Beta Tester plugin should somehow incorporate the feature flags functionality, in favor of core, at least initially.
    • Eventually, it was summarized that the topic should get picked up again later, as the WSOD protection mechanism (see #44458) is not blocked by this and should move forward.
  • Further conversations on the current state of the project will happen at WCUS, with the results being published in a recap. The meeting on December 10th is cancelled because of WCUS and related travel.

Post-WCUS Update

  • As mentioned during the State of the Word, WordPress core aims to raise the minimum required PHP version to 5.6 by April 2019, and to 7 by end of 2019 – a great success for the ecosystem and the Servehappy initiative.
  • A conversation between members of the core, community and hosting teams happened during contributor day, planning the steps ahead for both Servehappy and the overall Site Health project that it is part of. A detailed summary of this will be published separately.
  • The goal for the initial parts of Servehappy is to release them ahead of the PHP version bump, likely as part of WordPress 5.1. Due to the intended version bump, the core notice should be displayed on all PHP versions below 5.6, contrary to the originally intended idea of only targeting 5.2 initially.

Next week’s meeting

#core-php, #php, #servehappy, #summary

Gary Pendergast 6:04 am on December 13, 2018
Tags: , , 5.1, ,   

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 core 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 Candidate 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 plugin release will also be in WordPress 5.0.2.
  • Twenty Nineteen bugs and visual issues.
  • There are a few PHP 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

  • Beta 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 bug 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 lead 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 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 JS

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 GitHub into Trac. This move will likely happen immediately after 5.0.2.

#5-0-1, #5-0, #5-1, #core, #dev-chat
Ian Dunn 3:14 am on December 13, 2018
Tags: , ,   

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 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 plugin has explicitly registered input or select fields via the wp_kses_allowed_html filter. 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-1, #5-0, #dev-notes

Tammie Lister 8:08 pm on December 12, 2018  

Dev Chat Agenda: December 12th

This is the agenda for the weekly devchat meeting on Wednesday, 12th December 2018, 21:00 GMT:

  • Holiday times for dev chats: should we skip next 2-3?
  • 5.0.1 planning and updates
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to those listed above, please leave a comment below. Either way, we look forward to seeing you at the devchat this week!

This meeting is held in the #core channel in the Making WordPress Slack.

#5-0, #agenda, #core, #dev-chat

Heather Burns 5:09 pm on December 12, 2018
Tags:   

Core-Privacy Agenda – 12 December

When/Where: Join us in #core-privacy on Making WordPress Slack on Wednesday, 12 December at 1900 UTC

1. WCUS postmortem
a. Leo and Kevin’s privacy talk – comments, feedback, and follow up
b. Contributor Day – lack of a table as a core component team despite having had a table at WCEU
c. Morten’s talk/Leo
d. Other business arising

2. V2 roadmap updates

3. Team issues
a. Recruitment of new team members and contributors (chicken and egg discussion)
b. Instructions regarding the core-privacy team issued to the Marketing team
c. Team structure & visibility – per 17 October office hours summary and 28 June meeting

#core-privacy

Gary Pendergast 12:49 am on December 11, 2018
Tags:   

WordPress Branch Status Update

Thank you everyone for helping work through this slightly different commit management process during the WordPress 5.0 release.

There’s some cleanup work to be done before we can get back to normal, but this shouldn’t take too long. There are 283 commits made to the 5.0 branch that need to be reviewed and ported to trunk. During WCUS Contributor Day, @nacin and a few other folks investigated methods for automating this process, but found that it wasn’t a viable option.

Instead, the fastest option is going to be a manual merge. I’ve created a spreadsheet with a list of all of the changes in the 5.0 branch, and the files they touched.

With a couple of workflow considerations, we can use this spreadsheet to avoid getting in each others way, and duplicating work:

  1. Assign yourself a commit that you’re working on merging. If there are multiple related commits that you’re going to work on, assign them all at the same time.
  2. There’s no need to commit every changeset individually, particularly those that will be overwritten by a later commit. For example, package.json or .travis.yml changes. Mark the earlier commits as Skipped.
  3. If you mark a changeset as Blocked or Skipped, leave a note with the reason.

Here are a few reminders while you’re running through changes:

  • Please read the Backporting Commits handbook page on best practices. If the svn merge command doesn’t apply cleanly, and you need to manually merge the commit, you can use the --record-only switch to record the merge, but not apply the changeset.
  • trunk is enforcing coding standards, so it’s a good idea to run composer install when you switch to trunk, then composer run format on the files you’re about to commit. grunt precommit will automatically do this.
  • Remember to add relevant information to the commit message:
    • “Merges [12345] from the 5.0 branch to trunk.”
    • Copy all props from the original commit.
    • “Fixes #54321“, so the relevant ticket is auto-closed.

@omarreiss and @atimmer are working on merging the @wordpress/* packages into the JavaScript reorganisation in trunk. All other changes without an assigned committer are up for grabs.

Finally, here is the status of the branches:

4.9 branch

The 4.9 branch is in normal status. As the previous major release, changes are only back ported on a case-by-base basis. There’s nothing to be merged from the 5.0 branch to the 4.9 branch.

5.0 branch

The 5.0 branch is closed until the work on porting changes to trunk is complete, at which point it returns to normal status. If the porting takes more than a few days, it may be returned to normal status for the purposes of releasing a 5.0.1 beta.

Trunk

Trunk is currently only open for merging changes from the 5.0 branch. After this work is complete, trunk is open for bug fixes, all features should be approved by @matt before committing.

#5-0

Helen Hou-Sandi 10:22 pm on December 9, 2018
Tags: , ,   

On WordPress + Git

Can you believe it – we’ve made it through a State of the Word without anybody asking “when is WordPress moving to Git/GitHub?” You may, however, have caught a brief mention of issue trackers in relation to the Triage Team focus for 2019. While it’s very important to make the distinction between Git the version control system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate Trac tickets over” – it means imagining what kind of change would be a net benefit to the core development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of Gutenberg development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunk), JavaScript package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVN repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regression, end-to-end, accessibility, performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migration from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org plugin and theme repos (GitHub Actions-powered build+deploy)
  • Automated testing – sniffers, Tide, unit tests, WP and PHP compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

Matt Mullenweg 10:49 pm on December 8, 2018  

9 Projects for 2019

As mentioned in this year’s State of the Word, these are the nine priorities that we should focus on in 2019, in order to make the biggest impact for WordPress users:

  • Creating a block for navigation menus.
  • Porting all existing widgets to blocks.
  • Upgrading the widgets-editing areas in wp-admin/widgets.php and the Customizer to support blocks.
  • Providing a way for themes to visually register content areas, and exposing that in Gutenberg.
  • Merging the site health check plugin into Core, to assist with debugging and encouraging good software hygiene.
  • Providing a way for users to opt-in to automatic plugin and theme updates.
  • Providing a way for users to opt-in to automatic updates of major Core releases.
  • Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them.
  • Forming a Triage team to tackle our 6,500 open issues on Trac.
Gary Pendergast 10:48 pm on December 8, 2018  

Updating the Minimum PHP Version

For the millions of sites already running WordPress 5.0, 85% are using PHP 5.6 or above. We’ve also recently observed that showing notifications to encourage users to upgrade their PHP version has been very effective. Yoast SEO experimented with this last year, and found that site owners upgraded their PHP version at twice the rate than before they were showed the notification.

In light of that, I’d like to propose that in April 2019, we bump the minimum PHP version requirement to be 5.6. Sites that choose to remain on 5.5 or below will still receive security updates and possibly bug fixes, but would not be able to upgrade to the latest major WordPress version until they upgraded to a supported version of PHP.

Similarly, I’d like to propose that in April 2019, we bump the minimum MySQL version requirement to be 5.5. 98.5% of WordPress 5.0 sites are using MySQL 5.5 and above.

Depending upon feedback and effectiveness, we can follow up by bumping the required PHP version to 7 as early as December 2019.