PHP Meeting Recap – October 30th

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: @flixos90 @jdgrimes @mte90 @nerrad @schlessera @vizkr

Chat Summary

The agenda for this week was to discuss the last remaining GitHub issue for the “Before Upgrading PHP” section and review the Google document for it that @schlessera had created from the previous discussion results.

• @flixos90 gave a quick update on the current state of the PHP Compatibility Checker plugin by WP Engine:
  • The sales call to action was already removed on the 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/ repo. It’s not in the public release yet, but it’s done.
  • The 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 is currently not 5.2-compatible, but will be made that.
  • In order to use the best PHPCompat library version possible, the plugin will bundle both the last 5.2-compatible version as a static dependency and then the latest version via Composer. Those will be loaded as necessary.
  • Instead of allowing the user to test for a specific PHP version, the plugin should offer a way to automatically scan for all recommended PHP versions and in the end recommend the user which version to upgrade to (if no errors in the latest version, recommend that one; otherwise proceed; give them a quick comparison overview at the end). This will make the process easier.
  • In that automatic procedure, older versions than 5.6 should only ever be checked if all other newer versions include failures. Under these circumstances, the idea is that it’s still better for a site to be on PHP 5.4 for example than 5.2.
  • All of this will be worked on. However, as there’s currently no timeline, there’s no pressure there. Once there is an idea on when it’s needed, the WP Engine team should be informed.
• The GitHub issue about contacting a developer was considered a bit fuzzy, as it is probably only useful for cases where a site was initially set up by a developer, but then never maintained. In these cases the site owner may still have a developer of choice that they can contact. In case a site is actively being maintained by a developer, it’s unlikely that it’s still on such an old setup. But even there it might help. It was decided to include this recommendation as the last paragraph, to not overemphasize it. @nerrad suggested to go with something like the following:
  

  While the steps above are something we believe any WordPress site owner can do, if you have an existing relationship with a developer/agency, you may want to also consult with them regarding the specific needs for your site.

• Regarding the sections in the Google document, it was decided that the “Updates” section should follow right after the “Backup and rollback plan” one as it builds upon that.
• It is still unclear how to handle the plugin and theme-related sections, both in terms of getting support and finding replacements. The idea of a crowdsourced list of plugins and whether they have any issues and which ones is nothing that can be relied upon yet. Plugin alternatives cannot be recommended without affecting the plugin market in an opinionated way, the only solution here would be a “Related plugins” functionality in the repository, but this would be something else far away from execution. For now these sections should be kept vague enough, while being as precise as possible about everything else.
• It must be clarified that while a backup helps with issues of WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins or themes, it does not back up the PHP version. If the PHP upgrade breaks a site, the entire PHP version needs to be rolled back, so contacting the host would be required again.
• In order to get this document to a place where it can be handed over to the marketing team, actual copy suggestions like in the initial Servehappy document will be needed. Right now a lot of it is summary including things some of which should not actually be emphasized as much in the final document.
• The current Google doc should be reworked to only include draft copy as content, and anything that’s currently there and significant to know in addition should be added as context-sensitive comments. @flixos90 started work on this as of now, and anyone is welcome to chime in with more suggestions, which will then be reviewed in the next meeting.

Next week’s meeting

The next meeting will take place on November 6th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. 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