Servehappy Roadmap

The group of people in the #core-php channel has been discussing and planning a project codenamed “servehappy” for some time now. We are at the point where we think that our plan has matured enough to present it to a bigger WordPress audience, in the hopes that we can get buy-in from more people to support or join our cause.

Goals

Primary Goal (long-term, indirect):

  • Reduce the number of WordPress installations running on an unsupported PHP version

Secondary Goals (short-term, direct):

  • Make WordPress site owners aware that they are running an unsupported version of PHP
  • Educate WordPress site owners about PHP and its versions
  • Provide WordPress site owners with tools and resources that enable them to update their site’s PHP version

The primary goal is what we’re aiming at. However, this is not something we can directly act upon. The secondary goals are the actionable elements that are in line with the primary goal.

We are confident that we can produce a definite positive impact on the primary goal through a concerted effort on these secondary goals.

Current State

A good overview of the current state can be found in the project repository’s README.md file.

 

Mockup of the ServeHappy page, showing collapsible sections of content.

ServeHappy page mockup
Click to enlarge

 

Through our regular weekly meetings we’ve made good progress on putting together the content for an informational page called “servehappy (in reference to the “browsehappy” page that helped get rid of legacy web browsers). The page should ideally be hosted on the wordpress.org infrastructure, similar to how the browsehappy page is stored.

 

Mockup of the WordPress admin dashboard, showing an admin notice warning about the PHP version.

Admin notice mockup
Click to enlarge

 

This page is meant to be linked to by admin notice(s) in the WordPress admin dashboard that will appear for people with unsupported PHP versions. Work on implementing these can start as soon as we have confirmation that the servehappy project should be further pursued.

 

Mockup of a plugin detail screen in the admin dashboard, showing a red "Cannot install" button and a link to the ServeHappy page.

Plugin requirements mockup
Click to enlarge

 

Finally, we want to work on enforcing plugin/theme PHP requirements as they can already be stated in the plugin/theme meta information. With time, this will provide developers with better control over their code base and incentivize site owners to keep up with the WordPress ecosystem’s evolution.

We’ve prepared a short overview document that details the core integrations and how they tie into the servehappy page.

As a side note, while working on the servehappy page content, we started collecting links to various resources that can be of use to people wanting to update their PHP version. These can be found in a separate servehappy-resources repository.

Project Progression

We intend to target only PHP 5.2.x initially, to not put too much pressure on the support channels of hosting providers. When a reasonable amount of time has passed and most of the initial updating effort has been completed, we can consider moving the needle up to PHP 5.3.x.

Provided that we have a clear roadmap, transparent communication and the patience to let site owners and hosters handle the updates in manageable intervals, this provides us with a tool to slowly catch up to PHP releases and reduce the currently growing gap between WordPress requirements and PHP versions.

Timeline

Here’s our current preliminary timeline:

Information Page on WP.org – Current Draft
– Trac ticket
1st Quarter 2018
Admin Notice in Dashboard – Trac ticket 2nd Quarter 2018
Minimum PHP Requirements Trac ticket 3rd Quarter 2018

Of course, these are only guesstimates. The actual development work involved makes this timeline easily possible, but what is time-consuming (and hard to predict) is the amount of discussions that are needed to find a concensus on all critical decisions.

Our Request

Before we invest more time into this project, we want to get a basic decision (in principle) about whether we should pursue or not.

  1. Is the servehappy project worthwhile and do we have a general buy-in from Core leadership?
  2. Can we make the servehappy project an official feature project?
  3. Information Page – Can this page be hosted on the wordpress.org infrastructure?
  4. Information Page – Who is responsible for the final editorial check?

To this end, we had the servehappy project added to the agenda of the upcoming devchat meeting on 10th Jan, 2018. This post was prepared to allow attendees of this meeting to get a quick overview of the project in preparation for the meeting.

#php, #roadmap, #servehappy

Multisite Roadmap Published

Over the past year, the multisite team has been looking at possible features to add or improve support for, what some of the pain points are and last but not least how to align with the core focuses for this year, which for multisite scope basically means working on REST API support and usage.

The result of those long discussions is a clearly defined roadmap, describing what the priorities will be over the next couple months or generally the near future. It should be clarified that this is a living document that will see updates from time to time as tasks get completed or new decisions are made.

The roadmap document lives on a separate page to be easily accessible outside of the blog, and also to allow other component teams to possibly follow with their own roadmaps.

