PHP Meeting Recap – October 8th

This recap is a summary of our previous PHP 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.

Chat Summary

  • We started discussing how themes should be approached in terms of the WSOD protection (see the Trac ticket / GitHub PR).
  • We noticed that, when the active theme is deleted, the frontend will simply show a blank screen, so there are no critical implications of what happens when no theme can be initialized. What needs to happen is therefore to just flag the theme as paused so that it isn’t loaded, with no further handling being necessary.
  • A Resume button for themes should be added to the Appearance admin screen, similar like there is one for plugins, displayed to those that have the resume_theme capability, which should map to the existing switch_themes.
  • An observation was made along the lines that the default PHP error output also renders with the frontend message that something broke. While path disclosure is a problem, such messages should never display on production sites that are set up with something like the ini_set( 'display_errors', 0 ) directive. WordPress does not take care of setting this itself, which can be discussed in a ticket, but is not related to our WSOD protection efforts.

Next week’s meeting

  • Next meeting will take place on Monday, October 15th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how the php-error.php template from the WSOD protection project and related efforts made in the PWA feature plugin can be implemented in a coherent way. @westonruter had highlighted that there were similarities, but also differences, and a common solution should be found.
  • 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.

#core-php, #php, #servehappy

PHP Meeting Recap – October 1st

This recap is a summary of our previous PHP 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.

Chat Summary

  • After last week’s meeting, we briefly continued discussing whether we should move forward with a hardcoded approach for the Update PHP page. While it is currently a regular WordPress page, we confirmed that decision, with the most important reason being its better trackability for string changes, and thus better handling for translators. In addition, the hardcoded approach should be quicker to develop because it does not involve dynamic content such as Gutenberg blocks.
  • It was decided that #3789 should be repurposed for that. @flixos90 said he would be up for it and will work on a first meta patch soon.
  • We then discussed the WSOD protection, particularly recent comments made on its ticket #44458.
    • We decided that the is_protected_endpoint() result should be filterable, however only for adding further endpoints. It should not be possible to alter the protected core endpoints.
    • The php-error.php drop-in should be responsible for outputting the HTTP status header and rendering HTML markup to the page. With this functionality being limited to a template, it is in line with the existing db-error.php. More importantly, with this approach sites that use the drop-in will still get the benefits of detecting multiple errors in one go by using redirects.
    • The function is_ssl() is always loaded when it would be needed by the new code (since it is part of wp-includes/load.php), so there is no need to think about what to do when it is not available.
  • @flixos90 confirmed that the multisite team would review the existing code the same week. This feedback has since been posted on the ticket. As of now, most of this feedback is already implemented on the latest patch. Please see the ticket for an explanation of the changes including screenshots, and the underlying GitHub pull-request for a better overview of the code.
Network Admin UI for the (manually) broken "Hello Dolly" plugin
Network Admin UI for the (manually) broken “Hello Dolly” plugin. Network administrators see information about the sites affected and can resume execution for the entire network, essentially force-resuming the plugin for every site.

Next week’s meeting

  • Next meeting will take place on Monday, October 8th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Review the latest patch, gather feedback and ideas, particularly in regards to multisite support and theme support, the latter of which is yet to be added.
  • 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.

#core-php, #php, #servehappy

PHP Meeting Recap – September 24th

This recap is a summary of our previous PHP 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.

Chat Summary

Update PHP Page

We first discussed the current implementation of the dynamic block we want to include at the top of the “Update PHP” page.

  • @nerrad had already implemented a Gutenberg block to provide this functionality. It has multiple fields in its sidebar to allow adapting the text to display.
  • @dd32 suggested looking into a hardcoded PHP template instead, to reuse Glotpress functionality for the translation workflow. Otherwise, it is very difficult for translators to know when strings had been updated. Also, this would ideally go into the theme for the Support subsite, instead of a plugin, to isolate the changes to this subsite only.
  • We mostly agreed that internationalization is easier with a hardcoded approach where the strings to localize are found in the code. @sergey pointed out that this is how all the content is done on the main wordpress.org site and linked to an example.
  • The approach to take would be to create a page wporg-support/page-update-php.php and hardcode the content into that.
  • This discussion showed that we wasted a lot of time (@nerrad invested up to 10 hours into the first iteration of the plugin), because the actual requirements were never mentioned before starting. We should think about how we can avoid situations like this in the future, making sure we don’t invest time in “non-options”.

