PHP Meeting Recap – October 16th

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

The meeting’s chat log.

Attendees: @felipeelia @flixos90 @jdgrimes @mte90 @schlessera @sergey @stevenkword @tobifjellner @vizkr

Chat Summary

The agenda for this week was to continue discussion on the GitHub issues that deal with the planned “Before Upgrading PHP” section.

  • @flixos90 started by giving a brief recap on last week’s meeting, particularly on the discussion of the PHP Compatibility Checker plugin by WP Engine and the changes that need to be made to it in order for it to be referenced and recommended by the Servehappy page and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Together with the lead developers of that 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, he will explore the next steps.
  • The meeting then focused on the individual GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues.
  • “Ask hosting provider”: This is kind of a fuzzy issue as to whether that is useful depends entirely on the individual hosting provider. One idea was to focus on managed hosts only for this and in the copy start with something like “If you are on a managed host, they may be able to…” – however, it may be a better decision to not mention this at all, as it would be hard to give valuable advice. No clear decision was made on this yet.
  • “Updates”: WordPress core, plugins and themes should be up to date (of course only plugins that do not require a higher PHP version in their update). As these updates can also break the site without even getting to the PHP part, this point should therefore mentioned after the “Backup and rollback plan” point. In regards to that, it may be helpful to recommend doing an extra backup after everything has been updated (still before the PHP upgrade) – however only if storing multiple backups is possible with the solution the site owner is using for their backups.
  • “Ask plugin/theme support”: This is definitely good advice when using premium plugins or themes with paid support. For community-driven plugins, it really depends on the popularity of the plugin and how many volunteers are helping out for the respective plugin. A related idea that came up was to create a list where support volunteers can add specific plugins with issues on certain PHP versions to so that over time a crowdsourced resource to find out about possible issues in advanced will evolve. Since @danielbachhuber and XWP have apparently been working on an automated solution for a similar cause, it may be valuable to combine these efforts. The result could for example be an 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. that delivers data on plugin compatibility with different PHP versions, taking both automated and manually submitted data into account. What to present about this point on the Servehappy page heavily depends on what these projects will end up working like.
  • “Check WP.org plugin/theme info”: It was decided that this point should not be included. There is no plugin information on the maximum supported PHP version, and even if there was, the majority of plugin authors would not update it accordingly over time (the same issue that is currently happening with the “Tested up to” field for the WordPress version). Furthermore, most developers whose plugins have issues on a more modern PHP version likely do not know about it or are not maintaining the plugin any longer.
  • “Test locally/on staging”: This point should be ditched as well, as it is much too advanced. A local environment is definitely not something trivial to set up for a non-technical person. For staging it depends on the site owner’s hosting provider again, but even on hosts that offer 1-Click-Staging, it can be a complex task – especially since several hosts do not allow changing PHP versions differently between the environments of a single site.

Next week’s meeting

The next meeting will take place on October 23rd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to finalize discussion on the remaining GitHub issues for the “Before Upgrading PHP” section, with the following week focusing on transfering all these thoughts into copy. 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