Here is what the roadmap focuses on at this point of publication:

  • REST API support for users, sites and networks
  • new internal APIs for sites and networks
  • introduction of site metadata
  • internal usage of the Meta API for network options
  • file organization improvements

All the above will set a solid foundation to after their completion finally focus on some long-needed more user-centric enhancements, particularly to the administration panels. Other long-term changes include improving test coverage and global context support. Those areas are also described a little more broadly in separate sections towards the end of the roadmap.

Please refer to the roadmap document for a full and current overview of multisite priorities.

#core-multisite

WordPress PHP now (mostly) conforms to WordPress Coding Standards

For 12 long years, the WordPress Coding Standards have stood as a beacon of hope, a promise that code written for WordPress will be easily readable, recognisable, and portable. Sadly, WordPress’ own PHP hasn’t lived up to that promise.

Until now.

Weighing in at a respectable 105,650 lines added, 77,558 lines removed, with an 11MB diff, [42343] fixes 94.8% of the coding standards issues in WordPress’ PHP.

The 5.2%

The remaining 5% of coding standards issues require manual intervention, which means that we’re going to start accepting coding standards patches in the near future. Please hold off on creating tickets and submitting patches for now, while we figure out the best way to manage it.

Existing Patches

Unfortunately, this change means that most patches currently on Trac will no longer apply cleanly – they’re going to need updating. It’s going to take a bit of experimenting to figure out the most efficient way to handle this, if you’re interested in this problem, please go ahead and experiment!

The Wider Ecosystem

In the process of preparing for this, there were a lot of bugs fixed and features implemented in WPCS, as well as upstream in the PHPCS project – this not only benefits the WordPress ecosystem, but the wider PHP ecosystem. Special props to @jrf for driving the bulk of these changes, both in WPCS and PHPCS!

WordPress 4.9.1 beta

As mentioned earlier today, WordPress 4.9.1 has been scheduled for release tomorrow, November 29th, 20:00 UTC. Please have a read of that post for details of the fixes.

The beta package for 4.9.1 is now ready for testing. Please help us by testing this beta to ensure 4.9.1 fixes the reported issues and doesn’t introduce any new ones.

#4-9-1

WordPress 4.9.1 scheduled for November 29th

WordPress 4.9 has been downloaded over 6 million times since its release two weeks ago.

A small number of bugs have been identified which are impactful enough that the core team has decided to release 4.9.1 with fixes for those issues. The release is scheduled for tomorrow, November 29th, 20:00 UTC. A beta release will be packaged later today and made available for testing.

The issues that have been fixed are:

  • #42573: File caching affecting users’ ability to use the plugin and theme file editors.
  • #42574: MediaElement upgrade causing JS errors when certain languages are in use.
  • #42579: Incorrect logic in extract_from_markers().
  • #42454: Unable to translate Codex URL in theme editor.
  • #42609: Theme editor cannot edit files when running on a Windows server.
  • #42628: flatten_dirlist() doesn’t play nice with folders with numeric names.
  • #42634: DB_HOST socket paths with colons not parsed correctly.
  • #42641: On multisite upgrade the wp_blog_versions table doesn’t get updated
  • #42673: Themes page throws console error when there is only one installed theme.

In addition, one fix for a bug introduced in WordPress 4.7 will be included in 4.9.1:

  • #42242: lang attribute in the admin area doesn’t reflect a user’s language setting.

Stay tuned for the announcement of a beta package.

#4-9-1

PHP Meeting Recap – November 13th

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.

The meeting’s chat log.

Attendees: @flixo90 @jdgrimes @jon_bossenger @mikelking @mte90 @nerrad @schlessera

@sergey

Chat Summary

We started the meeting by examining the poll that @flixos90 had made regarding a modified meeting time slot.

As most of the votes went to the 16:00 UTC time slot, and nobody had a specific reason for not using that time slot, we decided to make that new time official from now on.

This means that all subsequent meetings are held at 16:00 UTC from now on.

Then we continued working on the “Before Upgrading PHP” section again, which we are working on in a shared Google Doc.

