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.
- @joyously asked about the current state of Tide. @flixos90 added that he is not clear on where it currently stands, but once it is open for projects like Servehappy to integrate with it, it would make a great use-case. Automating the PHP version compatibility might be more reliable in the long run than requiring 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 authors to manually keep that information up to date.
- The topic of having a range of supported PHP versions for each plugin was discussed throughout the meeting.
- Information of a maximum supported version of course helps the user to determine its compatibility, generally. However, it can also have negative implications on the PHP efforts: In case the maximum supported version information is not accurate, it will make site owners hesitant from updating PHP, for no reason. Particularly since this conflicts with the project’s goal, caution is required.
- Neither the plugin/theme author nor an automated code-sniffing based tool can reliably provide compatibility information. Arguably, the latter will end up with more accurate results in the long run, but it still will include many false positives (or false negatives).
- Due to this problem, there was mostly consensus that no tested up to PHP version should be exposed at this point. While both the minimum and maximum versions are not reliable, the maximum version is more likely to have a negative impact on the project’s efforts.
- Another topic discussed was the safeguarding of such incompatible plugins and themes, when they are attempted to be used. A site owner should be prevented to interact with such an extension as early as possible, i.e. when installing it. If it is installed through a way that WordPress cannot control, such as uploading manually, then it should at least apply the same restriction on activation. A follow-up discussion to the meeting questioned whether this restriction should be enforced, or alternatively only suggested, for example by using indicative colors in the UI User interface.
- In that regard, it needs to be ensured that the more experienced users are accounted for as well, in case they want to be informed of fatal errors in the more traditional way and get around the safeguarding mechanisms. An idea could be to provide a constant or otherwise configurable flag to disable the safeguarding mechanisms, which could cover both the extension restriction and the WSOD prevention. By default these should definitely be enabled, to account for the majority of users. This being configurable would allow to circumvent the hard restrictions, which are preferable for the common case.
Next week’s meeting