Josepha 10:13 pm on May 29, 2019
Tags: ,   

Dev Chat Summary: March 29th, 2019

Announcements

@chanthaboune announced that since 5.2 has been successfully released, work will be resuming on the Team Leadership training. A blog post on make.wordpress.org/updates will be published for anyone wanting to help review the training materials or otherwise indicate they are interested in learning more about how leads lead in WordPress.

WordPress 5.2.2 Updates

5.2.2 co-lead @marybaum updated the agenda with the following proposed dates for bug scrubs and releases:

Bug Scrub: Wednesday, May 29, 2019, 14:00 UTC
Bug Scrub: Thursday, May 30, 2019, 18:00 UTC
Release Candidate 1: Monday, June 3, 2019, 19:00 UTC
 Bug Scrub: Thursday, June 6, 2019, 20:00 UTC
Release Candidate 2: Monday, June 10, 2019, 16:00 UTC
Final Release: Thursday, June 13, 2019, 16:00 CDT

Special thanks to @desrosj, @karmatosed, and @audrasjb who led bug scrubs in the past week!

Finally, requesting release packagers be available for the scheduled RC1 release on Monday, June 3, 2019.

WordPress 5.3 Updates

Owners of tickets currently milestoned for 5.3 are encouraged to triage them appropriately. If, as a ticket owner, you are unable to volunteer any time to your tickets in this cycle, please unassign yourself. I’d much rather know for sure that I have spots to fill/tickets to move than let anyone feel unnecessary guilt.

A few components are still assessing potential features to focus on. Once those are settled and focus leads have volunteered, then a finalized timeline for the release can be set. A mid- to late-August timeframe was hoped for, but maintainers were clear that expected features/focuses should be decided upon before more firmly committing to a final timeline. There’s no official, rigid requirement of an August release of WordPress 5.3.

@spacedmonkey asked if any key features have been announced for 5.3. @chanthaboune indicated that nothing is solid yet, and more confidence from maintainers about features that can reasonably completed for 5.3 is needed.

@spacedmonkey also inquired about what Gutenberg features should be expected for 5.3. @aduth pointed to a previous #core-editor chat that laid out the expected goals for Gutenberg updates in 5.3.

One of the aforementioned goals was a navigation block in Gutenberg. @spacedmonkey asked whether the new block will use existing menus from WordPress core. This spawned some debate between contributors about how menu data should be stored and the various admin interfaces used to interact with them. No decisions were made, and continuing discussion is encouraged on the relevant tickets at https://github.com/WordPress/gutenberg/issues/13690 and https://github.com/WordPress/gutenberg/pull/14856. See the Slack conversation for more of the debate.

Updates from component maintainers

Tickets were to be discussed, but time ran short, so they are included here for some additional visibility.

  • https://core.trac.wordpress.org/ticket/46957
  • https://core.trac.wordpress.org/ticket/24730
  • https://core.trac.wordpress.org/ticket/40878
  • https://core.trac.wordpress.org/ticket/43941
  • https://core.trac.wordpress.org/ticket/41685
  • https://core.trac.wordpress.org/ticket/19755
  • https://core.trac.wordpress.org/ticket/47021
  • https://core.trac.wordpress.org/ticket/47192

General Announcements and Open Floor

@sergey asked to open a conversation around changing the invalid and worksforme ticket resolutions in Trac to something more neutral and less confusing for users. The suggested change is: invalid → not-applicable and worksforme → not-reproducible. @chanthaboune suggested a Make post for that discussion to allow for a more in-depth discussion.

@desrosj raised a flag for the current, expected size of the upcoming 5.2.2 release. At the time of the chat, there were only 13 tickets in the milestone. Based on past precedent, the release seems to be a bit under the threshold of what usually warrants a minor release. No decision was made, and a make/core post will be created to prompt more discussion of the topic.

Finally, @xkon announced that #core-privacy code has been split into its own files, adhering more to the WordPress Coding Standards and helping with maintainability. Given the better code organization/separation of concerns, now’s a good time to get involved with #core-privacy.