Here’s a brief summary of the corresponding discussions and decisions:

  • We discussed adding a second “Backup” step after all updates have been done. In case of a rollback further down the line, this would avoid going through all updates again, which incur a big time and bandwidth hit.
  • While discussing how to best add this addition “Backup” step, we came up with the idea of adding small “aside” text boxes to the document, which visually communicate that the content therein is not part of the critical path and should not be considered a blocker in case the user can’t complete that “aside”.
  • We discussed the different animals that Google Docs assigned to the anonymous users, and how they don’t seem to match up everywhere. 😉
  • Regarding the compatibility checker, we discussed whether to include knowledge about the future XWP project that might have an impact here, or not. We decided that we write the content for the current state and context, as there’s no guarantees to when or if any of the WIP projects will be completed and usable.
  • We added an aside to the compatibility checker as well, to warn users against false positives and other detection issues.
  • We acknowledged that our aside might be a bit on the intimidating side, and that we need the help of the #marketing team to rephrase the copy in that regard.
  • We rewrote the “Ask plugin/theme support” topic so that it is clearer and points people to existing resources first before contacting support.

Next week’s meeting

The next meeting will take place on Monday, November 20, 2017 at 16:00 UTC, as always in #core-php, and its agenda will be to finish the rest of the “Before Upgrading PHP” document that we will hand over to the marketing team to get their help with writing the copy. If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

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

WordPress 4.9 final nightly build

