PHP Meeting Recap – May 21st

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 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 initial half of the chat dealt with the design of the “Upgrade PHP” page:
    • The design team had suggested improving overview of the page structure using either an accordion or a list of headings as a table of contents at the top of the page.
    • It was decided that the ToC (table of contents) functionality provided by the Handbook 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 would be a perfect fit. @clorith outlined that the HelpHub project (which is the upcoming new WordPress support platform) has this plugin included. With the target releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. set to the end of May, it is perfectly fine to wait that remaining time until we can enable it for the page. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ will also be enabled on the support platform by that date.
    • @flixos90 noted that the line lengths of the current version of the page are very long, making it difficult to read. @schlessera quickly changed the layout of the page by changing the page template, so that this problem could be solved immediately.
  • The rest of the discussion revolved around possible Gutenberg blocks to implement for dynamic and more targeted content on the page.
    • All Gutenberg blocks for dynamic content should be based on a GET parameter php_version being passed. If none is passed, either the respective blocks should not appear, or, where it makes sense, a fallback PHP version could be used.
    • Participants agreed on implementing a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that would be used as a dynamic headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. for the page, providing a prominent message such as “Your PHP version x.x is supported/outdated/insecure.”, based on the php_version passed. This block would not appear without the GET parameter present.
    • It was also agreed to introduce one dynamic section as a block, which would show different copy based on the php_version passed. The content of each of the three variants (supported/outdated/insecure) should be fully editable through the block editing interface so that it can be easily translated. Without the GET parameter, this block would not appear.
    • @joyously suggested enhancing the page content with a chart for more visual context. It was determined that a timeline of PHP versions and the current position of the user’s PHP version in it would be a solid approach. Without the php_version GET parameter present, this block would still appear, just without the current version’s position highlighted.
  • @afragen asked for feedback on his work with #43986 and #43987, which is something we should focus on very soon.

Next week’s meeting

  • Next meeting will take place on Monday, May 28, 2018 at 15:00 UTC in #core-php.
  • Agenda: Review whether there are new ideas for the content of the Upgrade PHP page, and discuss the approaches of @afragen‘s 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. and how to proceed.
  • If you have suggestions about this but cannot makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summary