WP Notify weekly meeting agenda for Monday 20 January 2020

This is the agenda for the next WP Notify feature project meeting, to be held on Monday, January 20, 2020, 14:00 UTC.

In order to start shaping the final requirements document, I’d like to start focusing on each section of the document, ensuring that it contains the correct information. The idea here is that we keep iterating on each section until we consider it complete, and then we’ll move onto the next.

So the focus of this meeting, and it’s recap post, will be on the section titled “Objectives”. The general agenda of the meeting will be as follows:

  • Opening and welcome
  • Reviewing and updating the requirements document: Objectives
  • Open floor

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

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

Dev Chat summary: January 15, 2020 (5.4 week 1)

The chat was facilitated by @francina on this agenda.

Full meeting transcript on Slack

Announcements / WordPress 5.4

At the moment there are 288 tickets milestoned for 5.4.

@francina is working on putting together a release squad. Some roles are already confirmed:

The whole team should be assembled by the end of the week. There is a fewer roles than in 5.3, because it’s a shorter release. The first Beta release is in 3 weeks from now.

@davidbaumwald expects to release the bug scrubs schedule by the end of the week.

@karmatosed added that Core design triages (on Mondays) for a few weeks can also focus on 5.4 to boost things.

@audrasjb noted that depending on the number of accessibility related tickets, the Accessibility Team can organize some extra accessibility focused bug scrubs. He will check the milestone to see if there is a need for more accessibility bug scrubs.

As @azaozz stated, hopefully component maintainers will take bigger and bigger part in “driving” 5.4, and releases in general.

@pbiron asked if there is a specific focus for 5.4. @francina answered that in general, 2020 is going to focus on one big goal: full site editing with Gutenberg. @dingo_d noted that it would need some coordination with the Theme Review Team.

@paragoninitiativeenterprises noted that #49200 needs feedback from anyone interested in WordPress security, or who develops plugins/themes.

@audrasjb is working on two tickets related to Themes and Plugins auto-updates: #49199 and #48850. This is one of the 9 projects for 2019-2020. The design team already provided some helpful feedback. These tickets are now waiting for technical review so they could hopefully land in the next couple of releases.

@marybaum noted her availability for copy review on 5.4 features.

@azaozz reported the Media team will release a feature plugin for lazy loading, so it can be tested well before adding to core. The plugin should be available in a couple of days.

@francina mentioned that development on 5.4 should have started the day 5.4 was branched, back in October. In fact, many people wait for the kickoff to start working. With Beta release scheduled in 3 weeks, it’s not really the time to add not fully ready features to the scope. However, WordPress 5.5 agenda is already known, so there is no need to rush things.

@azaozz and @francina pointed out that as soon as a release’s code is moved to a branch, trunk is back in business for the next release.

@xkon noticed that the “Current Release” widget on Make/Core might be confusing for newcomers as it’s still indicating 5.3 as the current release in progress.

Calls from component maintainers

Media: @azaozz is looking at couple of small enhancements for the uploader changes from 5.3, specifically adding a link in the UI to the original image (if it was scaled), and looking at some of the edge cases when creating image sub-sizes, file size for large PNGs, etc.

Widgets & Menus: @audrasjb will coordinate with @welcher to identify priorities for an eventual specific bug scrub.

Build tools: @johnbillion is going to look at getting several of the Composer related tickets into 5.4 (like using Composer for external libraries and phpunit). @desrosj and @johnbillion to synchronize their work at some point as @desrosj is working on backporting the local Docker environment.

Comments: @imath committed to look at each ticket involving comments in 5.4.

Open Floor

Some new contributors asked about how to start with core contribution. Worth noting the next New Contributor Meeting is scheduled for next Wednesday at 20:00 UTC in #core Slack channel. This is a great opportunity to ask for help or to learn how to contribute to WordPress Core.

@francina noted that @chanthaboune and @andreamiddleton are both nominated for CMX Awards. Everybody can vote for them on the dedicated website.

