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

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

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

PHP Meeting Recap – June 4th

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

  • The recap continued the discussion from last week (read the recap) about how to prevent plugin installations from happening if the plugin requires a WordPress or PHP version that is not met by the environment (see #43986 for the related ticket).
  • First it was discussed how to display the notice to inform the user of the version requirement not being met. @melchoyce had presented several design approaches for it, with the aftermath of last week’s meeting highlighting a mockup that replaces the bottom section of the plugin card with the red notice.

Plugin search result: "Incompatible plugin" error

  • The majority of voices during the meeting voted for using the above design, mostly for its clear highlighting and available space. Concerns were expressed about not showing specific PHP versions and, more specifically, about hiding the stats about ratings and active installations. The latter are completely unrelated, so the above mockup may need to be adjusted to include the stats as they are displayed on regular plugin cards at this point. This will need to be re-evaluated in the next meeting.
  • The other point discussed were the copy to use for the notice, including a link to show to solve the problem. The following copy was agreed on for the two respective issues:

    Incompatible with your version of WordPress. Please update WordPress (link to update WordPress).

    Incompatible with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • The above copy is brief and on point, and contains a clearly-described link as a call-to-action, being much more accurate than the previous “Why” links. It was decided to not include specific WordPress or PHP versions in this notice because these version numbers are more technical and would be unnecessary information for most users. Only the “More Details” modal should provide them. The copy was agreed on to use during the meeting, however with a concern being expressed later about the strict tone resulting of the short length of the structurally incomplete sentence. The following alternative was suggested:

    You can’t install this plugin because it doesn’t work with your version of WordPress. Please update WordPress (link to update WordPress).

    You can’t install this plugin because it doesn’t work with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • It was agreed that this copy sounds better, but it would need to be figured out how to fit it into the small space available. Alternatively, the longer variant could only be used for the notices displayed in the More Details modal. On the other hand, that would make visibility of these seemingly friendlier notices much lower. The copy can likely be finalized in next week’s meeting.
  • A problem that was not clearly handled yet is what should happen if both the WordPress and PHP versions are insufficient. In that case, either both sentences could show, increasing the required space further and possibly looking strange due to a single notice showing content that looks like two actual notices. On the “More Details” modal this is not a problem, but it may need a solution on the plugin cards.
  • An alternative was suggested to, at least on the plugin card, always only mention one of the two problems, even if both occur. While none of the participants were really satisfied with that approach, they agreed that in such a case the WordPress version issue should take precedence because it is most likely much easier to fix. The discussion on how to deal with both issues occurring simultaneously should be continued once it is clear how to display the notice and what content to use. It may very well be solved in that process as it needs to be considered for both decisions.

While the preliminary decisions made during the meeting are certainly not final, @afragen implemented the state after the meeting in an updated patch and provided screenshots for it on the ticket, which can help a lot in evaluating the possible approaches in the upcoming meetings.

Next week’s meeting

  • Next meeting will take place on Monday, June 11, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on how to display the notice, with particular attention to maintaining the information currently present on the plugin card and accounting for the possibility of both versions being insufficient. The concrete copy to use should only be discussed if there is enough time left at the end.
  • 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

PHP Meeting Recap – May 28th

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 with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • 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 – May 21st

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 initial half of the chat dealt with the design of the “Upgrade PHP” page:
    • The design team had suggested improving overview of the page structure using either an accordion or a list of headings as a table of contents at the top of the page.
    • It was decided that the ToC (table of contents) functionality provided by the Handbook plugin would be a perfect fit. @clorith outlined that the HelpHub project (which is the upcoming new WordPress support platform) has this plugin included. With the target release set to the end of May, it is perfectly fine to wait that remaining time until we can enable it for the page. Gutenberg will also be enabled on the support platform by that date.
    • @flixos90 noted that the line lengths of the current version of the page are very long, making it difficult to read. @schlessera quickly changed the layout of the page by changing the page template, so that this problem could be solved immediately.
  • The rest of the discussion revolved around possible Gutenberg blocks to implement for dynamic and more targeted content on the page.
    • All Gutenberg blocks for dynamic content should be based on a GET parameter php_version being passed. If none is passed, either the respective blocks should not appear, or, where it makes sense, a fallback PHP version could be used.
    • Participants agreed on implementing a block that would be used as a dynamic header for the page, providing a prominent message such as “Your PHP version x.x is supported/outdated/insecure.”, based on the php_version passed. This block would not appear without the GET parameter present.
    • It was also agreed to introduce one dynamic section as a block, which would show different copy based on the php_version passed. The content of each of the three variants (supported/outdated/insecure) should be fully editable through the block editing interface so that it can be easily translated. Without the GET parameter, this block would not appear.
    • @joyously suggested enhancing the page content with a chart for more visual context. It was determined that a timeline of PHP versions and the current position of the user’s PHP version in it would be a solid approach. Without the php_version GET parameter present, this block would still appear, just without the current version’s position highlighted.
  • @afragen asked for feedback on his work with #43986 and #43987, which is something we should focus on very soon.

Next week’s meeting

  • Next meeting will take place on Monday, May 28, 2018 at 15:00 UTC in #core-php.
  • Agenda: Review whether there are new ideas for the content of the Upgrade PHP page, and discuss the approaches of @afragen‘s patch and how to proceed.
  • 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

PHP Meeting Recap – May 14th

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 couldn’t yet discuss the feedback from the design team, as they hadn’t yet processed the ticket in their meeting.
  • @sergey couldn’t make progress on enforcing the “Requires PHP” header, obviously, as he was busy helping to wrangle the 4.9.6 release.
  • @flixos90 has introduced a new tag on Trac to track the Servehappy tickets: https://core.trac.wordpress.org/query?keywords=~servehappy (available at http://bit.ly/servehappy for the memory-challenged amongst us 😜).
  • We discussed whether the PHP version that is being sent to the .org API could be problematic (GDPR, security). The consensus seems to be that this is data that is usually already available through other API requests (and often is even being transferred by servers in the header information), so we should be good. It is meant to be used to give more contextual information to the user about what the version number actually entails.
  • @flixos90 mentioned that we should not only focus on plugins for enforcing the PHP requirements but also include themes as well. @schlessera will look at what the differences between plugins & themes entail and then create Trac tickets accordingly.

Post-Meeting Updates

  • @afragen built a first pass for #43986 – Disable “Install Plugin” button for PHP required version mismatch.
  • The design team has discussed the “Upgrade PHP” page and collected some feedback. @jaymanpandya is working on implementing this feedback and will get back to us once he has been able to complete something.

Next week’s meeting

  • Next meeting will take place on Monday, May 21st, 2018 at 15:00 UTC in #core-php.
  • Agenda: Check whether there’s updates on the “Upgrade PHP” design review and discuss “Requires PHP” enforcement details.
  • 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

PHP Meeting Recap – April 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

  • We first discussed whether we could have the current widget implementation backported to the upcoming minor release 4.9.6. @desrosj was positive about doing this, but left it open for a final review and someone with the willingness to actually commit it. One benefit would be to include this with the privacy policy changes, which has translators already be aware that a portion of new text strings need to be translated. Also, getting it in as soon as possible will finally allow us to get real feedback on its reception and effectiveness.
  • The “Upgrade PHP” information page needs a visual overhaul. It currently is a pure wall of text, and any change in that regard will be an improvement at this point. @schlessera will work on changing the page for a few quick wins to make it more digestible, and the discussion with the #design team needs to be relaunched.
  • As the first two components of the “Servehappy” initiative are now in a usable state, it is time to focus on the third component: enforcing the “Requires PHP” plugin header information.
  • There are several different mechanisms that need to be changed for enforcing the PHP version requirement, and we agreed to split the main ticket up into smaller subtasks so that blocking issues in one will not block progress in others.
    Here are tickets for the current subtasks:
    1. Disable “Install” (plugin) buttons – #43986
    2. Block updates to new plugin releases – #43987
    3. Allow filtering plugin searches by required PHP version – #43989
  • @afragen has already built a proof of concept that shows a basic implementation for blocking updates. This immediately points out a problem with the current API, which can only serve the plugin information for the latest release of a plugin. If we need to cycle to prior versions to do something like “find the latest version that still runs on PHP 5.2”, we’ll have to work on infrastructure changes as well.
  • Blocking updates does have security implications. We want to block updates to new versions that would bump the required PHP version past a version the server provides, but at the same time, we still want to provide the possibility for plugin authors to push security updates.

Post-meeting update

  • The Servehappy nag widget was not included in the beta of release 4.9.6. We should work on getting it backported early in the 4.9.7 release cycle.

Next week’s meeting

  • Next meeting will take place on Monday, April 7th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how best to relaunch the #design process and go over the individual tickets for enforcing the “Requires PHP” header.
  • 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, #summaries

PHP Meeting Recap – April 16th

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 some back and forth of discussing the color of the widget title border, we decided that we should go for a contextual coloring for now: orange (as a warning color) for outdated sites, and red (as an error color) for insecure sites. However, only after the meeting, we realized that there would hardly be any occasion for us to show the orange warning-type bar.
  • It is important to not rely on color alone for conveying information, for accessibility reasons.
  • We agreed that the efforts to make the widget less visually jarring should avoid downplaying the sense of alarm too much, as that defeats the purpose.
  • The wording of the widget was rediscussed again. However, the result was confusing because not everyone was referring to the most recent state of the widget. We finally didn’t budge from what was concluded last week: the editorial version is good with the exception of the word “guarantee”.
  • We discussed adding a visual symbol, like an exclamation mark, that provides more of a visual cue than the red border. I’ve added a new path with screenshots to the patch that does just that:This also makes the widget still quite noticeable when collapsed.

Next week’s meeting

  • Next meeting will take place on Monday, April 23th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss latest version and the use of the exclamation mark symbol.
  • 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, #summaries

PHP Meeting Recap – April 9th

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 design meeting had not taken place at the time to discuss design of the nag, but the topic was discussed later the week, so next week there will be feedback to review. Screenshots of both the expanded and collapsed state of the dashboard widget are present on the ticket #41191.
  • Via the Automattic editorial team, an updated version of the copy for the nag was suggested and uploaded as a patch.
  • The suggested changes were met with consent, especially considering the removal of a rather redundant sentence to continue reading and a fragment focusing on the people working on WordPress (as they are not the group the widget is targeting).
  • The new “PHP Upgrade Required” was approved as well. While mentioning the term PHP which may initially be unknown to the site owner, it clearly identifies the problem, and via the word “required” it is a clear call to action.
  • The one sentence questioned was the following:

    The instructions we provide will guarantee a secure, painless update.

    Particularly the word “guarantee” may be misleading as it is impossible to guarantee a painless update process. @nerrad shared multiple alternatives which he also added to the ticket. There was consent that at least “guarantee” should be replaced with “help with”.

  • An important thought that was emphasized again was that, while upgrading PHP is not that trivial, there needs to be a positive attitude and expressions being used about that in order to motivate site owners to proceed. It must not be too euphemistic though – updating PHP is undoubtedly more complicated than updating a browser for example.
  • Except for the one sentence it was agreed that the revised version is more accurate, on-point and in line with the wording used in core otherwise.

Next week’s meeting

  • Next meeting will take place on Monday, April 16th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss design feedback for the nag, as expressed in their meeting and on the ticket.
  • 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