WSOD Protection

We then moved on to discuss progress on #44458 – Catch WSODs and provide a means for recovery for end users.

  • The current implementation is missing logic for themes and might not yet work correctly on multisite installations.
  • @flixos90 will mention the ticket during the multisite meeting to look at what would be necessary for making it work with multisites.
  • For themes, @afragen quickly tested what would happen when no theme at all would be loaded. The login screen and the admin backend do not seem to be affected.
  • For skipping to load a theme that throws errors, we can add an additional condition in the bootstrap code where WP decides whether to load the functions.php file or not.

Next week’s meeting

  • Next meeting will take place on Monday, October 1st, 2018 at 15:00 UTC in #core-php.
  • Agenda:
    • Discuss hardcoded approach to “Update PHP” page.
    • Collect feedback on multisite approach for WSOD protection.
  • 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.

#core, #core-php, #php, #servehappy, #summary

PHP Meeting Recap – August 20th

This recap is a summary of our previous PHP 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.

Chat Summary

  • We continued reviewing the content of the Update PHP page, which is available in this Google document.
  • We specifically looked at the closing section that acts as a summary, wondering whether it could be highlighted more or whether it is even needed. In the end it was decided to keep it as it is, as web readers typically expect a conclusion to occur at the end of a resource. Furthermore it leaves them with a positive attitude about their (future) achievement.
  • There were two comments about redundancy of paragraphs describing what would be the topic of the respective next section, since they are followed by a heading telling the same thing. However, as linking paragraphs they improve the reading flow and therefore should remain present.
  • A couple of minor wording improvements were discussed and applied.
  • It was agreed that the only outstanding change is the removal of all the hosting-specific tutorial links. They should be replaced with a single link to an external resource containing those links, similar how it is in the current live version of the page. A long list of links would distract readers, furthermore a single external resource allows for more flexibility on how this is managed. For now, the single link should point to the hosting-specific tutorials list in the Servehappy resources repository. Once this change is present, the content of the Google document can go live, replacing the current Update PHP page content.
  • Before the meeting, at WordCamp Brighton, a new idea of coming up with a documentation pattern and distributing it to hosts in order to get them provide guides on how to update PHP on their environment was discussed. The idea was appreciated by everyone. While an involved task, it will iterate on the already present crowd-sourced resources repository.
  • It would make sense to use GitHub Pages for such a repository. Pointing to a repository directly would easily confuse non-technical users, and a simple website fetching the content from GitHub Markdown files would improve that greatly.
  • A consideration is the URL to use for that. GitHub Pages URLs for organization repositories contain both the organization name and the repository name, so for the servehappy resources directory, it would be WordPress.github.io/servehappy-resources, which is not very obvious for what it contains. A repository named update-php or update-php-resources would be a better alternative. Alternatively, a custom domain could be used. This needs to be carefully evaluated.

Next week’s meeting

  • Next meeting will take place on Monday, August 27th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the approach for streamlining hosts’ PHP update tutorials and using GitHub Pages (or possible alternatives) for those resources.
  • 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – August 13th

This recap is a summary of our previous PHP 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.

