PHP Meeting Recap – October 2nd

This recap is a summary of this week’s PHP 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.

The meeting’s chat log.

Attendees: @flixos90 @jdgrimes @jpry @joostdevalk @garyj @mte90 @nerrad @schlessera @sergey @techjewel

Chat Summary

This meeting revolved around discussing the “Before Upgrading PHP” section.

First, we quickly brainstormed a list of possible actions we could recommend:

We later created an issue for each of these possible actions, and the above list links to these.

Then, we discussed in more detail how a non-technical site-owner could run compatibility checks, and in what ways we could automate this. There are two main directions that need to be evaluated: static analysis & runtime checks.

The static analysis can be done through the PHPCS library. There’s a usable plugin wrapper called “PHP Compatibility Checker” that already does all the required work of wrapping the PHPCS command line tool into a WordPress plugin and provide a neat user interface. However, this plugin currently contains a direct entry point into the sales funnel of WPEngine, the hosting company that funded its development. While this is just fine to refer people to on a personal basis, we currently consider this a show-stopper when it comes to officially endorsing this plugin, as it would mean that we’re sending existing customers from other hosting providers from within the admin backend they’re hosting to their competitor’s sales page. We decided we’d contact WPEngine to see whether they would be willing to collaborate on a “toned-down” version of the plugin.

[ NOTE: in the meantime, discussions with the hosting company responsible for the above plugin were very fruitful, and they are willing to change the plugin to defuse the sales message. ]

While we also discussed the merits of runtime checks when installing/updating plugins, we came to the conclusion that is is not reliably feasible, as it is not possible to reliably hit all possible code paths of a given plugin/theme in an automated manner.

We briefly went over the new “Required PHP version” information, and whether a “Tested up to PHP version” was already discussed. Most people think that this is not easily kept up to date and will lead to stale information. However, the possibility should be explored whether the statistics collected upon plugin updates could not be used to statistically deduce whether a given PHP version can be assumed to be safe to use.

We briefly mentioned Backups as well before the end of the meeting. These cause some of the same issues, in that we don’t want to link to specific vendors at the expense of others. For now, we’re thinking it’s best to give general advice about what to watch out for with the backups, and then link to something like this page: https://wordpress.org/plugins/search/backup/

As already stated we have created GitHub issues for every topic, and an overview of these can be found in the “Before Upgrading PHP” section of the Sections” project board. Any feedback on this topics is welcome!

Next week’s meeting

The next meeting will take place on Monday, October 9, 2017 at 18:00 UTC, as always in #core-php, and its agenda will be to go over the feedback added to the individual sections and distill the information. 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. See you next week!

#core-php, #php, #summary