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 – 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 – 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

PHP Meeting Recap – April 2nd

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

  • Design feedback was not yet available to review, so this was postponed to next week.
  • Per #41191, @pento will ask the Automattic editorial team to review the wording.
  • @markjaquith brought up that the large amount of text currently in the nag may be too much. Since the PHP upgrade education page already contains detailed information, the nag should be more on point. Key points are:
    • PHP runs your site.
    • Your PHP is outdated.
    • Updating makes your site faster and more secure.
  • @flixos90 suggested to compare the nag with the one from Browsehappy which is way shorter. While upgrading PHP is not trivial, it should be possible to shorten the current copy so that it is only a bit longer than the Browsehappy message. Something like the following may work already:

    It looks like your site is using an outdated/insecure version of PHP. PHP is the programming language that WordPress is built on. To make your site faster and keep it secure, please upgrade the PHP version on your webserver.
    Learn how to upgrade my PHP (link)

  • It’s important to highlight the performance aspect of upgrading, not only the improved security.
  • @afragen shared his proof-of-concept for rejecting plugins that require a higher PHP version than available. While a core implementation would need to cover much more than the functionality present, it is a good source to start working from, and some of the code or ideas may be reused in the implementation for #40934.

Next week’s meeting

  • Next meeting will take place on Monday, April 9th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss design feedback and wording of the nag.
  • 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 – March 19th & 26th

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.

Chat log from March 19th
Chat log from March 26th

Chat Summary

