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 – May 7th, 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

At this meeting there was some continued conversation around plugins & theme php version requirements (see parent ticket here)

  • @sergey has made some progress on technical restrictions
  • #design feedback will be needed as a part of implementing how restrictions are communicated to the user.
  • Initial goal for this is block installation of plugins in environments that don’t match php requirements for the plugin.
  • @flixos90 is going to get in touch with the design team regarding feedback on the mockups.

Also on the agenda was continued conversation around design/layout work for the PHP upgrade page. We took a look at this mockup that was done by @jaymanpandya, however for the most part we felt that in order to progress on this, the feedback needs to come from the #design team itself and those involved in the design of the overall WordPress.org site. To that end, @flixos90 has created a ticket in meta for tracking this and this is a callout to anyone involved in #design (and particularly with regards to the overall design of WordPress.org and how this would fit in with that) to review the current mockup and add comments.

Next Meeting

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

Agenda:

  • Followup on php requirement restrictions for plugins/themes (hopefully with some design feedback).
  • Followup on PHP upgrade page design feedback (if there is any).

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 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).

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

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