Chat Summary

  • The content of the Update PHP page was further discussed. There is a Google document available where @alexdenning has been working on revised copy. It is open for comments if you have suggestions.
  • As a reminder, the goal is to shorten the copy by removing unnecessary technical details and thus more positively encouraging the user to update. At the same time, we must not omit that there may be issues and, most importantly, we have to educate about the prerequisite steps necessary to roll back in case a problem occurs that cannot be fixed quickly.
  • As most problems actually need technical assistance to solve, we should not go into too much detail there, but point out that they might want to get help from a developer in such a case. However, basic suggestions as finding a replacement plugin in case a plugin is incompatible should remain, as we still want to encourage users who would be unable or unwilling to hire a third person.
  • At the same time, with the improvements being made in #44458 we can actively encourage the update because, even in case of errors, the site owner will still be able to log in to the site to provide short-term fixes at least.
  • Over the course of the meeting, we made a couple comments on the document with the items we discussed. Please refer to the Google doc linked above for details.
  • We also briefly picked up discussion on visual assets for the page. While that should preferably happen after the copy is in place, it doesn’t hurt thinking about it already, especially since some pieces might be relatively independent of what the final copy will be like. These are ideas we have been considering:
    • Timeline of PHP versions and their end of lifes (dynamic including the passed PHP version, or not)
    • Graphic of the relation between server, PHP, website, WordPress (possibly also including plugins and themes)

Next week’s meeting

  • Next meeting will take place on Monday, August 20th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Further discuss the Update PHP page copy and visual assets to use.
  • 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – July 30th

This recap is a summary of our previous PHP 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.