Thanks to all the attendees and everyone else that contributes to WordPress! These notes were taken by @davidbaumwald and proofread by @chanthaboune.

#5-2-2, #5-3, #devchat, #summary

Jorge Costa 5:09 pm on May 29, 2019
Tags: , ,   

Editor Chat Summary: May 29th

Agenda, Slack Transcript

Announcements

Gutenberg 5.8 was released today, congratulations to everyone who participated in this release!

The release agenda for WP 5.2.2 is out https://make.wordpress.org/core/2019/05/28/5-2-2-release-agenda/.

Regarding the WP 5.2.2 release, from the editor side, we have two PRs to be backported. https://github.com/WordPress/gutenberg/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22Backport+to+WP+Core%22+is%3Aclosed+milestone%3A%225.8+%28Gutenberg%29%22+.

@youknowriad volunteered to backport the PR’s.

Task Coordination

  • @aduth
  • @youknowriad wants to work on
    • Exploring grid helpers when resizing images.
    • Exploring more animations (snackbars, moving blocks…).
    • document the release tool.
    • automate npm releases.
  • @nerrad
    • Implemented useSelect hook and it’s powering withSelect.
    • Is working on the useDispatch hook.
  • @gziolo
    • Spent one full working day triaging issues last week
    • https://make.wordpress.org/core/2019/05/27/the-block-registration-api-status-update/ – Is still awaiting feedback for the block.json proposal, hopes to finalize it this week.
    • Is helping @joen with improved UX for nested blocks.
    • Wants to start on Bring consistency to block toolbar for text blocks .
  • @mapk
    • Is working on a few Table block issues.
    • Is looking at word breaks in the Media_Text block.
    • Will look into custom fields checkbox in the Options menu.
    • Will check spacer block clearing floats.
  • @andraganescu
    • continues to work on the media blocks update flow.
  • @kjellr
    • Still helping support the nested block work from @joen
    • Thinking about providing suggested column layouts: https://github.com/WordPress/gutenberg/issues/15663#issuecomment-496568894
    • Narrowing down the icons for the Group block: https://github.com/WordPress/gutenberg/issues/15602
  • @jorgefilipecosta
    • Past week:
      • Worked on the widgets screen endpoints and frontend rendering of blocks in the widget areas, a summary of the work was posted in https://github.com/WordPress/gutenberg/issues/13204#issuecomment-496934219.
      • Worked on other enhancements e.g.: text color in the heading, link UI on the images and some editor bug fixes.
    • Next week:
      • Will explore a short term very specific project board to make organizing PR’s and issues easier.
      • Continue the work to solve generic block editor problems affecting the widgets screen and probably external usages of the block editor.
      • Address reviews on the image link UI.
      • Work on some bug fixes and UI enhancements e.g. explore insert by URL on cover and media text blocks to make them more similar to the other media blocks.
      • Improve the contrast checking to make aware of parent colors (e.g: group block) and solve some bugs.
  • @iseulde
    • Plans to continue with this roadmap: https://github.com/WordPress/gutenberg/issues/13778.
    • Is a bit busy with conferences.

To anyone reading this, it is possible to participate in the task coordination in an async way. Feel free to comment in this post with the tasks that you worked on during the last week and/or what tasks you plan to work on during the next week.

Inline color support

@paaljoachim asked participants in the core editor chat to discuss his comment https://github.com/WordPress/gutenberg/issues/8171#issuecomment-496304938, that proposes the addition of inline color support.

@youknowriad said:

I think that is something we can consider, it should be tracked in its own issue separately from the block level color support tracked in 8171.

@mapk volunteered to create an issue to track this task.

@iseulde said that this task is on the rich text roadmap, but would be good if there’s a separate issue.

@mapk referred that @phpbits volunteered to implement this feature. Thank you @phpbits!

@youknowriad would like some design and API explorations and referred that the following questions should be considered:

  • What inline formatting do we want to support aside colors?
  • Do we want to gather these in a panel/popover?
  • In terms of API, how can we control the availability of these options?

