4.9 and Gutenberg

I am really happy with the 4.8 release: the potential impact on new users and community event attendance is big, and the entire community really pulled together to make it a success.

I’m sure many people are curious and anxious about the Gutenberg editor. You can of course follow along and participate on GitHub, and we’re hoping that a plugin for easy install and usage will be available soon.

I’d like to give Gutenberg some extra gestation time as a plugin, ideally getting it to 100k active sites over the next month or two, before we merge. It’ll be easier (and safer) to get people to install and auto-update a plugin than switch their sites to trunk. We could even put a promo for it in 4.8.1.

In the meantime I think we can do another user-focused 4.9 release with the theme of editing code and managing plugins and themes, doing v2s and polishing some features we brought into WP last year. Weston and Mel already have some good ideas there, and we can start to discuss and brainstorm at the Dev chat next week. This will also allow the Gutenberg-driven release to be 5.0, which is a nice-to-have but not the primary driver of this decision.

Hopefully I will see some of y’all at WordCamp EU, and regardless be sure to tune in to my session tomorrow which you can livestream from the WordCamp Europe homepage.

Target Browser Coverage

Previously, we discussed the new editor and browser support within WordPress core. Following up on those conversations, we are officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8.

Microsoft officially discontinued supporting these browsers in January 2016, and attempting to continue supporting them ourselves has gotten to the point where it’s holding back development. I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something. Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against. (The numbers surprised me, as did how low IE market share overall has gone.)

Of course, wp-admin should still work in these older browsers, but with fewer capabilities, and we will no longer be testing new features and enhancements in these browsers. For example, the next versions of TinyMCE – currently targeted at WordPress 4.8 – will not support older IE browsers.

As part of this change, we will work to update Browse Happy to show that these browsers are no longer supported and encourage users to upgrade or switch browsers.

First Quarter Check-in

Just wanted to give folks my perception and feelings on of how we’re doing thus far with the core foci:

Writing: I’m really happy with the progress. It has had some slower weeks here and there the past few months, but by and large the technical prototypes we implemented have been successful and we’re ready to move into the next phase. We have a Chrome fix we have to get in the next minor release, and the link boundary improvements will be going into TinyMCE core and could be great for an interim +0.1 release.

Customization: Doing well. Remember: The plan is for the larger block-driven customization work to kick off in June. Prior to that, we’re focusing on widgets and other low-hanging fruit. Lack of developers slowed us down last few months, now doing better but could still use more help there. Media widgets + WYSIWYG on text widget seem simple but will have a big user impact.

REST API: There has been little to no perceivable progress on having any parts of wp-admin powered by the REST API.

Considering 4.8: The TinyMCE inline element / link boundaries, new media widgets, WYSIWYG in text widget, and perhaps something else small like the WordCamp / meetup dashboard upgrade to the “news” section, would comprise a nice chunk of new functionality for a +0.1 “major” release. I’m hopeful their progress over the remainder of April will allow us to kick off a process to do a nice 4.8 update in the May / June timeframe, without drawing too much focus away from the Big Changes in the next-generation editor that is still the top priority.

#4-8

Aaron Campbell Leading Security

@aaroncampbell is now the new lead of security triage and resolution for the WordPress project, also known as the Security Czar. Many thanks to Nikolay Bachiyski for kicking this role off and getting a lot of the infrastructure we use in place. This is also a good time to thank the dozens of volunteers who participate in the security group, and the researchers and reporters who bring issues to our attention.

#security

Focus Tech and Design Leads

There are three main focuses this year: the REST API, the editor, and the customizer.

For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

REST API: Ryan McCue and KAdam White.

Editor: Matias Ventura and Joen Asmussen.

Customizer: Weston Ruter and Mel Choyce.

Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

Tech Lead responsibilities:

  • identify and ensure implementation of first-class REST API usage within WP-Admin,
  • replacing/refactoring admin-ajax use.
  • overall REST API architecture
  • infrastructure and endpoint performance
  • security at an infrastructure and endpoint (data-exposure) level
  • improving authentication options and documentation
  • working with the Design Lead to build new, or expand on existing, endpoints
  • working with the Design Lead to address usability feedback for the infrastructure and endpoints

Design Lead responsibilities:

  • usability of endpoints for internal or external clients
  • usability of the infrastructure from the perspective of a API client
  • working with the Editor and Customizer focus teams to collect requirements and gather feedback
  • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)

#customizer, #editor, #rest-api

Supporting the Future of wp-cli