Chat Summary

  • It was discussed which types of errors and exceptions to handle in scope of the sandbox mode (see #44458).
  • @schlessera presented a document in which he had prepared comprehensive resources and his suggestions for what to handle.
  • The approach was mostly agreed on, with the addition that the E_USER_ERROR type should also be covered, since many plugins make use of it, some of which are among the most popular ones.
  • The following PHP errors should be treated:
    • E_PARSE
    • E_ERROR
    • E_RECOVERABLE_ERROR
    • E_USER_ERROR
  • Regarding exceptions, only the base Exception and the PHP7 Error exception classes need to be treated, basically as a catch-all.
  • It is not necessary to wrap the try-catch statement catching Error into a PHP7 version check clause, since catch statements do not trigger autoloading since PHP 5.1, so there won’t be an issue on PHP versions below 7.
  • The following exceptions should be caught:
    • Exception
    • Error
  • Something to consider and test with the implementation is whether the shutdown handler plays well with other shutdown handlers possibly registered by plugins.
  • In addition to implementing treatment of the above errors and exceptions, an important item is how to handle multiple broken plugins: In the latest patch, when an error is detected and the plugin is paused, the next request might simply do the same thing if another plugin causes a problem. In case many plugins are affected, this presents a significant UX issue.
  • Therefore a mechanism is needed that detects multiple issues in one go without requiring further user interaction. Redirects and/or AJAX requests are ideas that could be used to accomplish that. @schlessera is going to continue working on that.
  • Due to the project becoming increasingly big, it was decided to proceed work through a pull request against a WordPress fork, to have a better overview of the incremental code changes. GitHub should only be used for the implementation while discussion can stay on Trac. A pull request has been opened for that purpose to which the latest patch has been ported over. Note: In order to test the code, it is only necessary to append a .diff extension to the PR.

Next week’s meeting

  • Next meeting will take place on Monday, August 6th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – July 23th

This recap is a summary of our previous PHP 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.

Chat Summary

Update PHP Page

We first discussed the “Update PHP” page content/layout.

@AlexDenning confirmed that work is being done on the page by @Jayman and him. He’ll send updates as they happen.

WSOD Protection

We then moved on to discuss progress on #44458 – Catch WSODs and provide a means for recovery for end users.

  • We collected thoughts about reframing the project from “Servehappy” to “Health Check Project”. This led to a lot of questions about what further changes this would allow that wouldn’t be covered by the “Servehappy” name. We could come up with a few examples, like:
    • helping people update their plugins & themes
    • keeping Core up-to-date
    • keeping MySQL up-to-date
    • organizing “Update Bars” at WordCamps & meetups
  • Then we discussed timing and whether we’re on track for 5.0. Basically, our changes can be merged/backported as soon as possible with the caveat that the following requirements need to be met first:
    • the “Update PHP” page needs to be reworked
    • the WSOD protection needs to be in place
  • We discussed the types of errors that the WSOD protection catches. The current proof-of-concept only catches PHP parse errors, but we can certainly catch other types of errors, provided we know without fail how to deal with them. @schlessera will set up a document to examine the possible errors and determine which ones to catch.
    We cannot simply catch all fatals unconditionally, as we wouldn’t know what to filter from load to make the site work again.
  • @flixos90 has created tickets to port the “Requires PHP:” header tag to themes: #44592 & #meta3718.

Post-Meeting

Link to the document discussing the different types of PHP errors to catch: https://www.notion.so/brightnucleus/WP-Sandbox-88738b62e9e947a7aeb8271d958a5497

Next week’s meeting

  • Next meeting will take place on Monday, July 30th, 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.

#core-php, #meta3718, #php, #servehappy, #summary

Servehappy: Roadmap Update and Priorities

At WordCamp Europe 2018, representatives from different teams got together to discuss the state of the Servehappy project, reevaluate its roadmap and priorities.

Meeting Context

While this blog typically contains updates from the core PHP team, it is important to highlight that the Servehappy project is an interdisciplinary effort that has involved several other teams as well. We have been collaborating closely with the marketing and design teams so far, however at the same time several efforts were pursued in other teams which had not been mentioned as much in the weekly recap posts: The community team and support team have been pushing a format called “Site Health Check”, providing support services at WordCamps to increase adoption of modern PHP versions as a part of that. The hosting team has also discussed on how to approach the problem on their end. Due to all these different teams being involved in the Servehappy project, we wanted to revisit the project state together with a representation of those teams.

Participants: @alexdenning, @flixos90, @mikeschroder, @miss_jwo, @pento, @schlessera

Meeting Summary

Short-Term Goals

While the general long-term goals of the project are clear and available in the project’s roadmap, the discussion briefly involved clarifying priorities and short-term goals.

  • Increase adoption of modern PHP versions by being more active and vocal about the necessity of those.
  • Encourage users in a positive manner to update and stay updated.
  • Make the process of updating as seamless as possible.
  • Release a first iteration of the project that warns administrators of sites running PHP 5.2.

Approach: Help People

We agreed that, in line with the WordPress philosophies, the approach to solving the problem should be based on framing the project in the user’s context, most of who have little to no technical knowledge of PHP.

  • We would like to boost user confidence by encouraging the update and educating about preliminary recommended steps to take in order to ensure the process goes without a hassle.
  • By highlighting tools such as Tide, the Health Check plugin, or the PHP Compatibility Checker plugin, we allow non-technical users to easily gain technical insights in a plugin’s compatibility with certain PHP versions.
  • We intend to reduce the risk of updating PHP as much as possible by implementing a sandboxing system to decrease the chance of a site breaking through the update. We need to ensure that site owners are never locked out of the backend due to an incompatibility.
  • We plan to run further Site Health Check desks at WordCamps and related events and encourage organizers to do so, in order to raise awareness of the importance of checking the PHP version on your website. An important side note to this, at this point only updates to PHP 7.2 and 7.1 should be encouraged, as both PHP 5.6 and 7.0 will be unsupported from the end of this year.

Data about PHP Version Updates

We briefly talked about the jumps from and to specific PHP versions, looking at how involved they typically are.

  • The update from 5.2 to 5.3 has known issues which are not small. We should review the support impact for hosting companies, agencies, plugins, themes, and the WP.org support team.
  • The updates between 5.3 to 5.6 are usually unproblematic, there have been no known major issues.
  • The update from 5.6 to 7.0 has many known issues. @mikeschroder will request a list of common issues and errors known to the hosting team when performing that update.
  • The updates between 7.0 and 7.2 have been less problematic, however due to several deprecations more investigations should be made in that area.

Improving the Updating PHP Page

While the nag to inform site owners about an unsupported PHP version has already been merged into core and an Updating PHP page is already available, it is necessary to improve the latter.

  • The above page, which is linked to from the core nag, will to a large extend determine whether the project will be successful or not, as people have to be willing to read its content and then act on its recommendations.
  • Currently the page is a simple wall of text, which will likely scare away visitors. The page content needs to be further reworked, broke down into more obvious sections, shortened, and be visually enhanced so that users are guided through the process as intuitively as possible.
  • @alexdenning will coordinate with @jaymanpandya who had worked on a design for the page before to move this forward.

Community Plans

  • A Site Health Check desk will be available at WordCamp Brighton in mid-August with the goal of testing this approach further and optimizing the process.
  • Following this, we would like documentation to be created about having this format, with the goal of it being ready by WordCamp US in early December. That documentation could then be shared with communities and organizers around the world, encouraging providing this format at more events.
  • Current plans also include there being a Site Health Check desk at WordCamp US, preferably also with more hosting team support at the desk, especially due to their high availability at that event.
  • Another idea was to have wapuus made available specifically for the Site Health Check.

Hosting Plans

  • The core PHP team would like to communicate more and collaborate more closely with the hosting team.
  • The hosting team is an ally to these efforts and would like to be more involved. Some miscommunications in the past were figured out and clarified.
  • It is planned that a representative of the hosting team will be participating in the weekly PHP team meetings, reporting back and voicing views of the hosting team on the topics discussed. As of now, @antpb has stepped up to fill that position.
  • It would be great if documentation for hosting companies could be created on how to integrate with the Servehappy nag in core (read more about the core integration) and on how to provide easy-to-understand documentation on how to safely update PHP in their specific environment.
  • An idea for further down the road that came up was having standardized endpoints as part of an API for upgrading PHP across hosts. CPanel or Plesk adopting this could move the needle across many hosts at once.

Core and Security Plans

  • The security and core teams plan to work on user-facing documentation on why running old versions of PHP or WordPress is dangerous.
  • Furthermore they intend to create documentation for both plugin and theme authors about how to ensure that their code is compatible with modern PHP versions.

Involvement of the Marketing Team

  • Going forward, all documentation created as part of the aforementioned plans should preferably be reviewed by the marketing team.
  • It is important to use an easy-to-understand, encouraging and positive tone of voice for all documentation.
  • We need to ensure that all marketing material documentation is localizable and uses language that is easily translatable.

Requirements for Servehappy in Core

In order for the first iteration of the Servehappy project to be shipped in a core release, we determined the steps that must be completed before.

  • The first iteration should primarily revolve around the core nag warning users about outdated PHP versions. It will only be displayed for PHP 5.2 in the first iteration.
  • Due to that version being controlled by a wordpress.org API, the nag’s visibility can be gradually increased by being shown on higher PHP versions too, without being tied to WordPress core releases.
  • Further efforts of the Servehappy project in core, such as preventing installation or updates of incompatible plugins and themes, are not specifically a requirement for the first iteration. Although not as high a priority at this point, they should definitely not stall and will be merged and released as they get completed, however only at the same time or later than the core nag.
  • The efforts of improving the Updating PHP page mentioned above needs to be completed, with the page being in a solid state. It should be fully translatable, and there should be enough time before the release to encourage the creation of localized versions of the page across the globe. The link to the page in core is localizable as well, being able to link to those versions.
  • A safe-mode functionality needs to be implemented in order to prevent WSODs (white screens of death) and other errors that would lock the site owner out of their backend. It will likely involve some sort of sandboxing system, with plugins being deactivated in the admin as necessary to ensure possible access. Having this will allow the instructions in the Updating PHP page to be more positive and confirming. @schlessera has since been making quite a bit of progress on this already in #44458.
  • It should be possible for hosting companies to hook into the nag and provide their own instructions of how to upgrade to WordPress users on their stack.
  • It is currently envisioned to have the first iteration ship as part of WordPress 5.0, however depending on when that version is released, this may change. It is certainly no hard deadline in that regard.

Project Name Proposal

  • Based from the Site Health Check desks, there is a suggestion to refocus the project to be the WordPress Health Check Project which encourages people by name to check for updates continually.
  • However, the problem has arised about defining what is in scope of the site health check. It needs to be clarified what kind of health check this is, as some users so far have looked at it as a performance check.
  • The name change would allow for a more positive mindset and for the scope of the project to change as the WordPress project needs it to.
  • Unless there are objections, the name Servehappy for the core efforts is solely an internal codename and will not be exposed to the user anywhere.

Get Involved

If you’re interested in these efforts, please get involved and get in contact with the respective team whose work you are interested in. The easiest way to do so is participate in their meetings. We need your input and ideas, specifically we would like to ask for your feedback on the outcome of the discussion that is part of this summary, as most of it is not set in stone. If you cannot make it to the respective meeting, posting a comment here is a great alternative.

As far as the core efforts go, the next meeting will take place on Monday, July 23th, 2018 at 15:00 UTC in the #core-php channel on Slack.

#core-php, #php, #servehappy

PHP Meeting Recap – June 25th

This recap is a summary of our previous PHP 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.

Chat Summary

  • 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 capability upgrade_php will be renamed into update_php.
    • 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 will be changed to https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
    • A redirect will be done from https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
  • Then we quickly discussed the #design <=> #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/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 ticket 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.

#core-php, #php, #servehappy, #summary

PHP Meeting Recap – June 11th

This recap is a summary of our last PHP 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.

Chat Summary

  • A final decision on both the design and the copy for preventing installation of incompatible plugins was made (see #43986).
  • It was agreed to use a mock-up presented by @melchoyce outside of the regular chat at the end of last week. It displays the notice on top of the plugin card, thus addresses the concerns about the notice being too far away from the disabled button and about currently present information being hidden by the notice.
  • For the copy, it was decided to go with the following, for the three possible circumstances:

    This plugin doesn’t work with your version of WordPress. [Please update WordPress].

    This plugin doesn’t work with your version of PHP. [Learn more about updating PHP].

    This plugin doesn’t work with your versions of WordPress and PHP. [Please update WordPress], and then [learn more about updating PHP].

  • @afragen already created an updated patch that implements the above. The patch needs to be thoroughly reviewed and can hopefully be committed some time next week. Here is a screenshot of what the final result will look like:

Plugin Card Incompatible Notice

  • In the second half of the meeting, discussion started about how to approach preventing plugin updates in case of incompatible PHP or WordPress versions (see #43987).
  • It was decided that, in the plugins list table, each row with an incompatible version should show a notice almost like it currently does for a regular plugin update. However, the notice should use the error color instead of the warning color, and also show an error icon.
  • A challenge with the copy in that notice is that it also needs to include a link to view details of the new version. A first draft was suggested, following closely what has been decided on for the plugin installations (see above). Here is the current state of the copy, again for the three possible circumstances:

    There is a new version of %1$s available, but it doesn’t work with your version of WordPress. [Please update WordPress], or [view version %2$s details].

    There is a new version of %1$s available, but it doesn’t work with your version of PHP. [Learn more about updating PHP], or [view version %2$s details].

    There is a new version of %1$s available, but it doesn’t work with your versions of WordPress and PHP. [Please update WordPress], and then [learn more about updating PHP]. You can also [view version %2$s details].

  • It was remarked that plugins with a WordPress version that is incompatible are not made available already. This possibly means that it will only be necessary to implement notices and restrictions specific to the PHP version, however no decision has been made on that yet.
  • At the time of the meeting, the patch on #43987 also included adjustments for the general “Updates” admin screen, preventing plugin updates from there as necessary. To narrow down the scope of the ticket and make the discussions more straightforward, it was decided to implement that part in a separate ticket. #44350 was then opened for that purpose.

Next week’s meeting

  • Next meeting will take place on Monday, June 18, 2018 at 15:00 UTC in #core-php.
  • Agenda: Check whether there are any blockers that have come up with #43986, and otherwise focus on continuing the discussion about #43987.
  • 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.

#core-php, #php, #summary