Open Floor

@iseulde proposed a dedicated place (a specific meeting/a channel) to have conversations related to the RichText component.

@youknowriad asked why does it need to be separate from the current meeting? While adding that he not suggesting we don’t do it but was wondering if a section during the core editor meeting could be dedicated to RichText when needed.

@iseulde shared that in her opinion core-editor has become very broad and she thinks it might be good to have something smaller. She is not sure about set meeting times, she thinks that perhaps just a space where people can chat async is enough.

The conversation went on with some people trying to understand the current challenges communication related to RichText faces, and some people showing support to the idea of a RichTextspecific communication medium.

@youknowriad ended the meeting by saying that we should experiment and see what works and asked @iseulde to keep us updated.

#core-editor, #editor-chat, #summary

Jorge Costa 12:23 pm on May 29, 2019
Tags: , ,   

JavaScript chat summary, May 28th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: dependabot

@netweb started the topic by referring that dependabot was enabled in Gutenberg-examples and helphub repositories and the bot is currently creating PRs to update the package-lock.json dependencies.

A discussion about specificities about how npm versions work, what type of PR’s dependabot is creating, and why dependabot is enabled went on.

Agenda: Add type module commonjs to the corresponding packages

@gziolo referred that we have several packages which use CommonJS and questioned why not to mark them according to the new spec.

@gziolo shared the PR that applies the change referred above https://github.com/WordPress/gutenberg/pull/15841.

@aduth asked if “type”: “commonjs” was not the default given that to be backward compatible having that default would probably be a need. @aduth added that he is looking forward to having consistent module import semantics across our packages.

@gziolo said he would do additional.

After meeting @gziolo commented on the referenced PR that he was able to confirm that commonjs is the default type, and proposed an alternative PR https://github.com/WordPress/gutenberg/pull/15879.

Agenda: New things on the wp.data api

@nerrad referred that useSelectwas merged. And asked for thougths about useDispatch i.e useDispatch( storeName: string ): Object along with useDispatchWithMap( dispatchMap:function ): Object<function>.

@youknowriad asked:

what if it’s useStoreDispatch and useDispatch? I’m thinking that the map implementation is important for us, especially because we only want to call some selectors when the handler is called. So the question I have is about which implementation should be the default (called useDispatch)

@aduth also gave support to that approach because that way useSelect and useDispatch both accept a mapping function as an argument.

@epiqueras asked what the function gives that is not possible to do directly with the returned dispatch function?

@aduth answered that he thinks that the one thing is direct access to the registry, which is used in some places to help performance (only call a selector when the action is actually dispatched).

The alternative of useDispatch just returning dispatch right was suggested.

@nerrad referred:

I think with the move to hooks I actually prefer useDispatch to either return dispatch or actions for a specific store because typically useDispatch will be used in concert with useSelect in a component.
That provides flexibility for the component to take care of memoizing (via useCallback etc) any aggregate onClick events etc using the value from the select and the dispatches.

And referenced that useDispatch in redux does not receive a map.

For context, a link from the react-redux project was shared https://github.com/reduxjs/react-redux/blob/v7-hooks-alpha/src/hooks/useDispatch.js.

People in the meeting arrived at a consensus that a good solution is just expose a single `useDispatch` without a mapping function that contains an optional parameter specifying the store name, and when called without argument just returns dispatch.

Other remarks

For people interested in GitHub Actions, @aduth explored a simple one to get the ball rolling: https://github.com/WordPress/gutenberg/pull/15826.

Package publishes were improved with regards to managing two-factor auth passcodes: https://github.com/WordPress/gutenberg/pull/15826.

#core-js, #javascript, #meeting-notes

Riad Benguella 9:48 am on May 29, 2019
Tags: , ,   

What’s new in Gutenberg? (29th May)

More than 42 contributors participated in this Gutenberg release. It includes a number of valuable improvements and two important bug fixes that are going to be backported into the next WordPress 5.2.2 release.

