PHP Meeting Recap – April 23, 2018

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 main focus of our recent meeting was reviewing the latest work around the upcoming php info widget.  A reminder that this work is being tracked here.

  • @schlessera presented the latest iteration of the widget for feedback which is this:
php widget screenshot 1

collapsed version:

php widget screenshot 2

Notable features of this iteration:

  • It is accessible.
  • It is more in line with the other widgets.
  • It makes the widget more noticeable when collapsed.
  • It makes use of a dash-icon instead of a notice border for drawing attention

General consensus seemed to favor this latest iteration.  However @johnjamesjacoby brought up some concerns about the verbiage and  language still in the widget.

  • Unnecessary “Click the button” type guidance
  • Running an insecure version of PHP doesn’t mean that a quicker website is a quick update away. (Note, this feedback was also left as a comment in the previous meeting summary post.)
  • Unusual for WordPress core verbiage to have “this is how we do it” type phraseology.

Responses were:

  • Let’s get this feedback on the trac ticket.
  • While most of us don’t completely like what we have now, it’s been through multiple iterations including incorporating suggestions from design and editorial teams.  So its “good enough” for now and we can iterate.

In the latter part of the meeting we focused on the following design comments:

  • Use the color red only if insecure version, otherwise use yellow/orange.
  • Collapse the nag by default.

Although it was brought up that it’s unlikely yellow/orange would ever be displayed because most scenarios will result in an insecure version of PHP prompting the widget to show, we agreed that its trivial to do conditional colors so it will be implemented.

However, the nag being collapsed by default is not a trivial change to make.  There’s no prior art for that with the dashboard widgets.  We decided to defer further discussion on this until the next meeting.

After Hours

Since the meeting @johnjamesjacoby provided additional feedback in the trac ticket and @flixos90 took some of what he suggested and proposed another iteration for the widget:

PHP widget - latest iteration.

Changes made in this iteration:

  • Fix incorrect statement “WordPress has detected that your site is running on an insecure version of PHP, which means that a faster website is just a quick update away.” by removing the second part of that sentence. That furthermore makes it a more clear statement, and the aspect of speed is mentioned in the second paragraph anyway.
  • Remove the whole last section that essentially just revolves around the user needing to click the button. It helps further shortening the copy, as requested by the design team, and was redundant.
  • Left-align button and make it regular-size, as requested by the design team and in 41191.11.2.diff@johnjamesjacoby We cannot shorten the button text itself, as “Learn more” makes it too unclear this link helps with updating PHP.
  • If the PHP version is not insecure, but only out-of-date, show the icon with yellow color, as requested by the design team. This change is to be future-proof, but note that at this point, it will never be rendered this way because we show the notice only on 5.2 which is insecure.

Next meeting:

Next meeting will take place on Monday April 30, 15:00 UTC in #core-php

Agenda:

  • Followup on the latest iteration of the php widget.
  • Decide on whether the widget will default to collapsed.

A reminder that if you have suggestions about the dashboard widget but cannot make the meeting, please leave a comment on this post (and/or comment in the trac ticket).

Dev Chat Summary: April 18th (4.9.6 week 3)

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

4.9.6 planning

Updates from focus leads and component maintainers

  • The Editor / Gutenberg Team released v2.7 and published information on how they’re organizing component-specific issues in their GitHub repo. Component Maintainers will benefit from utilizing the specific milestone setup for their component when trying to identify areas that would best benefit Gutenberg. There are also additional milestones for a11y and docs.
  • The GDPR Compliance Team published notes from their recent meeting covering recent deployments, available resources, plugin dev guidelines, and the addition of a privacy section to the readme.txt file
  • The PHP Team published notes from their recent meeting
  • The Media Team published notes from their recent meeting covering a time change for their meeting (to Thursday’s at 20:00 UTC) and their main focus on a Gutenberg Media triage
  • @jorbin looking for a proposal on Make/Core post from team working on the JS reorg / no longer using srcwith a summary and proposed timeline; majority of current info is in #43055

Next meeting

The next meeting will take place on April 25, 2018 at 20:00 UTC / April 25, 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-6, #core, #core-editor, #core-js, #core-media, #core-php, #dev-chat, #gdpr-compliance, #gutenberg, #summary

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

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

Dev Chat Summary: February 28th (4.9.5 week 4)

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

4.9.5 planning

Updates from focus leads and component maintainers

WCEU Contributor Day

  • @flixos90 looking for volunteers for the core team to lead WordCamp Europe contributor day.
  • @getsource will be there, but helping with Hosting Community
  • @kadamwhite will be there, but his experience from WCUS shows it may be better for REST API folks to embed with another team and support their efforts (e.g., the Editor team)
  • @antpb willing to talk on setting up a local for Gutenberg and Core development
  • @sergey will be there helping with Meta team, but open to helping with Core during afternoon
  • Also, please keep your eyes out on tickets that would be good to be tackled at WCEU contributor day
  • If you’re attending WCEU and interested in leading the core team or targeted sub-teams (JavaScript, REST API, etc.), then please reach out to @flixos90.

General announcements

  • Progress on implementing a way to catch the issue from the 4.9.3 release is being tracked in #43395
  • @mte90 looking for review on eight tickets:
    • #40810: patch has been refreshed including unit tests, needs review
    • #34706: needs review on whether work is required or not as the desired enhancement may already exist; @danieltj to take a look
    • #14148: needs review to see if a refresh is needed, otherwise needs testing
    • #17025: needs review before another likely refresh
    • #28112: needs review and docs; @audrasjb to test the patch
    • #36661: needs review
    • #15145: needs review
    • #17019: needs testing
  • @helgatheviking looking for review on #18584, but likely wait on this for now until Gutenberg lands as nav menus might get a bit of an overhaul

Next meeting

The next meeting will take place on March 7, 2018 at 21:00 UTC / March 7, 2018 at 21: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-5, #authentication, #contributor-day, #core, #core-php, #core-restapi, #dev-chat, #gdpr-compliance, #summary, #two-factor

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

Dev Chat Summary: February 14th (4.9.5 week 2)

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

4.9.5 planning

  • We’re looking for nominations for people to lead this minor release, self-nominations are very much welcome. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • No timeline set for 4.9.5, but minor releases tend to run 6-8 weeks so we’ll go with what fits with the release leads’ schedule
  • Potential focus for 4.9.5 could be support of foundational work needed to support Gutenberg

Updates from focus leads and component maintainers

  • The PHP team shared a recap from their recent meeting, thanks again to them for documenting that discussion
  • The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.
  • The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

  • Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.
  • Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work
  • Meta#3459 created to track this work

General announcements

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 2018 at 21: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-5, #core, #core-php, #dev-chat, #gdpr-compliance, #summary