Dev chat summary: July 17

@earnjam led the meeting. @marybaum took notes and is writing this summary.

Announcements

Gutenberg 6.1

@earnjam announced the release of Gutenberg 6.1 last week. New features include animations/motion to block reordering, improved messaging for REST API errors and more.

Check out the release post for more details: https://make.wordpress.org/core/2019/07/10/whats-new-in-gutenberg-10-july/

Look for version 6.2 RC to land next week.

PHP Coding Standards

@pento posted a followup to some proposed coding standards changes from a few months back.
See the decisions on these changes here (they might surprise you!): https://make.wordpress.org/core/2019/07/12/php-coding-standards-changes/

And keep in mind these affect only the code for WordPress Core. In your own Themes and Plugins, use the coding conventions that make sense for you.

Releases

5.2.3

With four tickets in the queue and none of them affecting functionality, it’s still not clear that they warrant a separate 5.2.3 release. Scheduling for that is still pending further info on a roadmap for 5.3, which should land in early fall.

5.3

As yet the Core team is progressing on current open tickets — there are 57 in the queue — while @chanthaboune continues gathering data from component maintainers on feature priorities for 5.3.

Component maintainer updates

Core-media

@azaozz asked for more eyes on #40439.

If you can help test, please check out the ticket or head to #core-media.

Site-health

@clorith pointed to the call for input for bumping the PHP recommendation and said that soon a Make blogpost will outline next steps—and next versions.

For now, the site-health team isn’t looking to raise the hard minimum. This will be a soft bump up to nudge users toward the minimums that will follow.

Open Floor

Triage Team

@joyously asked about progress from the Triage Team, and the responses came from several quarters.

@desrosj posted a link to his three-month summary: https://jonathandesrosiers.com/2019/06/wordpress-triage-team-3-month-reflection/ and plans to post more often on https://make.wordpress.org/updates.

@karmatosed mentioned that Design holds two triages a week, and that from where she sits, triage seems to be going gangbusters and spreading across the WordPress Project.

@azaozz pointed the group to his efforts on TinyMCE: https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=TinyMCE&order=priority

@marybaum mentioned having been in an accessibility triage last Friday.

Gutenberg Phase 2

Newcomer @Lu asked about the timing of Gutenberg Phase 2, with a particular interest in widget blocks. @earnjam answered with a summary of the release discussion earlier in the chat.

Strings

@marybaum asked the group for their thoughts on a more systematic, global approach to the copy in strings.

For now, the group agreed to have #meta add two keywords to tickets—needs-copy-review and has-copy-review.

Props to @garrett-eclipse, who opened meta#4609 and its counterpart meta#4610 on the spot.

Right at the close of the official chat, @audrasjb linked to https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance

#dev-chat, #gutenberg, #releases, #strings, #triage-team

Dev Chat Agenda: July 17

Here is the agenda for the weekly dev chat meeting at July 17, 2019 at 20:00 UTC.

  • Announcements
  • Upcoming Release Discussions
    • Point release
    • Major release
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.

#5-3, #agenda, #devchat

Editor chat summary: Wednesday, July 17th

This post summarizes the weekly editor chat meeting on Wednesday, 17 July 2019, 15:00 GMT+2 held in Slack.

The agenda followed can be found here.

Gutenberg 6.2

Slack archives

RC due to next week. Milestone (12 issues open).

Task coordination

Slack archives

Some people are away this week.

  • @karmatosed is focusing on triage and board coordination. Also doing a few design reviews.
  • @kjellr is working on tips improvements and Patterns API designs.
  • @mapk is working with Tammie on widgets screens reviews and recorded several issues for testing. Helping to keep the icon + labels PR moving forward.
  • @nosolosw is reviewing some open Drag&Drop PRs.
  • @aduth has some work on custom sources for block attributes (meta attributes and site options). Also implementing local storage-based autosave backups.
  • @jorgefilipecosta is handling block style improvements. Also reviewing PRs while focusing on RichText, among other bug fixes.
  • @welcher Adding priority to SlotFill system.
  • @chrisvanpatten plans to announce a Gutendocs bug scrub soon (aiming at Monday morning eastern time, probably next week).

