Agenda for September 7th Site Health meeting

The Site Health meeting will be held on Monday September 7th, 2020, 16:00 UTC in #core-site-health on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. (a Slack account is required)

Meeting schedule / frequency

As we’re a rather small group, holding weekly meetings has proven to be a bit difficult with time management, let’s consider getting a fixed schedule with bi-weekly (or whatever is more appropriate) meetings instead.

WordPress 5.6

With work on WordPress 5.6 underway, let’s take a look at what we wish to accomplish with this release, and what our focuses should be.

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 version support schedule

Please have a look at the proposed schedule for supporting older PHP versions, there are many comments which bring up a lot of valid points.

Let’s discuss next steps on how the team can help with the proposed schedule, and discuss the pain-points that were brought up and how these could be addressed.

#site-health

Agenda for May 11th Site Health Meeting

The weekly Site Health meeting will be held on Monday, May 11, 2020, 16:00UTC in #core-site-health on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. (a Slack account is required)

During this past weeks dev chat, the item of moving the minimum PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 compatibility up further this year was brought up as a talking point. This will need a collaborative push to move towards. The desire target this time is PHP 7.1 as the minimum supported version, but to do so we will need to come up with a more effective way of encouraging users to do the upgrade.

At the time of writing, WordPress 5.2 or newer require PHP 5.6 to work. On top of that ~25% of all sites running these versions (WordPress 5.2, 5.3 and 5.4) are using PHP 7.0 or lower, that’s too high a number for us to bump the minimum required PHP version to where we want it.

The ServeHappy dashboard widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. alerts users with PHP versions lower than 7.0 at this time. An initial step here would be to increase that threshold to 7.2, the currently most popular version. The team is aware that PHP 7.1 is already EOL (End Of Life), and that 7.2 will be the same come January 2021 (See list of supported PHP versions), but this is a marathon so we are taking it in small leaps to not cause unintended disruptions to the userbase.

That said, the dashboard notice likely won’t be enough for a PHP version push this year, that’s why this upcoming meeting will be focused on brainstorming ideas on other approaches that will help this endeavor, as we will have the upcoming WordPress 5.5 release to implement any changes needed to help move towards the goal.

#agenda, #site-health

Site Health January Review

This is a summary post for Site Health meetings held in January.

🎯 Focuses for 2020

A few focuses have been outlined for WordPress 5.4, and they are currently on track.

Surfacing the Site Health status with a dashbaord widget has its initial iteration committed, and aims to help inform and educate users and continue one of our purposes of helping keep websites running as smoothly as possible and being good internet citizens.

Another goal is to get compatibility checks for PHP version into themes, which is also in the review phase and is looking on schedule for this years roadmap.

Improving the Recovery Mode is our third focus. Current tickets focus on alternate ways to access recovery mode, and improving its performance in general.

🎫 Ticketticket Created for both bug reports and feature development on the bug tracker. triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. to align our selves

We also held a short-circuit ticket triage on Friday January 31, 2020, 16:00 UTC to make sure all the current planned tickets for the next upcoming WordPress release, 5.4, were on track and moving as expected.

This let us re-prioritize some that were no longer required, as they were superseded by other tasks that were already completed, and also gave better insights into remaining tickets that needed some direction.

🙌 Get involved

If you would like to improve the Site Health component, we’re always up for new ideas.

Here’s how you can get involved:

We look forward to seeing you all at our next meeting!

#site-health

REST API: Introduce dashboard namespace

Summary

We propose to introduce a dashboard REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. namespace prefix, for use on endpoints specifically relating to the WordPress adminadmin (and super admin) dashboard.

Motivation

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. currently contains two namespace prefixes: wp and oembed. These represent two separate APIs offered by WordPress: the general REST API which exposes structured WordPress data objects to external clients, and the OEmbed implementation.

The general design of WordPress distinguishes between the core, and the Dashboard “application” built on top of it. These two have not traditionally been formally separated, however the design and clean slate of the REST API allows us to consider these separately as we evolve the Dashboard.

With the push towards removing admin-ajax handlers in favour of new REST API endpoints, there are naturally APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. endpoints being introduced which are not useful outside of the administrative interface. Endpoints for Dashboard Widgets, pointers, and other features are specific to the Dashboard application, and are not broadly applicable to public-facing WordPress sites or third-party applications.

Introducing a new dashboard namespace prefix allows separating Dashboard-specific endpoints from the public WordPress REST API. This can also allow for future changes, deprecations, and new versions of the Dashboard API without requiring a version bump for the public REST API.

Detailed design

New endpoints for the Dashboard will live under dashboard/, initially with the namespace dashboard/v1 for the first version of endpoints.

Future iterations of the Dashboard that need to break API backwards compatibility can increment the version under the same namespace prefix as needed (e.g. dashboard/v2dashboard/v3). These new versions do not need to affect the public WordPress REST API.

