This recap is a summary of this week’s PHP 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: @brainfork @chasecm @flixos90 @jdgrimes @joyously @mte90 @nerrad @schlessera @sergey @spacedmonkey
Chat Summary
Continuing what was started last week, the agenda for this week was to review the second half of the copy for the “Servehappy” page, which the marketing team has worked on.
- The first part of the meeting was about reviewing the “Are there risks when upgrading my PHP version?” section:
- The first paragraph should emphasize more how WordPress consists of multiple parts by individual parties that may cause different kinds of compatibility issues when used together. There should be less focus on the open source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. part of it.
- The first two paragraphs can be merged into one:
In a perfect world, the answer would be “no”. However, the WordPress ecosystem is made up of thousands of themes and plugins (built and maintained by developers all over the world). All the various combinations of these parts that can be added to your site increase the potential for incompatibilities with certain PHP versions. WordPress cannot detect all those possible conflicts automatically.
- The third paragraph should be omitted since talking about the different possibilities regarding PHP version upgrades does not belong into the section describing risks. The fourth paragraph will not be part of this section either, but can instead be reconsidered for an additional “Before Upgrading PHP” section, which will be worked on later.
- An extra paragraph should be added to clarify some of the actual issues that may occur:
Some of the things that could happen when these incompatibilities affect your site, are white screens or unexpected behaviour. If any of these happen to you, you can troubleshoot them (this should link to extra troubleshooting steps elsewhere) or roll back the php version on your server (the rollback part may not always be applicable, so it may be better to strip it out). However, by following the suggestions in the next section, you can drastically reduce the chance to run into any of these issues.
- The second part of the meeting was about reviewing the “How to Upgrade PHP for your Website” section:
- The first two paragraphs are good as is.
- In the third paragraph, it should only be recommended to send an email to the host if the site owner does not find any resources about how to upgrade. The part about them feeling comfortable doing it should be removed, as upgrading PHP itself is a rather simple task compared to some of the steps recommended before the PHP upgrade. When the host provides an interface for it, the upgrade is usually only about navigating to the right area and hitting a button. The paragraph should therefore start like this:
If you cannot find instructions for your specific host, the best thing you can do is ask them. […]
- The email template itself should not use specific PHP versions and rather ask for the latest version (this may be revisited, see below):
I want my website to be as performant and secure as possible with the latest version of PHP. For the server my WordPress site is hosted on, I want to ensure that is the case. If I am not already on the latest version of PHP, please let me know what steps I need to take to upgrade.
- It may be useful to highlight that, if the hosting provider is unable to upgrade the PHP version, the site owner should consider switching to another host. On the other hand, it could also be clarified that if the site owner is uncomfortable / unable to upgrade to the latest PHP version due to some incompatibilities detected, it is also worth upgrading to the highest possible version that is still actively supported if there is no other way.
- The section about self-hosted setups and servers managed by the site owner themselves should be removed as it is very unlikely those people are not already aware about PHP upgrades and how they work. This page is for non-technical people, and self-hosting a site does not fit into that scope.
- Whether it is really the right decision not to mention any specific PHP versions should be revisited. Not mentioning any version will make the information on the page more vague, and regularly updating the page to use the current version should be an easy task, when done right initially. There could be a shortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. for the latest PHP version (currently 7.1) and another one for the lowest PHP version to recommend (currently 5.6), both of which would be used throughout. This would allow to only change the version numbers in one place and have them updated throughout the entire page.
- As mentioned before, the page should also contain a section about which steps to execute before actually upgrading PHP. This could include things such as using a PHP compatibility checker plugin 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, checking how well the themes and plugins used are maintained, backing up the site, and more. This is currently not part of the Google document because there isn’t a clear idea for the section yet.
Next week’s meeting
The next meeting will take place on October 2nd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to think about and plan the “Before Upgrading PHP” section mentioned above. Ideas are very welcome and it would be great if you could take some time to think about possible steps in the meantime so that there is already something specific to discuss next week. 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, #marketing, #php, #summary