#5-4, #devchat, #summary

Dev Chat Agenda for January 15, 2020 (5.4 Week 1)

Here is the agenda for the weekly meeting happening later today: Wednesday, January 15, 2020, at 09:00 PM UTC.

Announcements

We are kicking off WordPress 5.4 this week!

Components Check-in

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-4-2, #agenda, #core, #devchat

WP Notify weekly meeting notification for Monday 13 January 2020

The WP Notify feature project continues in 2020, with our first meeting of the year to be held on Monday, January 13, 2020, 14:00 UTC. We will take this opportunity to review the current status of the project, determine where we are at, where we need to go, and how we need to get there.

As the project has been on hiatus since late 2019, there is no fixed agenda, but I’ve listed a few items below we will be discussing.

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 #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

Dev Chat summary: January 8, 2020

The chat was facilitated by @francina on this agenda.

Full meeting transcript on Slack

Upcoming Release – WordPress 5.4

@francina reminded the main feature of 2020 will be full site editing. All component maintainers received a ping before Christmas to put together a scope for WordPress 5.4. An open call for tickets was also published on Make/Core. While @francina noted there were mostly bugfixes and not so many new features, @audrasjb raised ticket #48850 from the comments of this post. This ticket is related to automatic updates for plugins (with manual opt-in), which is one of the 9 projects for 2019-2020.

@azaozz noted that the media component team plan to continue with image post-processing. It looks like it will need couple of small UI changes/enhancements.

@audrasjb added the accessibility team will probably focus on bugfixes on both Gutenberg and Core for 5.4, and target the next major (5.5) for bigger new features.

Highlighted posts

@francina noted that a lot of volunteers signed up to the release model working group. @francina will write a recap post on Make/Core.

Worth noting @azaozz published a 5.3 release cycle post-mortem.

Components check-in

Comments: @imath is working on #35214. Feedback welcome.

Core privacy: @xkon said the privacy team won’t have any specific focuses for 5.4, only bugfixing & enhancements on existing parts. Some of them need backward compatibility review, especially #44038 and #44176. Both tickets have a patch and are ready for further iterations if needed.

Media: @azaozz is experimenting with #44427. Seems a very worthwhile enhancement for 5.4.

Open floor

In the agenda comments, @justinahinon pointed out some editing needed in the roadmap, and highlighted reactions of the community concerning handling of big media on WP 5.3. @azaozz noted most comments are about “missing” the original image in some way. The initial plan was to have a link to it in the user interface. It should be added in 5.4. Another enhancement for the UI would/may be to show when an image is missing some of the sub-sizes and have a way to create them. There are plugins that handle this, but may be time to have it in core. There are couple of pre-existing edge-cases that need fixing too. Most notably increase of the file size for indexed PNGs when resized to smaller dimensions.

@timothyblynjacobs shared #47192 as a possible 5.4 feature. It’d bring a pretty often requested feature to Recovery Mode. It would need design and copy input as well as a security review from people familiar with the intricacies of the Users/Capabilities API.

#5-4, #devchat, #release-process, #summaries

Media Meeting Recap – January 9, 2020

Here’s a summary of the #core-media chat from January 9, 2020. Weekly media meetings happen on Thursdays at 14:00 UTC; see the full transcript here, in the Make WordPress Slack.

Attendees: @joemcgill, @karmatosed, @antpb

Upcoming Meeting Schedule

Happy 2020! Because of the holidays, the group postponed chats until Thursday, January 9.

This morning, the group also discussed moving the regular time, so more people can join the chat – particularly people working on critical tickets in the 5.4 release cycle.

Here are three options. Vote for your favorite in the comments:

  • Move the current Thursday 14:00 UTC time to 15:00 UTC
  • Move the date to Tuesday at 21:00 UTC (this option works well for the three who came to today’s meeting.)
  • Multiple meetings, to account for both sides of the world. This option would likely require a push of the currently scheduled meeting to 15:00 or 16:00 UTC as well as an agreed time and date for the second meeting. @joemcgill suggested that multiple meetings not be forced to cover the same agenda items. Some items will overlap where it makes sense, but, for example, if one meeting has cleared the ticket queue, it would be pointless for the next meeting to consist largely of a triage.