As noted in the 4.9 release delay post, a final nightly build is now available for testing. This includes three commits, so please take a look through those and test as you can (see #42548, #42530, and #42545).

We hope to ship WordPress 4.9 on Wednesday, November 15th (that’s tomorrow) at 23:00 UTC, but we still need your help to get there. If you haven’t tested 4.9 yet, now is the time!

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

We are almost there
But we still need help testing
So test, please and thanks!

Thanks for your continued help testing out the latest versions of WordPress.

#4-9

WordPress 4.9 release delayed by one day

The 4.9 release was due out today (November 14th), however issues with shortcodes within widgets (#42548) and changes to the Editor (#42530) occurred during release preparations. The new target release date is tomorrow (November 15th). It doesn't serve anybody well to delay things this late in the day, but it's essential to ensure the late fixes which have landed in the last few days are well tested.

We will do a release dry-run today at November 14th, 23:00 UTC23:00 UTC in #core after the code freeze, depending on the availability of the lead devs. An update will be posted that includes a link to a nightly build after the code freeze.

We've re-scheduled the 4.9 release to occur tomorrow at November 15th, 23:00 UTC / 23:00 UTC.

#4-9

Nav Menu Improvements in the Customizer in 4.9

In our usability tests with prior releases, we identified two common problems users encountered when trying to create a menu.

  1. Clicking the Add a Menu button in an attempt to add a page to their new menu.
  2. Forgetting to assign the menu to a location.

In WordPress 4.9, we’ve updated the Customizer’s menu creation flow to address these issues.

An Updated Menus Panel

The Menus panel layout and copy have been updated for clarity. The panel now shows menus first and locations second. This puts menus front and center and allows the panel to adjust more easily to specific scenarios. For example, when there are no menus, the panel asks users to create a menu and explains the steps to be taken.

Before After

Menu Creation

When the user clicks Create New Menu, the Customizer opens a dedicated menu creation section. Using a dedicated section allows us to guide the user through each step of menu creation. We start by inviting the user to provide a clear name for the menu and to select its new location. Once the menu is created, we guide them to add menu items and highlight the Add Items button if the user doesn’t find it after a short time.

Create a Menu for a Location

The locations section now allows the user to create a menu for a location that has not been assigned a menu. When the user clicks a location’s Create New Menu link, the Customizer opens the Menu Creation section with the location preselected.

Deprecated UI Classes

With the addition of a dedicated menu creation section, a number of classes are no longer used and are being deprecated.

The following PHP classes have been deprecated along with their files:

  • WP_Customize_New_Menu_Control in
    wp-includes/customize/class-wp-customize-new-menu-control.php
  • WP_Customize_New_Menu_Section in
    wp-includes/customize/class-wp-customize-new-menu-section.php

The following JS class has been deprecated (but not its containing file):

  • api.Menus.NewMenuControl in
    wp-admin/js/customize-nav-menus.js

Related Tickets

  • #40104 Customizer: Improve menu creation flow
  • #36279 Add an “add new menu” button to the menu locations section in the customizer
  • #42114 Customize Menus: UX Improvements
  • #42116 Customize Menus: Add “It doesn’t look like your site has any menus yet” view
  • #42357 NewMenuControl class has been removed from trunk

#4-9, #customizer, #dev-notes

WordPress 4.9 Field Guide

WordPress 4.9 is officially the best release ever (that rhymes with Shore Joint Twine)!  Users have safer and more flexible ways to edit code, new and improved widgets, and improvements to customizing their site while developers will be able to take advantage of 188 enhancements and features added.  Let’s look at the many improvements coming in 4.9…

Widgets: now new and improved

Galleries aren’t just for posts anymore, now they can get all up in your sidebars. That’s a good thing, if you’re into that sort of thing. On top of that your text widget now supports shortcodes, images, galleries, videos, audio, and other media. Oh, and the text widget now supports embeds, so go ahead and drop a YouTube clip in that widget.

Introducing the Gallery widget

Widget Improvements in WordPress 4.9

WordPress and CodeMirror sitting in a tree…

Something something I-D-E. Ever wondered what an IDE would look like inside WordPress? Do you use Notepad as your IDE? No? Great, then you’ll love the syntax highlighting, linting, and auto-completion functionality within the Customizer’s Additional CSS feature, the Custom HTML widget, and the Plugin and Theme file editors!

Code Editing Improvements in WordPress 4.9

🔎, 🏗️, and 👓 Themes in the Customizer

That’s emoji for browsing, installing, and previewing, but you knew that already. The Customizer now includes a new experience theme browsing and live-previewing themes, as well as—for the first time—installing new themes from WordPress.org in the process. Don’t believe us? Then give it a try with your favorite theme!

A New Themes Experience in the Customizer

Changesets

Quick, what’s your favorite sequel? If you said Caddyshack 2, then we need to have a little chat. If you said Changesets 4.9, then you’re correct! Get ready to learn all about Drafting, Scheduling, Autoloading, and Linear/Branching Modes, Autosaving Auto-Drafts and Autosave Revisions, Post Locking, and Customization Drafts. Yes, all of that is in 4.9. You’re welcome.

New Features and Enhancements with Customizer Changesets in 4.9

Nav menu creation flow

Ever had problems working in the Customizer and adding a page to a menu or forgetting to assign a menu to a location when trying to create a menu? The Customizer’s menu creation flow has been updated to address these issues.

Nav Menu Improvements in the Customizer in 4.9

The A(PI)-Team

If you have a problem, if no one else can help, and if you can find them….maybe you can hire The A(PI)-Team. The Customizer JS API improvements in 4.9 fix many longstanding annoyances and shortcomings with the JS API. Additionally, a REST API update now effectively requires named URL parameters and thus no longer allows regular (numeric) matches.

Improvements to the Customize JS API in 4.9

Improvements in REST API request parameter regular expressions

Multisweet multisite multimprovements

Run a network of sites? Then pour yourself some coffee and dig into all the multigoodies in 4.9. New functions and filter, replaced functions, capability and role updates, and some security improvements all come along for the ride on the multisite train.

Multisite Focused Changes in 4.9

Users and security updates

Were you hoping for new capabilities for activating and deactivating plugins plus installing and updating language files, capability security hardening, changes to how multisite handles switching roles and capabilities, and security improvements to how email addresses get updated in 4.9? If so, you’re going to be happy. If not, you should still be happy.

Improvements for roles and capabilities in 4.9

Account Security Improvements in WordPress 4.9

Don’t Press That

Press This is no longer in core, but can be found via a “canonical” plugin. Cry if you want to, but the functionality still exists so cheer up!

Press This in 4.9

 

ME.js updates.js

If.js I.js could.js think.js of.js something.js witty.js related.js to.js the.js ME.js.js updates.js, then.js I.js would.js have.js wrote.js that.js here.js. Instead.js… .js.js all.js the.js things.js.

MediaElement upgrades in WordPress 4.9

Updates for screen readers

As usual, we saved the best for last! Modernization and standardization comes to the screen-reader-text CSS class.

Changes to the screen-reader-text CSS class in WordPress 4.9

But Wait, There is More!

Roughly 400 bugs, 181 enhancements, 7 feature requests, and 42 blessed tasks have been marked as closed in WordPress 4.9.

Please, test your code. That bears repeating: Please, test your code. Fixing issues now, before 4.9 is released, helps you and helps millions of WordPress sites. Please. Test. Your. Code.

#4-9, #dev-notes, #field-guide