Open Floor

Tammie suggests testing as a good way to get involved in the project. The “needs testing” label is a good starting point to review Pull Requests that need help.

Editor Chat Agenda: July 17th

Note taker: @nosolosw

This is the agenda for the weekly editor chat meeting on Wednesday, July 17, 2019, 3:00 PM GMT+2.

  • Gutenberg 6.2
  • Tasks Coordination
  • Open Floor

This meeting is held in the #core-editor channel in the Making WordPress Slack.

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #editor-chat

PHP Coding Standards Changes

This is a follow-up to several changes proposed a few months ago.

While reading these changes, it’s important to keep in mind that they only apply to WordPress Core: you can (and should) choose practices that best suits your development style for your own plugins and themes. The coding standards are intentionally opinionated, and will always lean towards readability and accessibility over being able to use every possible language feature.

Closures (Anonymous Functions)

There was quite a lot of discussion around this proposal, particularly with regards to allowing closures as hook callbacks. Thank you everyone for your input, and for keeping disagreements respectful. 🙂

We do need a decision, however, and there were several key points that led to this:

  • It’s currently difficult to remove closures as hook callbacks. #46635 has several interesting proposals to address this in an entirely backward compatible manner.
  • While WordPress Core should strive to allow any callback to be unhooked, plugins have no such restriction.
  • The WordPress JavaScript Coding Standards allow for closures to be used, we should be aiming to bring the PHP standards in line with that.
  • The broader PHP world has embraced closures for many years, and have found ways to use them responsibly. We shouldn’t ignore PHP usage outside of WordPress.

With these points in mind, a conservative, but practical step is to allow closures as function callbacks, but not as hook callbacks in Core. Ultimately, we should be able to allow any sort of complex callback to be attached to hooks, but the Core APIs aren’t quite ready for it yet.

Coding Standards Change

Where appropriate, closures may be used as an alternative to creating new functions to pass as callbacks.

