PHP Meeting Recap – February 26th

This recap is a summary of our previous PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • The agenda for the meeting was to discuss the 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. endpoint for which a first version was introduced the previous week.
  • It was ensured that the endpoint parses PHP versions correctly and allows for flexibility by parsing out the actual version number from strings which may contain additional environment-specific information.
  • Some concerns regarding the structure of the response were expressed, particularly related to redundancy, future maintainability and inconsistencies.
  • By the end of the meeting, it was agreed to go with the following response structure:
    • recommended_versionstring – The PHP version recommended by WordPress
    • is_supportedboolean – Whether the PHP version is actively supported
    • is_secureboolean – Whether the PHP version receives security updates
    • is_acceptableboolean – Whether the PHP version is still acceptable for WordPress
  • It was also decided to remove all IP address-related functionality, as it is unlikely that those will be needed in the future. Detecting hosts by IP address and maintaining host-specific data via the API would be a huge maintenance burden, and additionally passing the IP address would overcomplicate the current efforts by having to deal with possible privacy concerns.

Call for Testing

Since the meeting, the API endpoint has been updated to use the aforementioned response data structure, and an updated 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. for the PHP nag in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., implemented as a 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. like previously decided, is ready to be applied.

Please thoroughly test the API endpoint and patch. The API is already live, and the current plan for the patch is to commit it to core next week.

  • The API endpoint is available at, and it requires a php_version query parameter to be passed.
  • The patch for the core nag is available at, making use of the API endpoint. When applied and your installation is not on PHP 5.2, you can “simulate” the behavior by going into the src/wp-admin/includes/dashboard.php file, looking for the wp_check_php_version() function and temporarily hard-coding ‘5.2’ in there instead of the actual PHP version. For the related ticketticket Created for both bug reports and feature development on the bug tracker., see #41191.

Next week’s meeting

  • Next meeting will take place on Monday, March 5, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the patch for the core nag.
  • 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.

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