This requires no code changes, as it simply designates the namespace for future use. The first endpoints to be added under this new namespace are expected to be the endpoints for Site Health (#48105) in WordPress 5.4.

How do we communicate this?

The new endpoints under the dashboard namespace prefix will collectively be called the Dashboard REST API to distinguish them from the public WordPress REST API.

There are no user-facing changes resulting from this proposal. Likewise, there is no effect on pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, theme, or API client developers.

The difference between wp and dashboard needs to be communicated to core developers working on the Dashboard and related features. The announcement of this RFC on the Make/Core blogblog (versus network, site) will serve as an initial announcement, but evergreen documentation should be added to the Core Handbook.

A new page will be added to the REST API Handbook under the “Best Practices” section, outlining design guidelines for new endpoints added to WordPress Core. The proposed text for this page is:

REST API

Core implementations of REST API endpoints should follow some simple rules to ensure WordPress provides a consistent public data interface.

Creating New Endpoints

Where possible, core features should use existing REST API endpoints rather than adding new ones. For example, a tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) search feature should use the existing tag collection endpoint in the REST API rather than building one specifically for the feature.

When a new endpoint is required, care should be put into the design of the external API. In particular, the shape and schema of the resource, the namespace, the route (URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org), and the available actions should match existing precedent in core.

REST API endpoints intended for public use and which represent “core” features of WordPress should be under the public REST API namespace (wp/v2). Endpoints which are only applicable for the Dashboard (e.g. Dashboard Widgets, pointers, or other UIUI User interface settings) should be under the Dashboard REST API namespace (dashboard/v1). This ensures a clear distinction between APIs for general consumption and APIs built for specific UI features.

The design and implementation of the endpoint can be checked by the REST API team before committing to ensure it is consistent with the rest of the API. This helps us provide a more consistent experience for API consumers.

Drawbacks

Introducing a new core namespace could impact third-party plugins or other code which uses the same namespace string. This represents a minor backwards compatibility break, and investigation needs to be done as to whether we’re breaking any major plugins with this change.

It could also be argued that it fragments core’s API surface to introduce an entirely new namespace. Making the distinction of which namespace to use is tough, and this might lead to features that could have general applicability existing only as part of the Dashboard API, without a public API for use by external clients.

In addition, adding a new namespace opens the question of whether more even namespaces are needed. For example, should there be a CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. namespace? Do other features need their own namespaces as well?

Alternatives

There are a few main alternatives to creating a dashboard namespace prefix.

The first is to use the current wp/v2 namespace for endpoints relating to administrative interfaces like Site Health. The main reason to avoid doing this is that it couples Dashboard-specific features to the public REST API. These features are rarely applicable or usable outside of the Dashboard application, especially in third-party plugin interfaces or external clients. In addition, this would also tie Dashboard API versioning to the public REST API, which could lead to the public REST API version being needlessly bumped for Dashboard-only changes.

Another alternative is to use a sub-namespace prefix of the existing wp prefix, such as wp/dashboard. This avoids any risk of impacting existing plugins as wp is already known to be reserved for core. However, this breaks the current precedent of <prefix>/v<version>, increasing the complexity of API namespacing. Given that it is unlikely that the dashboard prefix is currently being used, the simpler option of dashboard/v1 is preferred. This also discourages a proliferation of sub-namespaces under the wp prefix.

The final alternative is creating a separate namespace for each feature, such as site-health/v1. This could have the advantage of making endpoints more discoverable, and would reduce the overall length of each endpoint’s URIs. A dashboard prefix may also imply that its endpoints are “private” to WordPress and specific to the WordPress display context in cases where future endpoints may be useful in third-party tools. This approach has the disadvantage that plugin developers may worry that any namespace they pick could eventually be reappropriated by WordPress core.

Unresolved Questions

  • Should we use admin/v1 or dashboard/v1? To some dashboard is unclear and meaningless, to others admin is very specific to wp-admin whereas dashboard is more general idea of management.
  • Should we use dashboard/v1 or wp/dashboard/v1? The former could potentially clash with plugins, and is much more generic. We also need to pave the way for further namespaces that may be added to core in the future, where clashes may be more common.

Originally written by @rmccue as a WP-API Proposal.

#5-4, #rest-api, #site-health

Increasing the recommended PHP version in core

The recommendation to update your PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 for users running version 5.6 or lower is scheduled to go live on August 20th, 2019.

A few weeks back, we outlined the plans to continue the work that was begun around WordPress 5.1 on increasing the PHP version recommended (and subsequently required) by WordPress.

Now that feedback has been gathered from multiple venues, both on various make blogs, and different team chats to spread the word about these blogblog (versus network, site) posts, it’s time to start acting on them.

We had originally wanted to push the changes out sooner, but will admit that with mass holidays happening during the start of August, this fell through.

That said, the plans are now in motion, a meta ticket has been created to keep things on track, and the bump is scheduled for August 20th, 2019.

#site-health

Proposal for increasing recommended PHP version in WordPress

I would like to propose we trigger displaying the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 update widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. for users of PHP 5.6 in WordPress.

At the time of writing, the WordPress stats show that:

  • PHP 5.6 has a usage share of 29.1%
  • PHP 7.0 has a usage share of 16.2%
  • PHP 7.1 has a usage share of 13.2%
Pie chart showing the usage share of each PHP version used by WordPress sites.