Closures must not be passed as filter or action callbacks, as they cannot be removed by remove_action() / remove_filter() (see #46635 for a proposal to address this).

Short Array Syntax

A little less controversial, but still with varying opinions, was the proposal to require short array syntax ( [ 1, 2, 3 ] ) instead of long array syntax ( array( 1, 2, 3 ) ) for declaring arrays.

While I’m personally partial to short array syntax, there were two particularly convincing arguments for using long array syntax:

  • It’s easier to distinguish from other forms of braces, particularly for those with vision difficulties.
  • It’s much more descriptive for beginners.

So, this change to the coding standards is the opposite of what was originally proposed, but is ultimately the more inclusive option.

Coding Standards Change

Arrays must be declared using long array syntax in WordPress Core.

Short Ternary Operator

The original proposal was to allow the short ternary operator, but this change reverses that. There’s a good argument that it looks too much like the null coalesce operator, especially as they perform different functions.

Take the following example from Core:

$height = isset( $data['height'] ) ? $data['height'] : 0;

It’s not possible to reduce this line with the short ternary operator, but it can be trivially reduced with the null coalesce operator:

$height = $data['height'] ?? 0;

The vast majority of other ternary operators in Core (which don’t have an isset() test) look something like this:

$class = $thumb ? ' class="has-media-icon"' : '';

This also can’t be reduced using the short ternary operator.

As the null coalesce operator is a useful addition (which we’ll be able to use once the minimum PHP version bumps to 7+), whereas the short ternary operator can only be used in a handful of cases in Core, it’s better to avoid the potential confusion, and not use the short ternary operator.

Coding Standards Change

The short ternary operator must not be used.

Assignments Within Conditionals

Particularly when there are multiple conditions, it can be quite difficult to spot assignments occurring in a conditional. This arguably falls under the Clever Code guidelines, but hasn’t been formalised.

I got a little ahead of myself with this one, and have already removed all assignments in conditionals from Core. Adding this change to the standard formalises the practice.

Coding Standards Change

Assignments within conditionals must not be used.

#php, #wpcs

Dev Chat Summary: July 10

In @chanthaboune‘s scheduled absence, @ianbelanger served as the facilitator for the chat.

Announcements

@joyously called attention to the recent Make post for feedback regarding the upcoming User & Developer Survey.

Upcoming Releases

Minor Release (5.2.3)

Currently, there are only three tickets milestoned for a potential minor before 5.3.

@audrasjb encouraged a quick decision regarding a 5.2.3 release given the current list of tickets deal with regressions. @desrosj suggested that some block editor features could be backported for a point release.

Major Release (5.3)

Final features and focuses have yet to be determined for the next major release, nor has a final schedule been announced.

Open Floor

@francina mentioned ticket #11302.
@ramiy called attention to ticket #35774.

This summary was drafted by @davidbaumwald and proofread by @sergeybiryukov.

#5-3, #devchat, #summary

Editor chat summary: Wednesday, 10 July 2019

This post summarizes for the weekly editor chat meeting on Wednesday, 10th July 2019, 13:00 UTC held in Slack.

Gutenberg 6.1

Thanks to @noisysocks for the release of Gutenberg 6.1.  Highlights include:

  • motion on block reordering, 
  • performance improvements, and
  • a new `PluginDocumentSettingSlot` enabling third-party developers to add panels to the document settings sidebar.

Very nice to see the editor becoming more polished over time. For a fuller description, please view this post and be sure to check out the short video that helps make the changes come alive.

Task Coordination

  • @mapk catching up on all the amazing work and jumping in to review and help keep things moving forward.
  • @aduth 
    • Custom block sources work is nearly ready for merge (currently a refactoring for meta attributes, but will build support for other sources like post properties, site options, etc) https://github.com/WordPress/gutenberg/pull/16402
    • Started exploring localStorage-based autosaves https://github.com/WordPress/gutenberg/pull/16490
    • I’ve got a few reviews I need to catch up on
    • Hopefully planning to tackle some lacking documentation I’ve seen mentioned in this channel over the past weeks
  • @youknowriad

has reviewed a bunch of PRs:

  • – Custom block attribute sources
  • – Mobile unit tests to be added to CI
  • – Smaller PRs here and there.

And worked on several things:

  • – Performance improvements
  • – Try to build a better Drag and Drop
  • – Work on accessibility: Edit and Navigation Mode
  • – Some low-level refactorings (Slots)
  • @getdave
    • Merged PR to allow alternative Blocks to register themselves to handle Grouping interactions (side benefit: also removes hardcoded refs to core/group within transformation logic)
    • Working on PR to add a grouping flag to the Block supports. This will allow Blocks to opt-in/out of being available to be grouped. This is because certain blocks shouldn’t be Groupable (eg: single column block).
    • #16278 Update to allow alternative Blocks to handle Grouping interactions
  • @epiqueras
    • – Reviewed: Custom Sources PR.
    • – Opened: FSE Templates PR, Block Invalidation Fix PR.
    • – Closed: Some issues that were fixed by parallel PRs.
  • @karmatosed
    • deep diving into the ‘needs design’ and ‘needs design feedback’ labels. My focus is on what can we ship, what needs to be made into multiple issues (some conversations grew) and what can have a quick mock to just get coded to see.  
    • Considering splitting out our project boards for ease.
  • @kjellr
    • I have a quick fix for @tellthemachines helpfully pinpointed the reason for failing tests in the borders + padding for nested blocks PR, but it’s still a little fragile, so I’d love another set of eyes.
    • I’m working on getting a V1 ready for the new Tips implementation, so @noisysocks can begin development:
    • Helping sort out a possible way to add a circular block style for images:
    • Working on comps for the Patterns API:
    • Finally, I’d love a dev to pick this one up at some point.
  • @joen created this PR to improve the consistency of how the trailing appender works in nested contexts. 
  • @jorgefilipecosta submitted a PR that expands block styles allowing users to select a default style per block, submitted some bug fixes and merged old PR’s. Reviewed RichText refactors, live drag drop, custom parser options, and widgets in the customizer

Open Floor

  • @tellthemachines opened a new issue around automated tests and documentation on expected behavior. She’s looking for feedback in GitHub so unit testing can be better documented and easier to implement for all contributors. New contributor feedback is requested to further improve the tests. @mapk suggested a post about the topic to share information.
  • @spacedmonkey wants to add a custom block to the list of allowed blocks when extending the core/media-text block.
  • @spacedmonkey requested direction for an issue allowing inner blocks to be defined at the block level, making them filterable. While similar to the concept of child blocks opened under @youknowriad suggesting opening a new issue in GitHub rather than reopening previous issue
  • @aduth will be restructuring GitHub tags to  remove “Theme” from “Plugin & Theme Interoperability”, add a new “Themes” label and will update descriptions

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

The agenda for the next meeting, 17 July 2019 13:00 UTC is here, please add anything you want to discuss.#meeting-notes, #core-editor#editor-chat#summary

Site Health Chat Summary: July 8th

PHP Version – soft bump

Note: The soft bump is the term referring to the PHP upgrade notice widget shown in the dashboard, and not the minimum requirement to use WordPress.

The discussion on what version to start recommending users upgrade to is going on in the comments at https://make.wordpress.org/hosting/2019/07/01/what-should-the-next-php-version-recommendation-be/, but we also covered them a bit during the Hosting meeting this week.

Currently it seems the best approach would be to recommend updating to PHP 7.1 (skipping 7.0 as it’s technically not maintained any more), but we’ll leave the conversation going out the week, then make a decision on this next week. After a version has been decided on we make it known via posts to the make blogs what the intentions are, and what versions we are aiming for, and then make thew bump. This should allow hosts and developers some time to prepare for the potential support requests.

Ticket review

We covered a couple of tickets as well that were brought up by participants.

#47651 – This has been flagged for design feedback, as it needs a UI/UX perspective to help with direction and user flow.

#47644 – This has a patch, but after some discussion it will need a refresh to help with making it a bit more friendly towards the average user.

#47321 – This had some initial discussions in the channel after the meeting, but during the meeting it was covered that it needs some copy-editing. The ticket will have the outcome of the copy-discussion added once a final decision has been made.

#46925 – The ticket is ready, but was unfortunately not reviewed yet. It will get reviewed this week, and we will hopefully be more on top of tickets now that they’re more easily categorized.

Read the meeting transcript in the Slack archives. (A Slack account is required)

#site-health

What’s new in Gutenberg? (10 July)

A few weeks ago, Matías shared a post about using motion to express change in reactive UIs. This release is a first step in implementing those ideas. It introduces motion to block changes, creation, removal, reordering.

In addition to a number of other improvements and bug fixes, the contributors also worked on typing performance. As of this release, typing is 30% faster on long posts.

6.1

Enhancements

Experiments

Bug Fixes

Performance

Documentation

Various

Mobile

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 6.1.0 5.2s 56.89ms
Gutenberg 6.0.0 5.4s 80.2ms
Gutenberg 5.3 (WordPress 5.2) 4.9s 66ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Dev Chat Agenda: July 10

Here is the agenda for the weekly dev chat meeting at July 10, 2019 at 20:00 UTC.

  • Announcements
  • Upcoming Release Discussions
    • Point release
    • Major release
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.

#5-3, #agenda, #devchat