New function: human_readable_duration

In WordPress 5.1, the new human_readable_duration function will be introduced. This function accepts a duration in hours, minutes and seconds and returns a “human readable” string appropriate for screen readers.

The function takes a string representing a time duration, with hours, minutes and seconds separated by a : (colon). For example, calling human_readable_duration( '3:10' ); will return 3 minutes, 10 seconds. Minutes and seconds are required. For 10 seconds, the call would be human_readable_duration( '0:10' );.

This new function was added as part of the work to improve the display of media metadata in #39667 where, in addition to adding units, aria-labels with plain language descriptions were added to improve accessibility:

https://cldup.com/P8-Sq1n6Bv.png
Improved time duration accessibility in the media library using the human_readable_duration() function.


#5-1, #dev-notes

JavaScript Chat Summary – January 15th

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on the next meeting’s agenda.

Open floor

Our agenda was empty this time. This is the topics we discussed:

#javascript

Follow Up on Recent Trac Bulk Edit

On January 4, there was a bulk ticket edit in Trac that affected approximately 2,300 tickets spanning all components that had not been modified in at least 2 years. The bulk action performed was setting the ticket status to closed with a resolution of wontfix.

A full list of the tickets closed can be viewed using this Trac query.

Follow Up Discussion

During last week’s devchat, there was a productive discussion about what happened and how to move forward from there. Listed below are some of the main takeaways:

  • Context
    • The bulk edit was not related to the recent Short Term Trac Milestone Ticket Triage Proposal.
    • A goal of the new Triage Team will be to establish better processes for performing updates to tickets, including bulk updates if any are warranted.
    • Bulk actions spanning multiple components should be communicated ahead of time.
    • Each component having hundreds of open tickets makes it difficult for new contributors to see where they can help most.
    • Many tickets take a lot of institutional knowledge to identify the best paths forward.
  • Hurdles
    • Component maintainers and Trac gardeners need clear expectations for how to treat those closed tickets. Triaging tickets that are closed is hard.
    • The wontfix keyword may not have been appropriate here. “Won’t fix” sounds like an active decision based on the lack of merit for a ticket. This may not be the case for most of the tickets closed.
    • Perhaps older tickets are getting lost in the reports currently offered on Trac.
  • Suggested Solutions
    • wontfix needs to be re-evaluated. maybelater is a resolution that fits this scenario better.
    • Define or agree on what constitutes “no activity”
    • A “stale” designation may help. Stale notices could remain open but be hidden from standard reports.

Proposed Path Forward

After the conversation in devchat, it was decided that this post would be a better place to continue discussion and reach a final conclusion.

Below is the process moving forward that is being proposed after taking into account all of the feedback received so far:

  1. All tickets closed in the bulk edit due to inactivity will have their resolution changed from wontfix to maybelater.
  2. Component maintainers are free to reopen tickets closed as a result of this bulk action, as long as they have a plan to triage the list within a reasonable amount of time.
  3. Just like component maintainers are free to reopen the tickets closed, they are also free to leave them closed. But, the closed tickets should be scrubbed to make sure that no important tickets were closed accidentally.

Those in the component maintainer role would discuss these options in their component meetings or Slack rooms and reach a decision of what path works best for them.

The actions chosen for each component should be communicated in the component’s weekly meeting summary and in the comments below. The plan should also be clearly communicated in the form of a comment in Trac if the tickets are reopened.

If a component wants to reopen their tickets but needs help scrubbing the list, include that in your comment below and a plan can be created for going through the list. The three components without active maintainers (Filesystem API, Pings/Trackbacks, Rewrite Rules) will have the closed tickets scrubbed by myself (@desrosj) and other members of the Triage Team (once it is fully formed) to ensure nothing important was closed.

The correct way to reopen tickets for the components that wish to do so will be communicated once it is determined. The best way forward will depend on the feedback on this post and from component maintainers. But, this could be one of the following:

  • Bulk edit to reopen component by component.
  • Trac database query to reopen, remove resolution, comment.

More Details

