REST API Meeting Agenda for Nov 7

The REST API weekly component chat will occur this week at November 7, 2019 18:00 UTC in the #core-restapi Slack channel.

Please note: We have not changed the UTC time for this meeting. If your country has recently adjusted for daylight savings time, this may be a different hour than the past few months.

Agenda Items:

  • Continue discussion from WordCamp US around a canonical authentication solution and begin tasking out work towards that effort
  • Discuss priorities for the 5.4 development cycle
  • Discuss needed documentation improvements
  • Open Floor

All agenda items are welcome, from all teams and contributors; please post them as comments below or let us know by joining the meeting.

#agenda, #rest-api

Core editor chat summary November 6th, 2019

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 6th November 2019 held in Slack, moderated by @karmatosed, notetaker: @itsjusteileen.

Weekly Priorities

WordPress 5.3RC4

WordPress 5.3 is currently scheduled to be released on November 12 2019, but we need your help to get there—if you haven’t tried 5.3 yet, now is the time!

November Gutenberg Priorities

Priorities for the coming month are categorized into these three headings: 

  • Block Content Areas,
  • Menu Navigation Block, and 
  • Tightening up existing interactions

For more details, consult this recent post.

Task Coordination

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

@karmatosed

  • Catchup after WCUS: so many good conversations about the editor!
  • Navigation block and catching up on reviews is my top priority.

