WordPress Privacy Chat Agenda – June 20

Agenda proposal:

  • Stats (Trac tickets)
  • Roadmap
  • Feedback from WCEU Contributor day and the workshop
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#core-privacy, #agenda

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

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

This is the agenda for the weekly dev meeting on June 6, 2018 at 20:00 UTC / June 6, 2018 at 20:00 UTC:

  • 4.9.7 planning
  • Updates from focus leads and component maintainers
  • WCEU preparation
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-7, #agenda, #core, #dev-chat

WordPress Privacy Chat Agenda – June 06

Agenda proposal:

  • Welcome to new contributors
  • Info: Name change: slack channel, GitHub repository
  • Stats: Trac tickets stats
  • Roadmap
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#core-privacy, #agenda

GDPR Compliance Chat Agenda – May 30

Note: GDPR Compliance will be renamed to Core Privacy on June 1. The slack channel and post tags will be adapted accordingly.

Agenda proposal:

  • Info: Name change
  • Stats: Trac tickets stats
  • Info: Weekly bug scrub
  • Roadmap v2, v3
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #core-privacy, #agenda

GDPR Compliance Chat Agenda – May 23

Agenda proposal:

  • 4.9.6 vs 4.9.7 and 4.9.8
  • Roadmap v2
  • Ticket prioritization 
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #agenda

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

New PHP Polyfills in 4.9.6

It is considered good practice to validate variables before using them. As using type declarations is still very rare in the WordPress world, parameters passed in to functions may not be of the variable type expected. Similarly, the type of variable returned by a filter may have changed due to incorrect usage of the filter by plugins or themes.

One particular situation which causes bugs often is counting something which isn’t countable. Proper variable validation can prevent those bugs.

In PHP 7.2, a warning was introduced when count() is used on an uncountable value. PHP 7.3 will introduce the  function is_countable(), which will help prevent this warning by checking that the passed variable is actually countable (the RFC has passed the vote and the function has already been implemented and merged into PHP Core).

Using count() to detect if a value is iterable (able to be passed to a foreach() loop, for example), is also a common practice. However, this will also result in warnings when upgrading to PHP 7.2. In PHP 7.1, the is_iterable() function was introduced to help prevent these warnings.

To help WordPress Core, plugins, and themes be forwards compatible, a polyfill for each of these functions has been added in 4.9.6. When a site is not running a version of PHP that includes these functions, WordPress will automatically load these polyfills.

Checking A Value Is Countable

is_countable() was introduced in #43583.

Old Way

if ( count( $var ) > 0 ) {
        // Do something.
}

New Way

if ( is_countable( $var ) && count( $var ) > 0 ) {
        // Do something.
}

Checking A Value Is Iterable

is_iterable() was introduced in #43619.

Old Way

if ( count( $var ) > 0 ) {
        foreach( $var as $key => $value) {
                // Do something.
        }
}

New Way

if ( is_iterable( $var ) ) {
        foreach( $var as $key => $value) {
                // Do something.
        }
}

Updating Core

New tickets should be opened on Trac for instances in Core that would benefit from these new functions on a case by case basis. Since all instances of count() and foreach() should be verified, a meta ticket has been opened to keep track of which files have been checked (#44123).

Want to learn how to write better conditions?

To better understand how variables behave in various PHP versions, how to write better conditions, and to improve variable validation, you may like the PHP Cheat Sheets website.

#4-9-6, #dev-notes

REST API Meeting Summary: May 10

This post summarizes the REST API component team meeting from May 10 in the #core-restapi channel.

Gutenberg Priorities

Following up on this blog post outlining priority REST API issues affecting Gutenberg, we discussed ongoing work to address these questions. If you’re interested in helping with these projects, review the linked blog post and tickets in the Gutenberg “Merge Proposal: REST API” milestone; all assistance is welcome!

register_meta improvements

The remainder of the meeting was focused on ongoing discussion about upcoming changes to register_meta. Per the summary posted last week, we are introducing the ability to limit meta registration to a specific “object subtype” (e.g. specify meta for a single post type, rather than forcing registration for all post types equally). We will also be introducing wrapper functions such as register_post_meta() to encourage use of the new subtype argument. See ticket #38323 for the latest patch.

The REST API team requests review from committers and any developers with prior history around meta. There’s some great discussion going on but these changes will have a strong impact on how we do data-modeling in the REST API, so we want to make sure that all interested parties are involved. See in particular this comment on trac for a summary of the latest patch, and some remaining open questions:

  • Meta-registration wrapper functions are being introduced for term and post object subtypes; should we introduce wrapper functions for comment and user meta objects, which do not currently support the concept of object subtypes?
  • Are “object type” and “object subtype” the best names for these parameters? Are they good enough?

Please check out the ticket (#38323) for further discussion.