Below is a summary of the number of closed tickets grouped by component:

  • Administration: 118
  • Autosave: 7
  • Bootstrap/Load: 18
  • Build/Test Tools: 27
  • Bundled Theme: 10
  • Cache API: 16
  • Canonical: 30
  • Charset: 6
  • Comments: 63
  • Cron API: 11
  • Customize: 49
  • Database: 34
  • Date/Time: 11
  • Editor: 76
  • Embeds: 12
  • Emoji: 2
  • Export: 24
  • External Libraries: 13
  • Feeds: 17
  • Filesystem API: 24
  • Formatting: 100
  • Gallery: 16
  • General: 172
  • HTTP API: 17
  • Help/About: 6
  • I18N: 28
  • Import: 36
  • Login and Registration: 54
  • Mail: 18
  • Media: 163
  • Menus: 77
  • Networks and Sites: 40
  • Options, Meta APIs: 40
  • Permalinks: 53
  • Pings/Trackbacks: 15
  • Plugins: 53
  • Post Formats: 4
  • Post Thumbnails: 4
  • Posts, Post Types: 151
  • Query: 69
  • Quick/Bulk Edit: 24
  • REST API: 5
  • Revisions: 13
  • Rewrite Rules: 37
  • Role/Capability: 17
  • Script Loader: 25
  • Security: 14
  • Shortcodes: 18
  • Taxonomy: 73
  • Text Changes: 13
  • Themes: 73
  • TineMCE: 56
  • Toolbar: 12
  • Upgrade/Install: 80
  • Upload: 25
  • Users: 102
  • Widgets: 59
  • WordPress.org Site: 3
  • XML-RPC: 27

Feedback

Do you have more to add to the discussion? Concerns with the proposed plan above? Please share them below!

#core, #trac

PHP Site Health Mechanisms in 5.1

Update: A few critical naming changes have been made regarding the fatal error protection since the post was originally published. Most importantly, the drop-in to override the new shutdown handler is now called fatal-error-handler.php, and the class to override is called WP_Fatal_Error_Handler. Furthermore, a new WP_DISABLE_FATAL_ERROR_HANDLER constant allows entirely disabling the feature via wp-config.php. The rest of the post is also updated to use these new terms, however you might need to update your code if you built anything based on the previous information. For a history of what exactly has changed since the original post date, please refer to the umbrella ticket #44458.


WordPress 5.1 will start showing notices to administrators of sites that run on long outdated PHP versions. This part of the Servehappy and more globally Site Health projects paves the way to a more secure and performant web and, more specifically to WordPress, to a bump of the minimum required PHP version.

The current threshold for which PHP versions to display the notice will be anything below 5.6. While the lowest PHP version still receiving security updates is currently 7.1, the idea is to not go all the way there at the beginning to limit the support load. PHP 5.6 is the intended version to bump WordPress requirements to, and from then the threshold for the PHP notice will increase granularly, with the goal to over time catch up with the actual PHP version progress. The threshold is managed via a new Servehappy API endpoint on wordpress.org, so the version numbers can be modified independently of a WordPress release.

Warning about outdated PHP version in WordPress backend

