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

Dev Chat Summary: June 13th (4.9.7 week 4)

This post summarizes the dev chat meeting from June 13th (agenda, Slack archive).

4.9.7 planning

Updates from focus leads and component maintainers

  • The PHP team posted summaries from their last two meetings covering progress and decisions on #43986 and #44350 as well as the approach for #43987. Join them next week on Monday, June 18th at 15:00 UTC in #core-php as they continue the discussion on these two tickets.
  • The REST API team would like a core committer’s review on #38323, so if you’ve got some time then please help out there.
  • And a reminder for those heading to WCEU that Contributor Day is tomorrow, Thursday, June 14th. If you’re in town, then please consider attending… thanks!
  • No design lead for Customize focus while @melchoyce is on sabbatical until September 10th

Devchat coordination

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats.
  • If you’re open to collecting agenda items and publishing an agenda, running the actual devchat meeting, and/or publishing a devchat summary then please comment here or ping @jeffpaul if you’re able to help out… thanks!

Next meeting

The next meeting will take place on June 20, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-7, #core, #core-customize, #core-restapi, #dev-chat, #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

Dev Chat Summary: June 6th (4.9.7 week 3)

This post summarizes the dev chat meeting from June 6th (agenda, Slack archive).

4.9.7 planning

  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, @tristangemus, @pbiron open to help contribute during 4.9.7
  • Waiting until after WCEU to confirm release leads and any potential focus for 4.9.7
  • Aiming to get someone who hasn’t lead a recent release and (who has prior experience contributing or has institutional backing to contribute to a release) to be nominated to lead or co-lead 4.9.7. Pairing that with assuming we’d get a more precise focus for 4.9.7 would mean we’d try and confirm leads in ~two weeks.
  • Working to communicate with other team reps and component maintainers to increase diversity in release leads by asking for nominations or suggestions in their next meeting/update, please share any ideas you have on this… thanks!

Updates from focus leads and component maintainers

WCEU preparation

  • Asking everyone to keep their eyes out for tickets that would be worth tackling at WCEU Contributor Day, please add good-first-bug keyword in Trac
  • Also looking for issues that need testing as that can provide another option for introduction to contributing
  • Code reviewing Gutenberg PRs, even just parts of PRs, could be a good chance for folks to wade into contributing
  • When reviewing a PR or Trac ticket, even leaving a comment like “I don’t understand what’s happening here, can you add documentation?” would be tremendously valuable
  • If there are patches that need refreshing, those can be useful to new contributors (if the refresh is easy) because it familiarizes them with the workflow of creating/submitting patches
  • Fixing coding standards issues are another good option for new contributors to learn coding standards while fixing them
  • Contact @flixos90 or @antpb if you have more pressing tickets that should be worked on during WCEU
  • Reminder to document any discussions about big changes (such as to coding standards) in a Make/Core post to share with everyone as not everyone can travel to WCEU

General announcements

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats. Please comment here or ping @jeffpaul if you’re able to help out… thanks!

Next meeting

The next meeting will take place on June 13, 2018 at 20:00 UTC / June 13, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-7, #core, #core-php, #dev-chat, #gutenberg, #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