PHP Meeting Recap – May 28th

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

• We started with discussing TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
• Questions we’ve distilled for that ticket:
  • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
  • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
  • Whether to use (colorized) icons or not
  • Whether to show current/required version numbers or not
  • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
• Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. behavior: while @afragen added actions to make the new blocking functionality extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software., @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
  After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
• @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

• We agreed that, although we could filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
• The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
• @MelChoyce collaborated with @afragen directly to produce a new version of the 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. that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:

Next week’s meeting

• Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
• Agenda: Continue work on the “Disable Install button” patch.
• 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