The link from the button points to a new support page about updating PHP which briefly explains the problem and then dives into how to prepare for an update and perform it. The link URL in WordPress is a translatable string so that locales can provide their own versions of the page. In order for that process to be straightforward, the content is managed through a page template, with the translation strings thus being available in GlotPress (see https://meta.trac.wordpress.org/ticket/4004). Furthermore, the link can be adjusted via either an environment variable WP_UPDATE_PHP_URL intended for hosting providers or a filter wp_update_php_url for a more dynamic approach on the code level. Replacing the URL should happen in cases where a more specific guide to update PHP on the given environment exists. The hosting provider is the preferred source to set this, so plugins are recommended to honor this priority and not unconditionally override it. Furthermore, if the URL is changed in any way, the URL to the original WordPress resource is still maintained as an additional link, which you can see in the following screenshot:

Warning about outdated PHP version with custom URL and related annotation

For further background information on these changes, please refer to the respective tickets #41191 and #45686.

Fatal Error Protection

To help the process of recovering errors that result from updating the PHP version, a mechanism has been implemented to detect fatal errors and, in certain designated areas of WordPress, recover from them. While updating PHP is mostly fairly straightforward and popular plugins and themes are typically maintained well, not necessarily all extensions are compatible with the latest PHP versions yet. So unfortunately there might be cases where a plugin or theme causes the WordPress site to no longer be accessible after the PHP update by causing a fatal error.

With the so-called WSOD protection (white-screen-of-death protection), WordPress will recognize when a fatal error occurs and which plugin or theme is causing it. When accessing the admin backend, the respective extension will be paused, allowing users to still log in to their site so that they can (at least temporarily) fix the problem. Once the extension is known to be fixed, it can be resumed from the backend. While this does not necessarily make updating PHP easier, it lowers the burden of possibly running into the case where you are completely locked out of your site when you do not have access to the codebase.

Extensions are only paused in the admin backend and a few other areas while for example the frontend stays unaffected, and thus broken. Since it is impossible to predict which functionality the broken extension is responsible for, it would be dangerous to have it disabled in the frontend. It is more clear to a user accessing the site to see a message that it is currently not accessible rather than, without notice, no longer having access to a certain part of the key functionality. In the frontend, a message that the site is currently inaccessible will be displayed via a regular wp_die() call, with a link to the admin backend. Sites that would like to modify this output can use a new php-error.php drop-in that should send the necessary HTTP header as well as the output.

Default output in the frontend when WSOD protection detects has detected an error

Note that, while the primary reason for implementing the fatal error protection mechanism was making the process of updating PHP less “dangerous”, it is technically not tied to the update at all. In fact, it will be enabled permanently and discover fatal errors under any circumstances.

For sites that prefer to alter this behavior or sites that would like to omit the WSOD protection altogether, it is possible to add a new drop-in file fatal-error-handler.php. That file should declare a custom shutdown handler class for treating fatal errors that extends the default WP_Fatal_Error_Handler, and then return the instance of it to use. The default class’s functionality is split into distinct methods so that it is easy to reuse and override as granularly as necessary in a child class. The functionality can also be disabled entirely if that is preferred, via a new constant WP_DISABLE_FATAL_ERROR_HANDLER or, more dynamically, a corresponding wp_fatal_error_handler_enabled filter.

For further background information on these changes, please refer to #44458.

Honoring Plugin PHP Version Requirements

When browsing plugins to install, WordPress 5.1 will display a warning for those plugins that require a higher PHP version than the one currently active. While that screen previously already included such information about WordPress version compatibility, it now does the same for PHP. Furthermore, for both of these potential issues, WordPress will now enforce these requirements, disabling the button to install such plugins.

This is only a first step in enforcing version requirements of plugins and themes. In a future WordPress version, these restrictions will expand also to updating or activating plugins and eventually cover themes as well.

For further background information on these changes, please refer to #43986.

#5-1, #dev-notes, #servehappy

New Styling for Admin Table Pagination Links in WordPress 5.1

In WordPress 5.1 the admin table pagination links have had their CSS styling modified.

New styling of admin table pagination links in WordPress 5.1

This CSS change improves the color contrast ratio for better accessibility and improves consistency across the admin screens. The pagination links are now styled like the standard WordPress buttons. By default, they have a lighter background color. The background color will no longer change to blue on hover and focus.

Plugins and themes should not be affected by this change unless they are re-using the .tablenav and .tablenav-pages CSS classes. All plugin and theme developers should verify that this change does not affect them.

You can read more information about this change in the related Trac ticket, #41858

#5-1, #dev-notes

How to get involved in Gutenberg Phase 2

Having trouble figuring out how to get involved in the Gutenberg Phase 2 effort? Understandable! There are a lot of teams (and channels and blogs) to keep up with. This post will help you find the posts that are helping to define upcoming work as well as identify the places you can follow the conversation.

Development Information

Now that the 5.0 ship is sailing, it’s time to start looking at the second phase of Gutenberg. The 9 projects for 2019 include a few items we’ll be working on in Phase 2:

  • Creating a block for navigation menus.
  • Porting all existing widgets to blocks.
  • Upgrading the widget-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.

Work on these projects will continue throughout the year. An overview of tasks included in the current scope and features is outlined in this Github issue. It is a living document that evolves as progress is made toward achieving these goals.

Design Information

The second phase of Gutenberg required a lot of initial user research. Synthesizing this research is happening now.  Details about how to get involved with this effort are outlined in this post.

Work on the research and subsequent design will also continue throughout the year. Regular updates will be shared on the Design P2.

Getting involved

While user research is in progress, there are a lot of development tasks that we can work on without additional design information. This includes improvements for phase 1 features, porting widgets to blocks and a lot more, as outlined in the “Actionable items” section of the Github issue linked above.

The main place to get involved is the Github repository. The #core-editor Slack channel is where developer coordination and live day-to-day discussions happen. The weekly developer meetings are held Wednesdays at 14:00 UTC.

Each meeting will have an agenda posted beforehand, so you can see if the topics up for discussion are relevant to your interests. Once completed, meetings will be summarized in a post, so that people who can’t participate synchronously, can catch up and comment asynchronously.

If you want to contribute to Phase 2 and still have questions about how to do that, please ask your questions in a comment on this post so we can make this resource even more useful!

#gutenberg

New REST API Notice in 5.1

Edit: On January 14, 2019, the Good and Bad Practices section was added to show both correct and incorrect code examples.

Starting in WordPress 5.1, if register_rest_route() is not called on the rest_api_init action hook, a “doing it wrong” notice will be triggered. This notice is being added in an effort to encourage best practices when registering REST API endpoints.

First, let’s look at what happens when WordPress loads to set up the REST API and explore a few reasons why this pattern is beneficial.

REST API Bootstrap Process

WordPress does its best to ensure that the REST API is only loaded when a REST request is being performed. To do this, the rest_api_loaded() function is run on the parse_request action and checks for a value in the rest_route query argument. This argument is populated with a value when the Rewrite API matches a WordPress REST API URL. When a value is present, the rest_get_server() function is called to instantiate the WP_REST_Server class, store it for use across WordPress, and to run the rest_api_init action hook.

Performance

When register_rest_route() is called, it invokes rest_get_server() to retrieve the global WP_REST_Server instance created in the bootstrap process. But, if the instance has not been set up yet, it is instantiated then and the rest_api_init action hook is run. This means that every function added to the rest_api_init hook will fire at that time. This could result in a large performance hit.

For example, say register_rest_route() is called on the init action, or, just called in a theme’s functions.php file. The REST API server would be set up for every WordPress request, even those that are not actually aimed at the REST API.

Missing Endpoints

If register_rest_route() is called too early, it’s also possible that endpoints will go missing and never be registered. This happens when other plugins are not given the chance to register their rest_api_init hooks.

For example, say register_rest_route() is called directly in an mu-plugin file. This will cause the REST API to be set up before regular plugins are run, so their rest_api_init hooks will not be registered.

Good and Bad Practices

Let’s look at a few code examples and detail why they are good or bad.

Bad Practice

register_rest_route(
	'hello-world/v1',
	'/phrase',
	array(
		'method'   => 'GET',
		'callback' => 'myplugin_get_endpoint_phrase',
	)
);

In this example, register_rest_route() is called directly in a file without being attached to an action hook. This means the function will be called as soon as the file is loaded by WordPress. All of the potential issues detailed above are possible, and a _doing_it_wrong() notice will be triggered.

Good Practice

function myplugin_register_endpoints() {
	register_rest_route(
		'hello-world/v1',
		'/phrase',
		array(
			'method'   => 'GET',
			'callback' => 'myplugin_get_endpoint_phrase',
		)
	);
}
add_action( 'rest_api_ini', `myplugin_register_endpoints` );

In this example, register_rest_route() is correctly placed inside of a function that is added to the rest_api_init action hook. It will only execute when the rest_api_init action hook is executed. The potential issues detailed above are avoided, and no _doing_it_wrong() notice is triggered.

Changes Required

Plugins and Themes

All plugins and themes should double check that their REST API endpoints are being registered correctly using the rest_api_init action hook. This best practice is also mentioned in the Routes and Endpoints section of the REST API Handbook. If this was a resource used when developing, chances are you won’t have to change anything!

Unit Tests

Because some unit tests require custom endpoints to exist, it is not uncommon for a test method to call register_rest_route() directly. If a test method calls the function before rest_api_init, a previously passing test method may now fail. This can be fixed in two ways.

The first way is to use rest_get_server() to create the WP_Rest_Server instance for your tests. Since rest_api_init is run within that function, this will prevent the notice. This approach can be seen in the Tests_REST_Server class. The wp_rest_server_class filter still allows you to replace the default WP_Rest_Server class with your own for testing purposes with this method.

The second way is to call do_action( 'rest_api_init' ); directly in your test method or setUp() method. This method is for scenarios where complete control is needed over the REST server setup process. This can approach can be seen in the Tests_REST_API class.

You can read more information about this change in the ticket on Trac.

#5-1, #dev-notes, #rest-api

Site Health Check Project review at WCUS

This is a verbose set of notes to record the discussions that took place at WCUS and to reflect the work that has been done across multiple teams.

The Site Health Check project is a collaborative multi-team project with a focus on encouraging better site maintenance.

This project benefits not just WordPress users, but also the surrounding PHP ecosystem as a whole. Our hope is that this will prompt a lot of PHP updates across the web.

It started as a project to focus efforts on getting users to update their hosting version of PHP from 5.2 to something where the End of Life has not already passed.

The project was initially called ServeHappy, homage to the BrowseHappy project which was a global tech effort to move away from Internet Explorer 6. The problem with the project name was that, when tested with users who did not know about the ins and outs of the project, the name was confusing and was not clear what the project’s intentions were.

The project is now known as the Site Health Check project. It encourages and hints to users that if they run a website, they should have a routine of checking and updating not just WordPress but underlying technologies that the site is built on. It also builds positive website ownership and habits.

The project is split into what can be considered 3 parts – changes to WordPress core itself, a site health check plugin and the site health check community support.

Upcoming changes to WordPress Core

The core-centric side of the project still reflects the Servehappy origins. This includes:

  • An information page on WordPress.org explaining the importance of updating PHP. The team has been working on improving the language used to benefit non-technical people and have clear instructions of what to do if they find out their site is running an old version of PHP.
  • A dashboard notice that will inform users if their site is running on a PHP version that WordPress considers outdated and plans to drop support for in a future update.
    • The version shown in the dashboard is API-driven which means that WordPress leadership has a centralized “knob” to tune the PHP version distribution.
    • The dashboard includes a link to wordpress.org/support/update-php which has generic information on what the notice means and how to update PHP on their servers.

  • There will be an environment variable or a filter which allows hosting companies to modify the link to the “Update PHP” page on their servers so that it goes to something more relevant for their customers.
    • There are some concerns of security problems and abuse over the link redirection.

  • The team has been working on a feature to add white screen protection, which the hosting group felt was helpful and cool. The white screen protection catches any fatal errors that a PHP update might produce. From the front facing side of the website, the site will still be white screened, but with the protection in place, the user can still access the admin panel.

  • There was a discussion whether it would be better for the site to be slightly broken rather than completely broken, but the general consensus was that it is better to white screen because from the Core Team perspective, they cannot be sure of what the PHP error causes, and thus can’t be sure that all the information being shown is meant to be public.

    It is better to white screen the whole website but ensure that access to the admin panel is still accessible. Once logged in, there will be a general notification regarding the WSOD.

PHP minimum required headers

Plugins

For a while, WordPress plugins have been able to set a minimum PHP required comment as part of the plugin header. To date it has not done anything but set the intention that the plugin author is able to declare what PHP minimum version they are willing to support.

Work is being done so that the Add New Plugin admin screen will show all plugins a user searches for, but will not be able to install any plugins that require a newer version of PHP without updating that first. Another task being worked on is blocking plugin updates if the newer version requires a higher version of PHP, same as it currently works if the update requires a higher version of WordPress.

This gives plugin authors better control of what PHP versions they are willing to support, and will hopefully encourage people to upgrade their version of PHP at the same time.

This change will allow plugin authors the choice to use more modern PHP functionality and syntax without worrying their plugin will break for the end user.

Themes

For themes, the Requires PHP header is not implemented yet, as they didn’t have the same readme.txt file up until recently: https://make.wordpress.org/themes/2018/10/25/october-23rd-theme-review-team-meeting-summary/

Now that new themes do have that requirement, there is an expectation that the header will be implemented as well in the foreseeable future. Here’s a ticket for that: #meta-3718

Relevant Trac Tickets

  • #43986 Disable “Install Plugin” button for PHP required version mismatch. This has already been committed to core.

  • #43987 Block plugin updates if required PHP version is not supported – Plugins screen

  • #44350 Block plugin updates if required PHP version is not supported – Updates screen

The latter two trac tickets are currently slated for 5.1 as well, planned for February 21: https://make.wordpress.org/core/5-1/

The feature merge deadline is January 10 though, so it needs to be discussed at the next #core-php meeting whether making it into 5.1 is still feasible.

A prerequisite for these changes is the WSOD protection that needs to be completed and committed by the deadline: #44458

Join in

The group has weekly meetings on Mondays 16:00 UTC on in the #core-php channel of WordPress Slack.

GitHub: https://github.com/WordPress/servehappy

Site Health Check Plugin

The site health check plugin is a way for users to be able to see technical details of their website setup without going into the server side of things. It is useful to conducting top level investigation work without accessing the server directly.

The beta version of the plugin takes the best practices from the Hosting Team’s documentation and checks the server against that. This includes: WordPress version number, plugins and themes are up to date, PHP version number, if HTTPS is active across the whole site as well as a number of other things.

When Health Check gives notifications about upgrading things, it hands users off to plain English documentation to walk them through the process. For example: https://wordpress.org/support/update-php/. Notifications for plugins and themes being up to date are based on the version inside the plugin and theme repo. If a theme or plugin is not present in the repo, it will assume it is up to date and will not give an error.

Eventually, a lot of the Site Health Check plugin will be in core.

The Site Health Check Plugin uses a traffic light system to flag up the importance of a suggested change. The definition of critical vs non-critical update notifications is from a security perspective. If it is a security issue, it’s critical.

Early user testing with the community has shown that the plugin suffers from a lack of designer eye. During WCUS, we have had a designer volunteer to review the interface and give feedback.

This should help with the usability of the plugin and balance it between positive reinforcement of things that are set up as guided by best practices whilst not over-burdening people with extra technical information.

There is some useful documentation on how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

Join in

– Github: https://github.com/wordpress/health-check

– WP.org : https://wordpress.org/plugins/health-check

Site Health Check Desks & Community Support

In-person support is invaluable. When a user is unsure of what to do, they can find in-person support at their local meetup and WordCamps. To omit any surprises, we can encourage our community to pre-warn and prepare as many people as possible.

The idea of Site Health Check desks has been tested in 3 different WordCamps and 1 meet-up with improvements and suggestions being fed back to the plugin and fliers.

Site Health Checks is an extension of the Happiness Bar, and by asking the simple question “Do you know what version of PHP your website is running?”, people either:

  • Know & it is up to date – get a high-five. Say Awesome and keep up the good work. Pre-warn the next EOL of PHP Dates.
  • Know & it is out of date – highlight the EOL date has already passed and recommend they update their PHP version.
  • If they don’t know, Check if they know how to check. If they do, suggest that they check and that they want it to be 7.2 or higher. 7.1 EOL is in a year.
  • If they don’t know and don’t know how to check, invite them to sit down and the volunteers can help them check using the Site Health Check plugin. DO NOT scrape the site. They can end up being blocked off the servers.

Postcards were created with 5 core things to check. As well as printable table toppers. They are used as fliers for people to know where to download the site health check.

Meetup organisers have also shown an interest in running the site health check and promoting it at their meet-ups.

This is where much of the user testing of both the “Update PHP” information page and the Site Health Check plugin is happening.

Plugins and Themes Plans

Plugins and Themes served from WordPress.org can be automatically checked and updated to be compatible with 7.X. This is because there is access to the SVN where these plugins are being pushed from.

Ideally, plugin authors who have a plugin in the plugin repo will update their plugins to be compatible with PHP 7.X. There are already plugins such as the PHP Compatibility Checker which people can use to check how compatible their websites are with a version of PHP.

How are premium plugins and themes going to be handled?

The plugin team at WordPress.org can contact authors, but ultimately it is up to the plugin author to action the suggestions that are made from the WordPress.org team.

If there is no answer, or the author does not wish to fix errors, then this is a dead end.

Target Dates

WordPress 5.1  ->  ServeHappy notice + White Screen of Death protector

WordPress 5.2 ->  Site Health Check plugin

Where hosting companies come into play

We would like hosting companies to go aggressively, pushing their communities forward before WordPress does.

We know that, as a hosting company, many of you will see the same issues come up during a PHP update. It would be useful to the rest of the group if any information of any PHP errors that are being seen repeatedly and information about which plugin or theme is causing it. It will allow the rest of the team to prioritise which plugins and themes need attention to be fixed across the whole community.

It will also help the support team if any solutions are found to be shared, so that they know what to be suggesting in the forums. We may be able to add notices before a PHP update into the health check which highlights problematic plugins.

Hosts with PHP lower than 5.6 may see some initial notifications before that date.

Hosting company teams are most likely to know other people working in the hosting sector. Above all else – get the word out.  Big hosts are represented well here, but as a community we are aware and worried about the smaller, independent hosters. Talk to your hosting friends. Let them know this is coming. Invite the small hosting companies to join the Hosting Team on WordPress.org for up to date information of what is upcoming and will be effecting hosters.

The more we can update in batches the less burden there is across the whole industry.

Where plugin and theme authors come into play

If plugin and theme authors ensure that their plugins have a PHP minimum version set in their required header, then their plugins and themes will be ready once the PHP requirement is being enforced.

Plugin and theme authors should also ensure that their plugins are compatible with PHP 7.X. Tools such as PHP Code Sniffer (PHPCS) or the PHP Compatibility Checker as mentioned above should help.

Actions from the meeting

– Ensure there is communication with the hosting team regarding release date plans.

–  #core-php should be cross posting ServeHappy notes to the Hosting P2 as well.

– WordPress.hosting has been taken, unsure by who. It would be handy to have WordPress.hosting symlink to Hosting Team P2 to help getting other hosting companies to join the Hosting Team

– Recommend that Hosting Team check and sync up the Best Practices documentation.

– Can someone from the hosting team please review and ensure that Health Check plugin is checking against everything that exists in the “Hosting Best Practices” doc.

– Recommended to Health Check plugin to check out Lighthouse plugin UI.

– Write up more in-depth info for meetup and WordCamp organisers, have postcard and table toppers online so they can be shared and translated easily.

Thanks

The effort to raise the minimum PHP version requirement of WordPress is a big cross- team effort. Big thanks to

  • @brettface for the notes.
  • #core-php, #plugins, #themes and #meta team for their hard work
  • the #hosting team for their input and support
  • @alexdenning from #marketing team for the content review
  • @clorith from #forums for the health-check plugin development
  • WordCamp London 2018, WCEU 2018 and WordCamp Brighton 2018 organisers for allowing us to test the Health Check help desk concept
  • And to the #polyglots team who will be asked in the near future to translate our work for the whole community.

#recap, #servehappy, #wcus

Dev Chat Summary: January 9

Thanks for everyone that attended, you can catch the archive here.

5.0.3 updates

5.1 updates

  • Beta 1 coming on Jan 10. Ticket list here to close or punt before then.
    • Aiming for 2000-2200 UTC, give or take.
  • Help is needed right now for triaging that list. You can help get 5.1 to beta, a great start is by reviewing tickets here.
  • There has been a change with PHP-FPM detailed here. @pento made a request for hosts to test this change.
  • @matt is leading with @pento as deputy for this release.

Updates from focus leads and component maintainers

Editor

  • New release of Gutenberg.
  • There is also some early discovery/ideation of phase 2 boundaries starting here.
  • Conversation on the design/research side here.

Media

  • Still working on identifying places to remove cruft and also some excellent work on clearing up tickets in preparation for 5.1.

JS

  • Planning for 2019 got started along with a discussion of auditing existing documentation for accuracy.

Open floor

  • Action requested on discussion of tackling lingering Trac tickets. Please share your thoughts.
  • The bulk edit that happened last week, was not based on the proposal in the post by @desrosj.
  • The triage team will be writing a post to start discussion of best practices soon and how to get involved.

#dev-chat #summary

Editor chat summary: January 9

Gutenberg 4.8

  • Gutenberg 4.8 is released and in WordPress 5.0.3. For the full list of change refer the release post.
  • This release was focused on bug fixes and performance improvements which are included in WordPress 5.0.3.
  • Due to the small gap between 5.0.3 RC and 5.1 beta, Gutenberg 4.8 will be included as is in WordPress 5.1.

Release schedule

  • A new release schedule was proposed:
    • Automatically release a new plugin version every 2 weeks with what’s already available on the master.
    • The remaining PRs in the milestone will automatically be moved to the next release.
    • Build a zip and do a call for testing on Monday, release on Wednesday
    • This will bring more clarity to the schedule and less stress for contributors.
  • There was also a discussion to remove the RC period for the plugin, but no decision reached.

Phase 2 Scope and features

  • There is an issue starting to outline the scope for Phase 2.
  • One of the focus areas for Phase 2 is “widgets 2 blocks“. There are a bunch of PRs that require reviews and may development. Would be great to get some contributions there for those looking to help.
  • An ‘async mode’ has been introduced to batch state updates and improve the performance of the editor with long content. As part of this, there is a structural change to the data module, everyone is encouraged to test for regressions with their custom blocks
  • There is proposed a ‘Generic block editor module’, to build a post agnostic editor. This will make it easier to embed Gutenberg in other places, such as widgets screens.

Open floor

@chrisvanpatten temporarily steps down from Gutenberg docs lead due to personal priorities and @dryanpress will step up instead.

The meeting archive is here.

The agenda for the next meeting is here, please add anything you want to discuss.

#5-0-3, #meeting-notes, #editor-chat

#docs