This proposal is based around multiple discussions in Hosting Team meetings, a P2 post and within core-site-health conversations.

A majority of respondents have suggested increasing the minimum requirement to PHP 7.2. The site-health maintainers agree with the sentiment but we would like to get to that point by introducing a series of incremental increases over the remainder of 2019.

When?

Our suggested roadmap to increase the minium PHP version is:

  1. Display the PHP update widget for PHP 5.6. This will trigger the widget for anyone using PHP 5.6 or below and WordPress 5.1+ in their dashboards warning them of the fact we recommend upgrading the version of PHP.
  2. Display the PHP update widget for users of PHP 7.0 and below.
  3. Based around support and stats of points 1 and 2, have a discussion about whether the next step should be displaying the PHP update widget for PHP 7.1 or a direct increase of the required minimum version to PHP 7.2.

We suggest to start showing the update recommendation for users of PHP 5.6 or lower starting August 5th, the timeline for showing the warning to PHP 7.0 users will be announced in a followup post, and relies on factors like support load, and adoption rate from the previous increase.

Why the PHP update widget?

In discussions, multiple people have highlighted that many sites do not update plugins and themes due to paywalls. In some circumstances it can mean their version of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme is not compatible with more modern versions of PHP. This is especially the case for many popular premium plugin and theme users.

We hope that the PHP update widget will encourage users to update all their plugins and themes, incluing all premium ones. By doing so, their PHP migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. at a hosting level would go much smoother, and help pave the way for raising the minimum requirements of WordPress further in a timely manner.

Another reason for going in with the update widget first is so we are able to drip feed the support requests for the multiple teams which have to handle the support for changes like this. This includes but not limited to community, hosting, plugins, themes and support forumSupport Forum WordPress Support Forums is a place to go for help and conversations around using WordPress. Also the place to go to report issues that are caused by errors with the WordPress code and implementations. https://en.forums.wordpress.com/. teams.

Screenshot of the PHP Update Widget

Feedback welcomed

If you have any questions, suggestions, or comments, the #site-health conponent would be gratful if you comment on this post with your thoughts.

Thank you.

Site Health Chat Summary: July 8th

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 Version – soft bump

Note: The soft bump is the term referring to the PHP upgrade notice widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. shown in the dashboard, and not the minimum requirement to use WordPress.

The discussion on what version to start recommending users upgrade to is going on in the comments at https://make.wordpress.org/hosting/2019/07/01/what-should-the-next-php-version-recommendation-be/, but we also covered them a bit during the Hosting meeting this week.

Currently it seems the best approach would be to recommend updating to PHP 7.1 (skipping 7.0 as it’s technically not maintained any more), but we’ll leave the conversation going out the week, then make a decision on this next week. After a version has been decided on we make it known via posts to the make blogs what the intentions are, and what versions we are aiming for, and then make thew bump. This should allow hosts and developers some time to prepare for the potential support requests.

Ticketticket Created for both bug reports and feature development on the bug tracker. review

We covered a couple of tickets as well that were brought up by participants.

#47651 – This has been flagged for design feedback, as it needs a UIUI User interface/UXUX User experience perspective to help with direction and user flow.

#47644 – This has a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., but after some discussion it will need a refresh to help with making it a bit more friendly towards the average user.

#47321 – This had some initial discussions in the channel after the meeting, but during the meeting it was covered that it needs some copy-editing. The ticket will have the outcome of the copy-discussion added once a final decision has been made.

#46925 – The ticket is ready, but was unfortunately not reviewed yet. It will get reviewed this week, and we will hopefully be more on top of tickets now that they’re more easily categorized.

Read the meeting transcript in the Slack archives. (A Slack account is required)

#site-health

New Core Component: Site Health

During Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 2019, the newest WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. component was created, Site Health. After many months being tested as a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., Site Health was merged into WordPress core in versions 5.1 and 5.2. Below are several changes that were made during Contributor Day to help organize tasks and efforts around Site Health moving forward.

New SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. Room

The Site Health feature is just one tool that is empowering site owners and hosts to upgrade to more modern versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20. Because of this, most of the discussions around Site Health have happened in #core-php to this point.

However, now that Site Health is in WordPress Core, it’s time to give that Slack room back to the folks discussing how PHP is used in Core (upgrades to patterns, discussing guidelines, style guides, etc.).

All Site Health discussion moving forward will be held in the new #core-site-health channel.

Component Maintainers

The following people have played incredibly important roles in the Site Health project so far and were asked to be component maintainers. All accepted:

Action Summary

Here is a brief summary of the actions taken to facilitate this change:

  • A Site Health component was created in Trac.
  • A Site Health component was created and added to the Make WordPress Core Components page.
  • All open tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All open tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the site-health keyword were moved into the Site Health component (tickets effected).
  • All closed tickets with the servehappy keyword were moved into the Site Health component (tickets effected).
  • The site-health tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) has been created for this blogblog (versus network, site). All Site Health related posts will utilize this tag.

Note: The site-health and servehappy keywords are now obsolete and should not be used moving forward. but they will remain on old tickets.

#site-health