Dashboard widget (#41191)

  • The voice of the widget text has been adapted to better match the overall WordPress feel.
  • The accessibility concerns that were raised have been addressed.
  • The widget currently looks like this:
  • The Trac ticket was flagged for ui-feedback and we are now waiting for the #design team to be able to go over the ticket. Once all of their feedback has been processed and incorporated, the version in trunk will be ready to discuss backporting it to the next minor release (4.9.6).

PHP version requirements for plugins & themes (#40934)

Next week’s meeting

  • Next meeting will take place on Monday, April 2, 2018 at 15:00 UTC in #core-php.
  • Agenda: [Go over #design feedback and] discuss how to proceed with plugin requirements.
  • 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, #summaries

PHP Meeting Recap – February 26th

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 agenda for the meeting was to discuss the API endpoint for which a first version was introduced the previous week.
  • It was ensured that the endpoint parses PHP versions correctly and allows for flexibility by parsing out the actual version number from strings which may contain additional environment-specific information.
  • Some concerns regarding the structure of the response were expressed, particularly related to redundancy, future maintainability and inconsistencies.
  • By the end of the meeting, it was agreed to go with the following response structure:
    • recommended_versionstring – The PHP version recommended by WordPress
    • is_supportedboolean – Whether the PHP version is actively supported
    • is_secureboolean – Whether the PHP version receives security updates
    • is_acceptableboolean – Whether the PHP version is still acceptable for WordPress
  • It was also decided to remove all IP address-related functionality, as it is unlikely that those will be needed in the future. Detecting hosts by IP address and maintaining host-specific data via the API would be a huge maintenance burden, and additionally passing the IP address would overcomplicate the current efforts by having to deal with possible privacy concerns.

Call for Testing

Since the meeting, the API endpoint has been updated to use the aforementioned response data structure, and an updated patch for the PHP nag in core, implemented as a dashboard widget like previously decided, is ready to be applied.

Please thoroughly test the API endpoint and patch. The API is already live, and the current plan for the patch is to commit it to core next week.

  • The API endpoint is available at https://api.wordpress.org/core/serve-happy/1.0/, and it requires a php_version query parameter to be passed.
  • The patch for the core nag is available at https://core.trac.wordpress.org/attachment/ticket/41191/41191.6.diff, making use of the API endpoint. When applied and your installation is not on PHP 5.2, you can “simulate” the behavior by going into the src/wp-admin/includes/dashboard.php file, looking for the wp_check_php_version() function and temporarily hard-coding ‘5.2’ in there instead of the actual PHP version. For the related ticket, see #41191.

Next week’s meeting

  • Next meeting will take place on Monday, March 5, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the patch for the core nag.
  • 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 – February 19th

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

  • Main topic for this meeting was to discuss the two different implementations of the servehappy notice we have so far:
    • an admin notice that appears at the top of all pages;
    • a dashboard widget that only appears on the dashboard.
  • @flixos90 quickly described the main benefits of the alternative dashboard widget approach:
    • it requires less logic;
    • it is harder to unintentionally hide;
    • it matches what the browsehappy project did.
  • We discussed how best to set the priority of the widget, so it won’t be displayed below the fold. @clorith noted that adding it to dashboard.php would ensure it is always shown first, just like the browsehappy one.
  • Those present during the meeting unanimously voted for the dashboard widget, instead of the admin notice. We thus decided to go with the alternative approach of the dashboard widget moving forward.
  • We decided to work on getting this into trunk for now, with the option of backporting it to the next minor release if there’s consensus later on.
  • The reshowing of the widget should not be included in the code for now, but could be part of the “database migration” code that gets run on updates. This lets us defer the decision of when to reshow.
  • The discussion then moved on to a ServeHappy API endpoint on wp.org that could be used to dynamically control the behavior of the dashboard widget.
  • @flixos90 has implemented a first version of the API endpoint following the details we’ve discussed, and it is already available right now: https://api.wordpress.org/core/serve-happy/1.0/?php_version=5.2
  • The information that is sent to the ServeHappy API endpoint (PHP version + indirectly IP address through server access logs) might have implications on GDPR compliance. We should raise this concern in the #gdpr-compliance channel.
  • We discussed how to let hosts provide upgrade information. A mechanism using constants or filters would be preferable to providing this through the API endpoint, as we’d want to decentralize this information and not maintain it ourselves.

Next week’s meeting

  • Next meeting will take place on Monday, February 26, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the new API endpoint.
  • 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 – February 12th

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 agenda was to discuss which version to include the notice in and how to deal with the dismissal functionality of the notice.

Release Plan

  • After requesting feedback in the #core channel, there were some concerns expressed about publishing the notice in a minor release (like 4.9.5), particularly because a notice like that suddenly being thrown from a minor release may seem weird.
  • However the amount of users affected by this would be very low, since only users on PHP 5.2 are initially targeted.
  • Releasing sooner than later would allow for quicker feedback and stats, to iterate based on those.
  • The decision was to go with the 5.0 release for now. When the notice has been merged into trunk, it can be reevaluated whether it should be merged in the minor release branch.

Notice Dismissal

  • Four initial possibilities were suggested to be considered:
    • The notice shouldn’t be dismissible at all.
    • The notice should be permanently dismissible.
    • The notice should be dismissible, but come back every month.
    • The notice should be dismissible, but come back every core update.
  • @clorith expressed concerns about heavier support load when bringing the notice back “unexpectedly”, like after a month. On the contrary, the notice being persistent is part to the solution, so people trying to get rid of it otherwise are doing it wrong.
  • If it needs to be brought back, that should preferably happen per (major) update.
  • Option 4 ended up to be the most viable one out of the suggestions.
  • @SergeyBiryukov then suggested to check how the existing Browsehappy notice does that. It was quickly discovered/remembered that the Browsehappy notice is not actually implemented as an admin notice, but as a dashboard widget.
  • That approach sounds promising too, so @flixos90 added he’ll work on an alternative patch for an implementation as dashboard widget.

Next week’s meeting: Admin Notice vs. Dashboard Widget

The agenda for next week is to decide on one of the following approaches to pursue:

Screenshots

Servehappy Admin NoticeServehappy Dashboard Widget

Benefits of admin notice

  • Very visually prominent.
  • Quick overview of details, layout similar like known welcome notice.

Benefits of dashboard widget

  • Not as easy to accidentally click away without looking, as fully dismissing requires to open screen options first.
  • Only shown in dashboard which appears to be more appropriate than everywhere.
  • Follows Browsehappy implementation, so less new code and tweaks required.

If you have any suggestions or feedback before the meeting, please comment on the Trac ticket or the individiual pull requests if applicable.

#core-php, #servehappy

PHP Meeting Recap – January 22nd

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 team has acknowledged our call for design help for servehappy and added a corresponding task in their Trello board. @jaymanpandya has stepped forward and was assigned this task.
  • We summarized again how we’re envisioning the site:
    • stand-alone design, as including it into the wordpress.org page design would reduce the impact and hinder proper optimization;
    • targeting site owners, with the option to make the content adapt to URL parameters for more precise targeting;
    • focused on easy consumption and avoiding overwhelm, with additional, more detailed content available as needed;
    • hosted on wordpress.org infrastructure and showing a small mention to the wordpress.org project;
    • not collecting usage data or feedback through the site, as that will likely get vetoed.
  • @jaymanpandya is an experienced UX designer and will work on a first set of mockups so that we can get a feel for how this might work as a real site.

Next week’s meeting

  • Next meeting will take place on Monday, January 29, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss UX mockups and hosting situation.
  • 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