This recap is a summary of this week’s PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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: @charliespider @davidvee @jdgrimes @joyously @nerrad @schlessera
Chat Summary
This meeting once again revolved around discussing the “Before Upgrading PHP” section.
We started by discussing the freshly introduced topic “Find replacements for incompatible plugins“, with the following observations:
- Some plugins can be easily fixed in a matter of minutes by a developer. This is out of reach for most end users, though.
- Replacing a broken 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 involves not only finding a suitable replacement but also migrating existing data between plugins. The involved effort can be quite substantial and deeply technical.
- Providing actual recommendations on what plugin replacements to use is once again difficult to do in an “official capacity”, as it has a direct impact on the market around plugins.
- Current search in the plugin repository is inadequate for this task. It needs more filtering / tagging / categorization tools (without just collecting spam of course) (meta trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. #2753), but it would also profit from an actual “Similar plugins” functionality (meta trac #3208).
- To avoid end users hitting a lot of incompatible plugins, we should investigate running the compatibility scanner over the entire plugin repository and directly email the plugin authors. Some of these issues might then already be taken care of at the time the end users run their own checks.
- We have to make sure we don’t inadvertently communicate a message along the lines of “most free plugins are broken, WordPress can only reliably be used with premium plugins”.
We followed this by discussing how to best approach the #marketing team. We opted to create a Google Doc that will contain a distilled version of all of our remarks so that we have something usable to provide as a starting point. We’ll collaborate on filling out this document, to have it represent a shortened overview of what we gathered in the “Before Upgrading PHP” section on our issue tracker.
Next week’s meeting
The next meeting will take place on Monday, October 30, 2017 at 18:00 UTC, as always in #core-php, and its agenda will be to go over the “Before Upgrading PHP” document that we will hand over to the marketing team to get their help with writing the 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