The work to improve the built-in block library is still ongoing. Heading blocks support custom text colors and we plan to expand this to other textual blocks in the future.

Gallery images can now be reordered inline without opening the media modal. Drag and drop support is being explored.

This release includes a working proof-of-concept of the block-based widgets screen. You’ll be able to edit/update your widgets areas using any available block. This will allow us to polish the UI and clear out bugs in the next releases.

5.8

Features

Enhancements

Bug Fixes

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 5.8.0 5.4s 64.9ms
Gutenberg 5.7.0 5.6s 65.8ms
Gutenberg 5.3 (WordPress 5.2) 6.1s 64.2ms
Gutenberg 4.8 (WordPress 5.1) 7.7s 150.6ms

👏 Kudos to all the contributors. Thank you.

#core-editor, #editor, #gutenberg

Andrés 8:19 am on May 29, 2019  

Editor Chat Agenda: May 29th

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

  • Updates
    • Gutenberg 5.8
    • WordPress 5.2.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

Robert Anderson 12:33 am on May 29, 2019
Tags: , ,   

Dev Chat Agenda: May 29

Below is the agenda for the weekly devchat meeting on Wednesday, May 29, 2019, 2000 UTC.

  • Announcements
  • Upcoming Releases Discussion
    • 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.

#agenda, #devchat

#core

Jb Audras 10:55 am on May 28, 2019
Tags: 5-2, ,   

5.2.2 Release Agenda

The last weekly dev chat meeting featured a call for leads for 5.2.2.

@marybaum, @justinahinon and @audrasjb are leading the release. @chanthaboune is managing communications among the different teams involved.

The current schedule shows final release for 5.2.2 on Thursday 13 June 2019.

Proposed agenda for this minor release cycle:

#5-2-2, #agenda, #bug-scrub

Ajit Bohra 9:15 am on May 28, 2019  

JavaScript chat summary, May 21st, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Maintaining Changelog

  • Updates to docs on maintaining packages change log.
  • Developers should not choose the version number for changes to packages, instead, add the changes to relevant subsection under “Master” heading.

Unstable APIs

  • Some discussion around listing and auditing various unstable APIs in use.
  • @nosolosw suggested automating the listing using JSDoc and was agreed upon.
  • These unsable API’s will be reviewed and removed on case by case basis.

Release Automation Tool

  • Current release process required manual intervention which was time consuming and prone to errors.
  • @youknowriad worked on the initial tool which helps in automating the process more details in PR

#meeting-notes, #core-js, #javascript

Grzegorz (Greg) Ziółkowski 7:04 am on May 27, 2019
Tags: block-directory, , , , ,   

The Block Registration API – status update

Build a WordPress.org directory for discovering blocks, and a way to seamlessly install them is one of the 9 priorities in the 2019 roadmap. This post tries to summarize work done so far and identify all the next steps required to land this project in WordPress core later this year.

It has been over two months since the Meta team published a post intended as a starting point for discussion and new ideas for the Block Directory, and a new type of plugin:

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory. They will be JavaScript-based, and each plugin will register a single Block. And they will be searchable and installable from within the Gutenberg editor itself.

@tellyworth

Currently, new Gutenberg blocks can be provided by plugins, which often register many blocks, and which are managed from outside the editor. The proposal mentioned above outlines a new type of simple block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. It was later followed up with the call for design on installing blocks from within Gutenberg. There was an essential technical aspect highlighted in the post:

The WordPress.org API will provide an endpoint for searching for blocks by name and description, and return metadata similar to that of plugins. Gutenberg’s Inserter could use that endpoint to also show relevant block plugins that are available to install, with a button and process for seamless installation.

@tellyworth

This new endpoint is going to be based on the Block Registration API RFC which intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project. In practical terms, it means that we are seeking for a solution where block type registration is declarative and context-agnostic. Any runtime (PHP, JS, Android, iOS or other) should be able to interpret the basics of a block type and should be able to fetch or retrieve the definitions of the context-specific implementation details.