@getdave

  • merging experimental `LinkControl
  • merging new link UI into the experimental Nav Menu Block 
  • Removing experimental flag soon, view progress dashboard is constantly updated with issues and PRs
  • Merged `DimensionControl` and `ResponsiveBlockControl` for creating Block Controls that require per-viewport “responsive” settings
  • Adding to the Group Block. Would love some eyes on this soon. 

@andraganescu

@bartczyz Taking on Special characters in permalink not being properly converted 

@copons started PRs for Site Description block: 

@nerrad — requesting review for PR that exposes a simple api for wrapping react elements for new feature: Introduce __experimentalCreateInterpolateElement. While I recognize this is not a complete solution, I think it provides an api for working with interpolated elements that also solves the need for i18n in those contexts.

@tellthemachines working on:

  • reviewing nav-related PRs
  • reviewing/testing the font size picker PR
  • picking up PR #13203 Responsive View Controls in Gutenberg

@noisysocks doing some work on replacing the NUX dot tips with a welcome guide modal.

@gziolo worked on Storybook integration

  • Playground awaiting review PR #18191
  • Progressing with explorations for Patterns API for blocks
  • Proposal for an experimental API PR #18270 
  • API integrated with the Columns block PR #18283
  • Will continue with Patterns API integrating proposed API with more blocks and extract common logic as an initial screen for blocks that define `patterns`

@nukaga

  • PR #18162 Updates columns index.js adding translatable (i18n) where a series of sentences displaying “lorem ipsum” was not translatable.
  • Looking at PR #15827 Twitter URL Embed automatically in Preformatted Blocks. Bug confirmed by @nerrad and ready to be picked up for work.

Open Floor

@pbrocks proposes picking up with adding SASS/PostCSS to wp-scripts process

@noahtallen looking for discussion and feedback about the block template API in his comment on Github.

@jesserh asking for review on PR#18164 to define allowed blocks per column

Announcing the new #core-css Slack channel

As a result of discussion in the last core dev chat we now have a brand new Slack channel dedicated to all things CSS!

Why do we need it/what is it for?

As a place to discuss CSS architecture and tooling, propose and maintain standards, ask questions and educate on best practices.

We have a ton of CSS in Core, and some of it is really old. Not that being old is in itself a bad thing 😁 but we might not need to support IE6 anymore, so some of those styles could use a bit of an upgrade. Having a dedicated CSS channel will help drive and focus efforts to improve our codebase for the benefit of all users and contributors.

In addition to that, we have a whole heap of CSS in Gutenberg, which, although more modern, needs care and maintenance too. 

There’s also something I perceive as a visibility issue. For instance, there’s a bit of a discussion going on in the GitHub repo around whether we should adopt CSS-in-JS tooling. It came up a few weeks ago in #core-js, and although to some extent it makes sense to discuss JS-based approaches in the JS channel, there’s a lot more at stake here than just the JS side of it. Not all contributors to the CSS parts of the codebase are JS devs, and not all of them are in the JS channel. It might be good to pull issues like that one into a CSS forum so we can get more diversity of input and opinions on them. 

Last but not least, CSS is transversal to Core and Gutenberg, and I hope a shared channel will help keep that wider scope in mind when we think of the changes we need to make on either side ❤️

Come and be part of the discussion in #core-css!

Dev Chat Summary: November 6, 2019 (5.3 week 12)

This post summarizes the weekly dev chat meeting from November 6th 2019 (agenda / Slack archive).

Announcements

WordPress version 5.3 Release Candidate 4 was released on Tuesday 5th. Everyone please help by testing out the RC.

Upcoming Releases – 5.3

@joyously asked where to look to see how translations are going for WordPress 5.3. @mapk shared the link to the project summary on Translate.

@collet raised some issues discovered on Twenty Twenty:

  • One issue related to nested rules in full-width Group & Cover blocks: 965.
  • Four issues related to column block: 960, 961, 962 and 963.
  • One issue related to nested blocks on starter content: #959
  • Also mentioned a pull request (701) that would be a worth inclusion in 5.3

@johnbillion answered Twenty Twenty can be updated independently of core. It’s ultimately up to the team behind the theme to decide if any of these bugs need to go into Twenty Twenty before 5.3 is released, or whether they can wait until a patch release of the theme.

@anlino will take a look at fixes for the columns issues today and tomorrow. Hopefully he can get those fixes before 5.3 final release. If there isn’t time to get them tested and merged properly, at least we’ll have the fixes good to go post-release.

The issues will be discussed in Twenty Twenty GitHub repository and in the core-themes and core-editor Slack channels to see what can land in time for final release of 5.3.

@collet also mentioned an issue related to the About page. In the about page. it’s said that “Heading blocks now offer controls for text and background color”. However, there is no control to change the background color inside the editor. It doesn’t appear to be related to Twenty Twenty. It needs to be updated in the About page.

Finally, @mikeschroder asked for more testing concerning a recent post published on Make/Core: Use of the “wp_update_attachment_metadata” filter as “upload is complete” hook

Open floor

@isabel_brison asked if a core-css channel could be created on Make WordPress Slack team to discuss CSS stuff. Given the amount of positive reactions, the Slack channel was immediately created by @peterwilsoncc 💥🕺💃

@mpcube asked for a review on ticket #48506. Discussion to continue in the proper ticket.

Move Dev chat meeting time (end of daylight saving time)

@audrasjb asked for a final decision about moving the dev chat meeting time with end of daylight savings time (DST). The meeting attendees agreed to move it from 20:00 UTC to 21:00 UTC starting on Wednesday 13th November. The New Contributor Meeting will also move from 19:00 UTC to 20:00 UTC.

These notes were taken by @audrasjb and proofread by @davidbaumwald

#5-3, #css, #devchat, #twentytwenty

Dev Chat Agenda for November 7, 2019 (5.3 week 12)

Here is the agenda for the weekly meeting happening later today: Wednesday, November 6, 2019, 08:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
    • Move Dev chat meeting time (end of daylight saving time)
  • Recap from WordCamp US Contributor Day
  • Upcoming Release Discussions
  • 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. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3#agenda#devchat

Editor Chat Agenda: 6 November.

Note taker: @mikeschroder

This is the agenda for the weekly editor chat scheduled for Wednesday, 6 November, 2019, 09:00 AM EDT.

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

  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

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

#agenda#core-editor#editor-chat

Use of the “wp_update_attachment_metadata” filter as “upload is complete” hook

As previously mentioned in Updates to Image Processing in WordPress 5.3 and Introducing handling of big images in WordPress 5.3, there have been changes in image post-processing after upload.

In WordPress 5.3, the image metadata is saved after each intermediate size is created to allow the processing of images to happen over multiple requests. This means the wp_update_attachment_metadata filter is run repeatedly while the image sub-sizes are being created. This fulfills the intended use of the filter, to let plugins “filter” the metadata before saving it to the database. It runs on all metadata updates, like when editing an attachment post, in wp_ajax_crop_image(), or to update the ID3 data for audio files.

However, some plugins are using the wp_update_attachment_metadata filter as an “upload is complete” hook (#48451). The changes in 5.3 are great for plugins that benefit from processing smaller amounts of information/images at a time, but may trigger more overhead/unneeded processing for plugins that bulk process images using that filter. A better hook to use for these cases is wp_generate_attachment_metadata.

An alternative solution may be to add context (by adding another parameter) to the wp_update_attachment_metadata filter.

The most likely plugins to be affected are those that use wp_update_attachment_metadata to do additional post-processing of uploaded files. After a plugin repo search, some examples of plugins that do this are Smush Image Compression and Optimization, WP Offload Media Lite for Amazon S3, DigitalOcean Spaces, and Google Cloud Storage, EWWW Image Optimizer, ShortPixel Image Optimizer, Compress JPEG & PNG images, Imagify – WebP & Image Compression and Optimization, a3 Lazy Load.

It would be ideal if the authors of potentially affected plugins could test and update them, if necessary, to continue working well in WordPress 5.3 or share any difficulties encountered on #48451.

Core-Privacy office hours agenda for 6 November 2019

The #core-privacy team had a great WordCamp US, with a brilliant talk from @riankinney on CCPA as well as a burst of effort on contributor day.

To keep that momentum going, we would like to run a full office hours at our usual time this Wednesday, 6 November, at 1900 UTC in our Slack channel. All are welcome.

Our loose agenda includes:

#core-privacy

Join the Gutenberg Customization Conversations 🎨

As we head towards the end of the year, two last projects surface as the culmination of the Gutenberg Customization phase. If you are interested in contributing, or want to join the ongoing discussions, this post outlines what the main focuses are and the threads to follow.

Full Site Editing.

Over the past eight months activity has focused on refining the editor experience, converting widgets to blocks, defining block areas, creating a new navigation block, introducing global blocks like site title, and several new tools to improve the customization capabilities of blocks. The idea is for all these elements to come together in an editor mode that comprehends the full structure of a site, including its global elements and dynamic pages.

Label “[Feature] Full Site Editing” in the repository for more details.

Block Patterns.

While blocks are powerful visual tools to achieve many different designs, it can take time and knowledge to combine them properly to achieve the most pleasing results. Since Gutenberg already supports block templates, it should be possible to offer users designs and patterns that are already assembled for them — made of various existing blocks — which users can then customize to their will with familiar tools. Part of this work includes exposing relevant APIs so these can be more easily developed and discovered.

You can also join the weekly meetings held in the #core-editor channel in the Making WordPress Slack, every Wednesday at 13:00 UTC.

Thanks for the help!

#gutenberg

Core editor chat summary October 30th, 2019

This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 30th October 2019 held in Slack, moderated by @mcsf, notetaker: @pbarthmaier.

Weekly Priorities

Gutenberg 6.8 and WordPress 5.3RC3

Gutenberg 6.8 had its RC on Monday and is ready to be released. @ella has offered to wrangle the release and release post! (edited)  

The third release candidate for WordPress 5.3 is now available! WordPress 5.3 is currently scheduled to be released on November 12 2019, but we need your help to get there—if you haven’t yet tried 5.3, now is the time!

A few things that might be good to fix in time for a potential WP 5.3 RC4:

I’d appreciate some eyes on these! I believe @jorgefilipecosta had something prepared for the latter.

November Gutenberg Priorities

Priorities for the coming month are categorized into these three headings: 

  • Block Content Areas,
  • Menu Navigation Block, and 
  • Tightening up existing interactions

For more details, consult this recent post.

Task Coordination

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

@getdave

Related to Nav Menus – a new experimental Link UI to standardise the interface for adding links has been merged.

Also merged experimental `DimensionControl` to provide a standardized user interface for controlling Block dimensions.

This is closely linked to the ongoing PR for `ResponsiveBlockControl` which enables per device/viewport settings for a given control https://github.com/WordPress/gutenberg/pull/16790. These are both related to the wider goal of enabling padding/margin adjustment on the Group Block via the editor. Looking for input and feedback on the later PR.

@joen addresses a frustration with the complex left and right margins and paddings that every block gets in this PR: this should make things easier for block developers and themers, ie styling the editor and building delightful blocks without complex CSS. The downside is, it’s a complicated refactor, and it will create issues in some existing editor styles, like TwentyNineteen. But I would argue it’s worth it, and a perfect candidate for kicking off the 5.4 cycle once 5.3 lands.

@mcsf  I’ve been targeting a good deal of my reviewing to the monthly priorities. Folks have worked a lot on improving the block appender and other pieces crucial for the Menu Navigation block, kudos to them

@andraganescu I am working on adding a link to the media and text block, fixing the selection when switching inspector tabs and reviewing/testing everything open for the navigation menu block

@gziolo I’m slowly learning about Patterns API for block and I plan to start development later this week. I also spent a lot time reviewing new stories for the Storybook and further polishing the integration with snapshot testing

@jorgefilipecosta Since the last week, we iterated and merged many of the gradient related PR’s. We now use the class mechanism on the button gradients. I helped the new experimental colors hook to land, and I have been involved in refactoring some blocks to be functional components so we can use hooks there. For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block.

@brentswisher Following up on old/stalled PRs – If I could get some new eyes on https://github.com/WordPress/gutenberg/pull/11070 specifically it would be great to wrap up, it’s been going about a year…Continuing to work on Storybook and file some related 

@gziolo and @getdave give props  to @itsjonq @mkaz @brentswisher and @enej for working on adding stories to Storybook too which makes testing a pleasure and helps us uncover all incompatibilities that folks can have when integrating components into their own project.

@retrofox Working now integrating https://github.com/WordPress/gutenberg/pull/18062 and https://github.com/WordPress/gutenberg/pull/18172 – apply colors correctly in editor mode

@jorgefilipecosta For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block. and improvements to the standard block UI can ultimately also improve the experience with Nav Menus

@mkaz Over the next week I hope to work with Joen to iterate on SVG loading. Hopefully one step for unsticking the Social Links.

@mcsf Relaying async updates from our APAC friends:

  • @tellthemachines: “I’ve been working on and reviewing nav menu issues. Current PR for showing appender only when item has submenu
  • @noisysocks: I’m focused on reviews this week: particularly Nav block PRs and this Widgets PR.

Open Floor

@marek asked if the screenshot on the Editor Component page needs updating https://make.wordpress.org/core/components/editor/ @mcsf proposed anyone with a more current screenshot to add it to a future Agenda post in the comments and anyone on the team with write-access to the component page can edit it

Specific Area Blocks

@aristath asked if the plan is to have blocks specific for these areas (like for example a branding block for the header block-area)? If so then these blocks will only be usable is the block areas for which we register them and won’t be available in the content? 

@jorgefilipecosta replied this could fit into the concept of child block where a block specifies it only makes sense inside a specific parent. It may be possible to use the current API’s and specify a branding block needs to be child of a header block, but that you may need to also use a branding block in the footer.

@mcsf I suggests this may work with block categories so that certain categories (“Page Layout Elements”?) aren’t meant to show up in post content.

@aristath from the theme team asks if there is code for review so the team can begin thinking about what needs to be done for themes (how they can override templates for registered blocks, what/how can be registered etc)

@poena I am seeing a lot of different screenshots in various github issues but is there actual example code for us to test?

@mcsf Are you asking more about block insertion and management UI, or about the front-end / template rendering aspects? There’s a few issues on different aspects

@aristath I’m asking about the template-rendering aspects, how they can be overridden (not all themes have the same branding components), if themes can register blocks for block-area A/B, if there’s anything we can start looking at. The UI doesn’t really matter, what we need at this point is to get an idea of what a theme can/should do code-wise to implement a feature. Even if it’s just a rough draft or an idea of where we’re headed .

@mcsf I think this a good starting point. A lot of issues and PRs, some of which merged, point to it, so be sure to scroll down to find some of the merged work around wp_template too. From the standpoint of overall user experience, this issue is a good aggregator.

@vindl Currently we already have a concept of child block. Where a block specifies it only makes sense inside a specific parent.  FSE-related (Full Site Editing) – would it make sense to extend this beyond blocks and make it possible to declare parent post type limitations (e.g. template-part block can only be inserted in wp_template CPT or similar)

@marek It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Not sure how much this was explored so far.

@williampatton It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Is the idea that the editor would be responsible for styling this?

@mcsf I personally see this is going beyond styling. Rather, we should have an editor (and blocks!) smart enough about block semantics that they a block can mean (and behave?) differently depending on where it’s inserted.

@marek I would think the editor provides classnames for areas and blocks and themes will handle those.

@williampatton I would prefer this aspect to be agnostic of the editor it. Ideally the editor doesn’t know/care where the items were and the frontend could handle all styling.

@poena This gives us an overview, how do we practically (and realistically) help move this forward?

@mcsf This gives us an overview, how do we practically (and realistically) help move this forward? Maybe some of those most involved in recent full-site editing efforts can weigh in? If not, this can be something to follow up via P2 comments — would that be acceptable, @poena?  I’d say that the November post would also be a strategic place to follow along and align.

@poena  I don’t know how you normally introduce new contributors

@mcsf that’s a great question. And, by the way, welcome and thanks for wanting to help! My personal impression is that full-site editing has been moving through different pieces that can be explored separately, which is good for velocity and collaboration, but also makes it much harder to jump in and get an immediate lay of the land. There doesn’t seem to be a single branch we can check out and start working on. it’s bits and pieces scattered all over the place. I’m sorry there was no super conclusive answer, @poena and @aristath but hopefully this is a starting point.

Thanks everyone for joining and for all the work!