New Media ticket triage

#48194 – Unregistered image sizes used for IMG tag “srcset”

As @joemcgill pointed out: “The problem here seems to be that someone has deleted image files that are still referenced in the database in attachment metadata. Regenerating image sizes ( wp media regenerate ) would fix this problem, but should we only use registered sizes in `srcset` attributes if there are other sizes available?”

#48321 – Hotswapping featured image with gallery images

It seems the ask is for (after creating gallery) the option to click on one of the gallery items and set as featured image of the associated post. It was agreed by attendees that this may not be best fit in the gallery block UI and perhaps would be better fit as an option within the media modal when creating galleries, images, etc.

The group changed the ticket to ask for reporter feedback.

@karmatosed made another point. The “Uploaded to this post” filter, in the Set Featured Image modal, does give the reporter part of what they’re asking for.

#48325 – Additional filter in media-template.php. Let developers hide attachment page link.

@joemcgill pointed us to the code that creates the attachment link: https://github.com/WordPress/WordPress/blob/master/wp-includes/media-template.php#L511 and said, “At minimum, I think that template should check that data.link is actually a URL before displaying [it]. [Developers] could filter the data that is used by this template.”

WordPress 5.4 Media Focuses

While it didn’t come up in the meeting, notes are a great place for all of us to develop ideas for Media focuses in 5.4.

If you have any media-related focuses you’d like to work on in the 5.4 cycle, and that you’re ready to work on, please leave a comment.

That helps the Media maintainers gather and prioritize the work. Plus, it would be great if you’d come to next week’s chat so we can all discuss your idea!

#core, #core-accessibility, #core-media, #media, #summary

What’s next in Gutenberg? (January)

This is a monthly update containing the high-level items that Gutenberg contributors are focusing on for the next month. Join us in our efforts.

Block Content Areas

Work on this major focus is ongoing and is expected to continue iterating over the next months.

  • Work on a separate Edit Site UI
    • Load the front page template. 19081.
    • Switching templates. 19141.
  • Framework: Nest block lists from multiple entities (posts). 19203, 18739.
  • More Full Site Editing blocks (post author, post tags, site description…).
  • Expose global styles. 19255.
  • Experimental block-based theme.

Block UI

In a continuous effort to improve the accessibility and the usability of the Gutenberg design based on user feedback, an updated Block UI design is being explored. 18667.

  • Move the block movers to the block toolbar 18685.
  • Update the Block UI 19344.
  • Lighter Block DOM structure 19010.

Tightening up

Existing interactions and blocks will be iterated on:

  • Polishing the Navigation block and addressing early feedback Projects/31.
  • Expand the new Media Flow component to other blocks. 19198, 19174.
  • Block patterns for several blocks and inserter UI. 17335, 16283, 19243.

While these are our focuses don’t forget you can always help with triage, ‘needs testing’ and reviewing PRs

#core-editor

Editor chat summary: 08 January 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, January 8, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project.

Gutenberg 7.2.0

The first item of the agenda is Gutenberg 7.2.0! @ella is working on the final release. The release candidate was published on Monday and is available here. It is a bigger release than usual because of the pause we had for the holidays.

The final release will contain fixes for four regressions that we caught since Monday.

Weekly Priorities

The post with the priorities for the month will be published soon and we can discuss the bigger picture in more detail in the comments when it is ready. Based on conversations we had in the past and in the general direction of the project it looks like these are the main things we should focus on during the next week:

  • FSE work (namely: separate edit UI and implement/merge additional blocks),
  • Updates to the block UI, namely the lighter block dom and the new improvements to the UI,
  • Polishing the navigation block.

Task Coordination

