This recap is a summary of our previous 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.
You can find this meeting’s chat log here.
- We first discussed terminology: are we talking about “PHP upgrades” or “PHP updates“? We are currently mixing both of these in a rather random fashion. We then decided that we’ll stick to “PHP updates” and “updating PHP” from now on, because:
- The distinction between “update” and “upgrade” is lost on most users anyway, so we should only use one in user communication.
- “Upgrade” implies an improvement. An “update” means getting it to the latest state. While it will provide improvements, doing an “update” is actually what we’re after, even if no improvements are to be had.
- “Update” better fits with the rest of WP communication as well.
- The following changes will be made to make all project deliverables consistent with the above decision:
- Patches in #43986, #43987 and #44350 will be changed to only refer to “updates”.
- The core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. capability
upgrade_php will be renamed into
- The support page will be renamed from
Upgrading PHP to
Updating PHP, and the page’s content will be adapted accordingly.
- The support page’s URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org will be changed to
- A redirect will be done from
- Then we quickly discussed the
#marketing collaboration with @jaymanpandya and @alexdenning. They have already made contact and will keep us updated on their collaboration progress.
- Finally, we discussed our new goal of “sandboxing” the 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/theme’s PHP code in some way to make sure users cannot be locked out of their site through a white-screen-of-death (WSOD).
- Current observations:
- Exceptions don’t help, as they are not fully integrated into the error handling at PHP 5.2.
- We can use a shutdown handler to detect fatal errors and know where they were triggered: https://3v4l.org/4jWAs .
- Such a shutdown handler could record a fatal error, and the next page request could then detect a recorded fatal error and decide based on some heuristics whether to initiate “safe mode”
- We cannot just act on plugin activation/deactivation, as this will still take the site down if we update PHP.
- We cannot disable a single plugin, as we cannot reliably detect who the actual culprit is in all cases.
- We might be able to disable a single plugin in those cases where we hit a parse error in a file of a plugin.
- A Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket Created for both bug reports and feature development on the bug tracker. was created for this: #44458 – Catch WSODs and provide a means for recovery for end users
Next week’s meeting
- Next meeting will take place on Monday, July 2nd, 2018 at 15:00 UTC in #core-php.
- Agenda: Continue discussion on the avoiding WSODs in PHP.
- 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.