Core Editor team reached the point where we believe that the Request for Comments is close to being finalized. However, there are still some areas where we feel that other WordPress teams could have a significant impact on the proposal.

Internationalization

The way how translations are handled inside JSON files is something novel for WordPress core. The current proposal for PHP follows the existing get_plugin_data core function which parses the plugin contents to retrieve the plugin’s metadata, and it selectively applies translations dynamically. It would be also similar for JavaScript, with the remark that we plan to implement a custom Babel plugin which would mirror PHP behavior for ESNext code. The transformation would happen during the build step to ensure that files can be statically analyzed before scripts are enqueued. You can find more details in RFC document in the Internationalization section. There is also an issue#15169 opened which describes the technical details of the proposed JavaScript implementation of the Babel plugin.

Core JS team discussed this topic at the end of the weekly meeting on Apr 2nd. We have received great feedback from @swissspidy which helped to shape the proposal. However, we still encourage other Polyglots team members to voice their opinions.

New REST API endpoints

The long term vision for the block discovery in WordPress includes:

  • Fetching the available block types through REST APIs.
  • Fetching block objects from posts through REST APIs.

The proposed implementation for the server-side awareness of block types should ensure that it stays intact with all recommendations that REST API team might have. That’s why we encourage the REST API team to get involved in the process early on. There is no immediate need to start working on new block type related API endpoints. However, it would be great to have it included on the roadmap. Ideally, they should stay as close as possible to the WordPress.org API and the final shape of the endpoint for searching for blocks.

#block-directory, #core-editor, #gutenberg, #i18n, #meta, #rest-api

Anthony Burchell 2:39 pm on May 23, 2019  

Media Meeting Recap – May 23, 2019

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, May 23, 2019. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused issues. The focus of this meeting, was around the timing of our meeting going forward.

Attendees: @karmatosed @joemcgill @desrosj @mikeschroder @antpb @anevins @sergeybiryukov @pbiron

Transcript: Read on Slack

5.2.2

It was discussed by @desrosj that #46052 would be great to have fixed to 5.2.2. There was discussion around wether or not this issue was a regression due to block editor or not related at all. Worth noting that this is happening also while using the Classic Editor plugin. Investigation is needed still.

5.3

Discussion began around the scope of Media for 5.3. There are 47 tickets in the 5.3 milestone. @desrosj mentioned that a few things need to happen to keep the scope manageable. If you have a chance, it would be great to review any tickets assigned to yourself in the 5.3 milestone and decide to punt or future release the issue. As he said,

Everyone should look at the tickets they own in the milestone and determine of the issue is realistic for 5.3. If not, please punt to Future Release (no shame in this!).

If the ticket is realistic, but you have lost interest or are not the best person to own anymore, please just remove yourself as owner.

There are 24 un-owned issues. I’d like to see all of these have an owner to help push these along during the release.

@desrosj

@azaozz has been graciously diligent in comprising a list of Uploads issues that should be prioritized. Most of all #40439 needs to be merged as soon as possible as it is currently a blocker for all of the issues in the list. For that ticket, @mikeschroder mentioned that some eyes/hands are needed on the UX/UI side for handling during the upload; likely a mix between the modal and Gutenberg. There is currently UI for testing in the patch but this is not the final design. This should aim to land early in the 5.3 cycle. The full list can be found below:

Improve processing of uploaded images

@pbiron brought up a ticket that would be great to have #44900 be considered for 5.3. It currently needs design feedback so that @pbiron can move it along. Any help there would be very appreciated.

The media team is also aiming for a A11y Media focused bug scrub at the beginning, middle, and end of the release cycle. More to come on that as they are scheduled. There are a large handful of smaller bugs that will not require a major amount of work to address in this cycle so they will be high priority. Any preferred times/dates for the scrubs are encouraged to be included in the comments below.

Next Meeting

The next #core-media meeting is set for Thursday, May 30, 2019 at 13:00UTC See you there!

#core-media, #media, #summary