@karmatosed working on:

  • Navigation block triage/feedback.
  • PR 19255 Global styles designs 
  • Triage, focusing on feedback and priority labels on design issues.

@andraganescu working on:

  • starting 8 Jan 2020 all media blocks (file, video, audio, image and media+text) have the new media replace control implemented — props to @soean
  • for the next week I’ll be working on refinements to the navigation menu and other media replace control open issues
  • I could use some eyes on these two very tiny PRs:
    • PR 19504 Adding always on display of media URL
    • PR 19461  When editing a navigation link, replace the current label with the title of page or post

@gziolo working on:

  • Patterns API integration with the Inserter

@koke working on

  • PR 18055 Close to shipping Page Templates/Block Patterns
  • PR 17335 I’d like to know more about the plans for that on the web and how we can consolidate the implementations better (or at least the parts that overlap) 

@mapk working on:

  • PR 19259 Creating template variations
  • PR 19499 Moving the Welcome Guide link 
  • PR 19400 Moving the Manage reusable blocks link

@itsjonq

  • Refocusing on Global Styles working with @karmatosed and perhaps others to get things working

@getdave working on:

  • Project 31 Focusing primarily on enhancements and fixes to the Nav Block.
  • PR 19387 UI (and accompanying REST API endpoint) to allow look-up of details about remote URLs (such as <title> tag) for display in hyperlink creation UI (LinkControl).

@retrofox working on:

  • Project 31 also on polishing the Navigation block too. As usual, we track the progress in the project board 

@bart working on: 

  • PR 18897 Navigation Block adds an empty link for untitled pages
  • PR 18321 Be consistent where we say edit or change
  • PR 18318 Navigation Block: Reduce toolbar options for menu item

@jorgefilipecosta

  • This week — a script to automate WordPress core package updates and committed the first automatically generated package upgrade patch. I reviewed some PR’s and worked on some bugfixes (two were cherry-picked into the release).
  • Next week — Automating package updates, namely by moving the script to core. I will explore dividing the way styles are loaded in core to unblock a challenge we have on the mechanisms to simulate media queries. 
  • Reviewing PR’s and working on my current PR’s/fixes.

@ella

  • Currently focussing on lightening the block DOM and performance.

Open Floor

Adding ColorControl component

@welcher is looking for review of PR 19288 Adds ColorControl component introducing a color picker without a pallet

@jorgefilipecosta pointed out the component “PanelColorSettings” is used in core blocks. At first sight it seems this component would allow everything the new component ColorControl allows with the primary concern being this solution includes a component that core itself does not use yet.

@chrisvanpatten pointed out the main difference is that ColorControl could really be described as “ColorPickerControl” for cases where we don’t want to offer colors from a specific palette

Introduce PluginManager class

@welcher asked for input on PR 19485 Introduce PluginManager class

This PR proposes disconnecting the plugin API function calls from direct access to the low-level datatype. This intermediary makes the API more semantic, allows for future changes/updates more easily and is meant to address @youknowriad ‘s concerns about the API not being fully semantic. This PR would be a precursor to changes to the API such as #16384. Also it introduces a new filter to allow the PluginManager class to be filtered allowing for ease of testing new API features and underlying data types. This last item is not the main purpose of this PR and is easily removed.

@welcher indicated this is a larger conversation to get started as the issue of the API not being semantic enough has blocked enhancements as seen in PR 16384. @jorgefilipecosta suggested allowing time for people to review the PR asynchronously and adding discussion to a future agenda.

Cover Block Background Image Size Selector

@paaljoachim asked for design feedback on PR 19223 “Cover Block: Add Background Image Size Selector”. @karmatosed suggested and added labels so it doesn’t get passed over for review