wp-cli is a command-line interface that is deployed and relied upon by almost every major user of WordPress out there. As we head into 2017, I wanted to make sure that its future is certain for everyone who builds on it, and that the major contributors to the project, chiefly Daniel Bachhuber, are able to work on it even more in the coming year.

To that end there are two big announcements:

1. The website of wp-cli.org, the code / GitHub, Twitter, and such are all coming in under the WordPress.org umbrella and there will be a CLI Make site with a P2 and all of the resources that used to be under wp-cli.org. There is already #cli on Slack and that will continue. (Will live at https://make.wordpress.org/cli.)

2. I’m going to be bringing together a number of companies in the WordPress ecosystem to solidify their financial support of runcommand so that Daniel and others can devote more time to making wp-cli better and better through 2017. This is a continuation of the fundraising started a few weeks ago.

This will all happen the first part of January, and I’m looking to a full and exciting year for wp-cli. Also big thanks to everyone who has chipped in, whether time or money, to support the project in the past. It has been one of the highest impact developments for WP in many years.

Many of the logistics are yet to be determined. Feel free to weigh in with questions, feedback, etc. in the comments, or join #cli on Slack. We’ll do our best to keep everyone in the loop as things develop.

#wp-cli

New lead for 4.7: Helen Hou-Sandí

Due to some unexpected constraints on my time this year, I’m going to be stepping down as the 4.7 lead, and I’m happy to announce that Helen Hou-Sandí is stepping up to lead the release in my stead. I’ll still be behind the scenes providing whatever support is necessary, and I’m really looking forward to the release . You might remember Helen for her famous work on WordPress 4.0.

#4-7

Since some people read this and not the…

Since some people read this and not the news blog, 3.8 is out. 🙂

State of 3.8, and thoughts on the next week

tl; dr: Still on track for release next Thursday. We’re extending the window for code changes by 3 days, through the 8th. RC2 package on the 9th will be what ships on the 12th.

December 5th, our targeted but controversial freeze date, is drawing to a close. First the bad news: there are two blockers and we could not ship the package we have tonight, despite a lot of great effort. The good news is we are close, there are good priorities on the remaining issues, the new features appear resilient and are live on WP.com which has generated a ton of testing, and we’re far enough out from our target (the 12th) that I’m confident we can ship that morning and still have had a 4-day freeze.

As a side-effect of the longer freeze and predictable date, I also think the best WP hosts will push it to their customers same-day and we’ll continue or improve our record of having localized versions ready to go.

What could break it? If an unknown unknown blocker pops up on Tuesday or Wednesday, we’re going to have to delay the release until the following week. Discovering that issue sooner, so it wouldn’t cause a delay, is a function of testing — the more we can test and cover now the better. We want to shake out big issues now, not next week. The more people that can run the RC or trunk at this point, the healthier the release will be.

What’s open right now? Our most substantial blocker, no-JS fallback for THX #25964, was raised a few weeks ago and we could have flagged its priority and developed a solution then, rather than the flurry of activity its had over the last two days. Our other blocker, the about.php page, is similar: I should have kicked off that page (#26387) when we nailed down exactly what headline features would be in the release, which was much earlier. Often user-focused non-code deliverables wind up as the last thing we do, but they’re so visible they deserve time to bake just like a complex backend change would. Of the the other 15-ish open issues there is nothing intractable, but there’s also nothing trivial, and for some issues we need to make a non-obvious decision to move it forward. We made the decision to punt or revert a number of things that weren’t fully ready yet, like the new author widget and RSSJS.

The things we missed are not a matter of having enough time, they’re a matter of priority. I think properly triaging issues as soon as they come in and being disciplined about working from highest to lowest will allow future release to avoid these problems. Even though that’s not hard to understand intellectually, sometimes you have to make the mistake to really grok it. I’m extremely proud of everyone who has been involved so far and in the amount of learning and growth I’ve observed even in our accelerated cycle.

#3-8

Excellent 3.8 brainstorm session today People talked about…

Excellent 3.8 brainstorm session today. People talked about a number of interesting ideas and started to form some groups around them. Not everyone is in IRC, so wanted to give an opportunity for people to post a comment with a given area here, and if you’re interested in contributing to that area reply to that comment. This allows people to connect asynchronously. As people comment please connect with them directly in IRC, email, whatever, and discuss.

Next week groups will bring more fleshed out proposals for forming a Plugin Project team, including a lead, mockups, user tests, existing plugins…

#3-8