@jorgefilipecosta noted:

  • The first issue is UI and is labeled for feedback, so it should soon be discussed/reviewed.
  • The second issue is technical the images are loaded as css property `background`. Due to limitations of CSS not having an equivalent to srcset( possible work around https://drafts.csswg.org/css-images-4/#image-set-notation), the browser will always download the same image size regardless of device.

A possible fix is to use an image element but use CSS to mimic look of background as done for video backgrounds. Post comments on this solution option in Github.

@jeffreycarandang made a similar suggestion as @jorgefilipecosta  using absolute positioning <img /> instead of background-image for Cover Block which would allow responsive image sizes, noting the biggest issue to solve is the Focal Point Picker. 

Image Handling

This is a related issue to the Cover Block Background Image Selector

@azaozz Issue 6177 offers a “mini-proposal” on how to handle images in the editor and the front-end (follow-up from #4914).

Latest Post Block

@FahimMurshed Issue 13584 “Latest Posts” blocks need “pagination”/”Load more” feature.

Looking for design feedback or propose a potential design for the block.

Triage PRs

@mkaz requested self-triage because the issue count is almost 2,000 with 400+ open PRs. If you have opened an issue or PR, please confirm they are still valid. You can see your list by filtering by Author. @Jorgefilipecosta agreed and pointed out a good way to contribute is by reviewing with the added bonus that you also learn with what other people have done.

Javascript Chat Summary: Tuesday, December 17, 2019

Below is a of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on the next chat agenda.

Next Javascript meeting is January 7th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings.

Prettier

@aduth introduce the topic by saying:

There’s been quite a bit happening this past week, both in the comments of the revisions proposal post, and in the original pull request.

Post: https://make.wordpress.org/core/2019/12/09/proposed-javascript-coding-standards-revisions-for-prettier-compatibility/

Pull request: https://github.com/WordPress/gutenberg/pull/18048 

I think we’re in a position to make a decision on how to proceed here. From the feedback to the post, there are some general thoughts around improvements to the standard, but not any reluctance to Prettier specifically (quite the opposite, in fact!)

It would seem to me that most people are on board with this. Does anyone have any last-minute thoughts on this, or would it be fair to say we can move forward with adopting Prettier?

Based on the comments of the PR and the conversation in the chat, it seems we are in a position to merge this work.

@jsnajdr referred that the PR adds a format-js script to wp-scripts, and provides support for IDE integrations. Well-behaving Prettier editor integrations should pick up the config and the fork binary automatically.

@mkaz proposed a PR that documents these changes at https://github.com/WordPress/gutenberg/pull/19074.

The conversation went on @jsnajdr noted that the PR does not yet format the code, but we can easily format it with `wp-scripts format-js`.

@gziolo showed availability to collaborate/discuss with @jsnajdr how format-js will operate after the PR is merged.

@gziolo noted that having prettier code formatting will alow inline snapshots on the test cases https://jestjs.io/docs/en/snapshot-testing#inline-snapshots.

@aduth proposed the following action items:

  1. Merge @jsnajdr‘s pull request.
  2. Review, merge @mkaz developer tools documentation.
  3. Submit standards revisions changes.

After @jsnajdr‘s pull request is merged:

  1. Create a pull request to apply formatting to the entire codebase
  2. Explore options for automated formatting.

Participants agreed on the plan.

Block Scaffolding

@gziolo shared the following GIF showing block Scaffolding working:

Block Scaffolding Tool

@gziolo managed to implement ESNext template support with wp-scripts integration and is wondering if this scaffolding mechanism should be part of the Gutenberg repository.

Participants started discussing if this solution is part of the Gutenberg repository, what will happen to the current “official” scaffolding solution offered in WP-CLI. There are technical restrictions in making something equivalent to the solution @gziolo proposed on WP-CLI because WP-CLI should not depend on node.

@gziolo will continue iterating on the new scaffolding solution and, once tested, will import it into Gutenberg.

SVGR support in wp-scripts

@mkaz started the topic by saying:

I have a PR that adds SVG support to it which is a handy addition, but not sure if we want to add it without having the same support in core Gutenberg: https://github.com/WordPress/gutenberg/pull/18243 

For core blocks, we don’t inline SVG, we always code them, so this mechanism would not be used by core blocks, but it may be helpful for third party block developers.

@gziolo said Parcel 2 is heading in the direction of supporting CSS and SVG imports. @aduth said Parcel faces a similar challenge, and it may be a useful reference of how to address this problem.

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

Editor chat summary: Wednesday, 18 December 2019

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, December 18, 2019, 14:00 UTC.

The agenda of the meeting is here.

Next core editor meeting is January 8th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings and plan the next Gutenberg release (and #core-editor meeting) for January 8th, 2020.

Considering our consistent bi-weekly release schedule, there were 23 Gutenberg versions released in 2019.

Thanks to everyone who made this possible!

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.

@andraganescu

  • I migrated the MediaReplaceFlow to the video, audio, file and media+text blocks and the PRs are waiting for a review. They’re all pretty small code wise: 19198, 19174, 19162, 19158.

@karmatosed

  • Triage continues and trying to ensure everything has a design review on PRs within short time.
  • Wrote v1 of triage team doc and it’s up on issue.
  • Spending sometime this week clearing down queues a bit and already finding I can close some, so nice to close!
  • Began working on navigation in wp-admin: working out boundaries for this.
  • Did some mobile web testing and logged some issues, continuing this.
  • Sentence case merged.
  • Quick fix for welcome guide.
  • Lots of design feedback and testing.

@noisysocks

  • No new development happening from me this week but I do have this open PR for deprecating wordpress/nux that I’d love some eyes on: 18981

@youknowriad

  • I’ve been working on a few PRs to improve API and consistency for the Button component
  • I’ve been working on a keyboard shortcuts package to ultimately allow editing shortcuts and registering third party ones
  • A few janitorial PRs

@aduth

  • Been doing some fixups: – Fix ArrowUp/parent block selection: 19135
  • Fix IE11 Welcome Modal: 19201
  • Would still like to land removal of “shortcuts” (needs review): 19045
  • Starting to explore user preferences persistence (more “sticky” than browser storage): 19177

Hoping to hit on a few things in next days:

  • Better data reuse for REST API _fields (opens up new optimization possibilities)
  • docgen improvements (edited) 

@mapk

  • Linking Media in Media + Text block is merged! 18139
  • Was hoping for some dev help on new Block Library categories: 11406
  • If the widgets screen is ready for testing, @jorgefilipecosta, I’d like to do some usability tests.
  • Usability testing the Nav block.

@ella

  • Been working on Raw handling, RichText, and slowly making progress with the toolbar in popover PR.

@epiqueras

  • Been working on edit-site and new entity APIs. Also template part editing flows.

@richtabor

  • I have one small tweak left for adding background color support to the columns block. Refactored it to use the ‘useColors’ hook. Next I’ll do the same for the Column block on a separate PR 17813

@isabel_brison

  • I’ve been working on making the editing canvas resizable, PR in progress here: 1908
  • Branching off from that, I’m starting to look at how we might optimise default block styles with CSS variables without breaking things completely in IE.

Open Floor

There was a lot of discussion on improved revision control. The main point raised by @Carike was that by using branched revisions, with minor and major designations, users will be able to use block based themes more easily. @epiqueras offered that branching or minor/major revisions are too complicated and a better improvement to revisions si to have them support block level changes.

The general agreement was that we need better revisions performance and UX.

The discussion continues in Track ticket #48953.

A second discussion happened about adding pagination to the latest posts block. There was a heated debate on whether pagination is a stand-alone block or simply a feature of blocks that need pagination. @karmatosed argued that pagination is not an option that an user might think as requireing inserting a block. @epiqueras argued pagination should be a block and be developed in such a way that if it is used standalone it would default to paginating the default post loop in the page, while other blocks might opt to use it by default (e.g. the latest posts block).

The issue is still up for debate, UX and technical solution in the GH issue #13584.

On a final note, happy holidays for those who do that and happy new year!

#meeting-notes, #core-editor, #editor, #gutenberg