Mervin Hernandez 7:04 am on February 27, 2020
Tags: , ,   

WP Notify Meeting Recap – February 24 2020

This is a recap of the WP Notify meeting held on Monday, February 24, 2020, 14:00 UTC. You can read the full meeting discussion here in Slack.

We focused on the next sections of the requirements document, Section 3 “Current Status”, and Section 4 “Project Goals”.

Section 3. Current Status

  • Finalized description of existing API features and limitations

Section 4. Project Goals

  • We continue refining the definitions of our MVP (minimum viable product) a.k.a. Version 1.0
  • We outlined important research the project should include
  • We noted importance of retaining backwards compatibility of notifications handling

At the close of the meeting, @hrmervin posed the question of how/if Gutenberg methods of notification handling can influence this project, either in short term or long term. 

Next Slack Meeting

Join us next week, where we’ll continue the discussion on the project goals, and system feature requirements. 

📅 Monday, March 2 @ 14:00 UTC

#admin, #feature-notifications, #notifications

Valentin Bora 12:44 am on February 27, 2020
Tags: , 5.4 release cycle, component-maintainers, , , meetings   

Devchat summary: February 26, 2020

@francina facilitated the chat on this agenda.

@valentinbora took care of publishing the meeting summary with special thanks to @amykamala, @audrasjb, @Cenay and @marybaum.

Full Meeting transcript on Slack

This devchat marked week 7 of the 5.4 release cycle.

Announcements

Upcoming Releases

Release Candidate 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)

WordPress Release Cycle

For background, please read:

@johnbillion got to the heart of the matter: should beta be for fixing bugs that predate the ones introduced during alpha?

@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.

@johnbillion liked the idea that beta is for every bug, as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.

@jeffpaul pointed out that avoiding committing non-regression bugs during beta means Beta and RC wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.

@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the Core team is happy to release.

@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).

@joemcgill @johnbillion @azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunk, and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.

per @johnbillion, @matt has, in the past, preferred to keep focus on the current release. 

@joemcgill stressed that the core team needs more clarity on what types of fixes are appropriate to commit to the 5.4 release, pointing out that the discussion in chat echoes this proposal to review historical practices to improve the project and potentially speed up release cycles.

@francina referred the group to the Release Model Working Group Chat Summary: February 19th, 2020 for the latest on that proposal.

@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

@francina proposed a change to the Components Check-in. 

Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:

  1. Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
  2. Adopt a Slackbot that, once a week, asks maintainers for a status update. 

@francina also proposed that those updates — and other communications — live in a new #component-maintainers Slack channel. Core is getting very busy with automated updates like Trac and Travis bots, plus RSS.

@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflict].

@francina and @valentinbora agreed that going async [communicating asynchronously] could help.

@cenay was in favor of the Slackbot option.

Action items

  • @francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
  • @audrasjb to get all dev notes by the end of the week and publish the Field Guide before RC1.

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, March 4, 2020, 21:00 UTC.

#5-4, #5-4-release-cycle, #component-maintainers, #core, #devchat, #meetings

Jorge Costa 10:21 pm on February 26, 2020
Tags: , ,   

What’s new in Gutenberg? (26 February)

Gutenberg 7.6 brings considerable progress on the full-site editing (FSE) front, including four new FSE blocks:

  • Post Featured Image
  • Post Tags
  • Comments Count
  • Comments Form

In addition, this release includes many enhancements and fixes to existing blocks and features.

Any help testing FSE work is much appreciated. So, if possible, please enable FSE in your testing environments and share your feedback.

Gutenberg 7.6 also brings a rotating list of tips that appear in the Block Inserter to provide useful information to users:

The release also comes with developer-focused enhancements to wp-env and wp-scripts, thus improving the experience of building with WordPress.

Last but not least, this release cycle has prioritized bug fixing, and as a result this release brings numerous fixes that were also included in Betas 2 and 3 of WordPress 5.4.

Read on for the full change log.

7.6 🇱🇹

Features

  • Add a rotating list of tips to the inserter help panel 20163

Experimental

  • New blocks:
    • Post Featured Image. 19875
    • Comments Count block. 19953
    • Comments Form block. 19954
    • Post Tags block. 19580
  • Add new features to the Post Excerpt block. 19715
  • Allow changing Site Title block heading level. 20361
  • Render the post comments form properly 20279
  • Add new features to the Post Date block. 19857
  • Add multiple template loading 19141
  • Show error when resolved block template is empty 20239

Enhancements

  • Improve find-ability for social/video embeds 20224

New APIs

  • Ensure packages-update wp-scripts command works with missing dependencies 20408
  • Add new option in dependencies webpack plugin to combine assets files into one file 20330
  • Environment:
    • Add custom port numbers to .wp-env.json 20158
    • Add support for local override files. 20341
    • Add debug mode. 20348

Bug Fixes

  • Overflowing LinkControl block editor component. 20154
  • Broken gallery to image transform and inconsistent types used in the gallery block 20084
  • Missing label on heading toolbar. 20248
  • Sidebar jumpiness. 20355
  • Fix wrong imports in PluginBlockSettingsMenuItem 20356
  • Color formatter appears when color choosing is not possible 20222
  • Crash when updating a post with the latest post block 20289
  • Inconsistency on Import from JSON button look 20416
  • Inline image width pop-up ‘wanders’ down page 20232
  • Styling problem on vertically aligned blocks 20368
  • Remove unnecessary aria-label from link formatter 18742
  • Make navigation button expand to fit longer nav link text 20230
  • Flow for gallery creation and editing 20287
  • Fix background color for dark themes on the spacer block 20296
  • Show metaboxes peeking in even on tiny screens. 20262
  • Add an edit state to media frames to fix an issue when opening a new tab. 17642

Documentation

Various

  • Create block: Add support for format:js to ESNext template 20335
  • Add check for minimum system requirements on create block 20398
  • Conditionally apply Editor Skeleton html element styles 20245
  • Environment:
    • Check for legacy installs and provide the option to delete them. 20340
    • Fix testsPath on local sources 20353
    • Use user with UID=33 to run WP CLI commands 20403
    • Fix issue where docker & wp had different URLs 20228
    • No longer show error message twice 20157
    • Support wp-config.php overrides. 20352
    • Support overwriting generated file directory with an environment variable 20253

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 7.6.0 7.7s 48.59ms
Gutenberg 7.5.0 8.5s 55.45ms
WordPress 5.3 7.9s 77.23ms

#core-editor, #editor, #gutenberg

Ajit Bohra 5:00 pm on February 26, 2020
Tags: , , ,   

Editor chat summary: Wednesday, 26 February 2020

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

WordPress 5.4 Upcoming Release

Gutenberg 7.6.0

  • RC will be released on Monday.
  • The changelog can be checked on https://github.com/WordPress/gutenberg/releases/tag/v7.6.0-rc.1.
  • The FSE work evolved a lot, and Gutenberg 7.6 includes four new FSE blocks, besides many enhancements and fixes to the existing blocks and functionality.
  • Any help testing FSE work is much appreciated, enable FSE on your test/in development projects and share your feedback.
  • Enhancement to wp/env and wp-scripts to make the developer experience better.

Weekly Priorities

  • The first iteration of G2 (Block UI redesign) has been merged into master and will make it into Gutenberg 7.7.

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.

@nosolosw

@youknowriad

  • Working on G2.
  • Starting a new project with @nrqsnchz about Block Patterns.
  • Help with G2 follow-ups.
  • Triaging old issues.

@joen

@mcsf

  • Followed up on items related to Social Icons.
  • Discussed block variations and patterns with @gzioloo.
  • Pitched in around dev notes for 5.4, and some reviews.
  • Exploring how to implement embeds as block variations.

@ellatrix

  • Continuing work on lightening the block DOM and allowing blocks to render the entire block and inner block wrappers, hopefully making it easier to style block for block and theme authors. 

@brentswisher

@gziolo

  • Paired with @azaozz to improve the build process for the editor’s JavaScript scripts in WordPress core.
  • A few bug fixes/enhancements for @wordpress/scripts and @wordpress/create-block packages.
  • Several reviews including SlotFill refactor.
  • Plan to work on the block features API proposed by @youknowriad.

@getdave

@itsjusteileen

  • Working on FSE and block templates from a user and theme creator perspective.

@andraganescu

Open Floor

Capitalization in strings used in the editor

Encouraging component maintainers to get involved with the non-editor parts of Gutenberg

  • @noisysocks some discussion around how to encourage Widget component maintainers to get involved with the experimental Block Widgets functionality. There’s a lot of expertise there that the Core Editor team could use.
  • @youknowriad suggested inviting component maintainers to the core editor channel.

Query Blocks

  • @andraganescu some discussion around reusability of query block https://github.com/WordPress/gutenberg/pull/20106
  • @revgeorge It’s working, but I’m working with @epiqueras to figure out how to best structure it’s de-duplication feature, or possibly going ahead without de-duplication at launch. It’s behind the FSE flag in the branch because it needs the post blocks to display results
  • @itsjusteileen from a plugin perspective, I’d love to see it with de-dupe
  • @revgeorge I can show you how I plan to use it with a plugin use case. The current plan for deduplication is to provide a container block that uses hooks to provide a way for blocks to get a list of displayed posts and add to that list, the container would be aware of the order the blocks are in and what they’ve displayed.
  • @gziolo what’s the difference between Query block and Latest Posts block?
  • @youknowriad Query block doesn’t have a fixed output based on attributes, it uses InnerBlocks to render each “post”. So you could combine PostTitle, post content, PostExcerpt, Post* blocks as a template for each “Post” entry in the Query block.

Semantic HTML inside the Group block

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

Amy Kamala 6:27 am on February 26, 2020
Tags: , ,   

Release Model Working Group Chat Summary: February 19th, 2020

This is the Summary of the Release Model Working Group Chat in #core on Slack at 20:00 UTC!

Folks are welcome to check out the agenda and Slack archive for this week’s meeting. Here is a recap of the last meeting, as well.

Thank you to @mikeschroder for doing the peer review on this summary!

This week a kan ban project board was introduced with new GitHub issues created!

@noisysocks broke down some of the ‘development’ phase of the pre-release cycle into individual issues for each critical step. 

A few of the issues have been assigned to contributors and more volunteers are welcome! Workflow is being broken down amongst team members as follows:

@noisysocks mentioned that some conversations have already lead to ideas for recommendations!

Next Meeting

Meetings for the Working Group will take place on the first and third Wednesday of the month at Wednesday March 4, 2020 at 08:00 UTC and Wednesday March 4, 2020 at 20:00 UTC. Hope to see you there!

#meeting-notes, #release-process

Andrew Duthie 9:48 pm on February 25, 2020
Tags: ,   

JavaScript Chat Summary: February 25, 2020

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.

Unit testing revisited

(Slack conversation)

The current tooling used for component testing in Gutenberg was observed to not support support React portals. An implementation of a new testing utility module was originally proposed, then later resubmitted as an incremental approach to adopt React Testing Library.

Discussion:

  • Is this about limitations of the tooling for fundamental React features, or about our approach to testing? It appears to be a little of both.
  • The conversation evolved into a discussion of how we want to test components, essentially distilled to a distinction between white-box and black-box testing.
  • There was some unclarity around what impact React Testing Library would have on our existing tools. @hazdiego joined the conversation, pointed to an earlier GitHub comment contrasting the solutions, and clarified that while it has feature parity to support replacing existing tools, it also comes opinionated with integration-style testing.

Action items:

Open Floor

WordPress 5.4 Deadlines

(Slack conversation)

@adamsilverstein made note that the WordPress 5.4 release is quickly approaching and that any work not addressed soon would need to be punted to a future release.

@aduth mentioned that a polyfill fix for URL will be needed, and that he would appreciate attention on the corresponding patch at #49360.

Webpack Build

(Slack conversation)

@gziolo mentioned that changes to the Webpack build were introduced with #48154, where one asset file is created containing all JavaScript entry points. This generated file is used to iterate and register all core scripts output from the Webpack build.

@gziolo mentioned a desire to improve upon this with better handling between development and production environments. He gave an example of the wp-warning package, which should be considered unnecessary for production, since it is a noop in that environment. Due to time constraints, this is planned to be discussed further in next week’s meeting.

#core-js, #javascript

Lara Schenck 8:12 pm on February 25, 2020
Tags: ,   

CSS Chat Agenda: 27th February…

CSS Chat Agenda: 27th February 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, February 27, 2020, 4:00 PM EST.

This meeting will be held in the #core-css channel  in the Making WordPress Slack.

Agenda:

  • Idea for a CSS audit
  • Open Floor

The agenda is light this week, so if there’s anything else you would like to discuss, feel free to add additional topics in the comments!

#agenda, #core-css

Pascal Birchler 1:45 pm on February 24, 2020
Tags: , , , ,   

XML Sitemaps Meeting: February 25th, 2020

Last week we held the first of many weekly meetings for the XML Sitemaps feature project on Slack.

XML Sitemaps Kickoff Meeting Announcement

Meeting Recap: February 18th

We had quite a few people attending, not all of whom were familiar with the project. Thus, we started off with a small recap of the project’s scope and goals. After that we discussed various different topics:

  • How to modify the sitemaps to include/exclude certain URLS
    A pull request has been opened to add a FAQ section to the readme that aims to answer these kind of questions.
    Also, a new way to filter WP_Query instances used for sitemaps has been proposed.
  • Why are there no changefreq and priority fields?
    Those are optional fields in the sitemaps protocol and not typically consumed by search engines. The feature plugin follows other solutions like Yoast SEO who also don’t include those fields.
    Developers can still add those fields if they really want too.
  • Will there be UI controls to include/exclude content from sitemaps?
    Adding UI controls is currently a non-goal for the project.
  • Calculating the last modified date for URLs
    This is rather difficult and computationally expensive in WordPress. Given that sitemaps are first and foremost a discovery mechanism for content, having this data is not necessarily required. We will explore omitting this functionality (GitHub issue).
  • The default limit of 2000 URLs per sitemap is considered high and might need to be re-evaluated.
  • Potential compatibility issues with other XML Sitemaps plugins have been discussed.
    If a site ends up having two sitemaps by accident that wouldn’t be bad. However, the current /sitemap.xml URL might clash with other plugins. A GitHub issue has been opened to suggesting using /wp-sitemap.xml as the base. This would avoid conflicts in this regard.

Agenda: February 25th

The next meeting will be held on Tuesday, February 25 at 16.00 CET

For tomorrow’s meeting, the agenda is rather brief:

  • Updates since last week (merged changes, new issues)
  • Next steps for proposed lastmod changes
  • Next steps for URL naming change
  • Planning release of version 0.2.0

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

#agenda, #feature-plugins, #feature-projects, #seo, #xml-sitemaps

Jonathan Bossenger 9:12 am on February 24, 2020
Tags: ,   

WP Notify weekly meeting agenda for Monday 24 February 2020

This is the agenda for the next WP Notify feature project meeting, to be held today, Monday, February 24, 2020, 14:00 UTC.

Agenda

  • Opening and welcome
  • Reviewing and updating the requirements document: Current Status
  • Reviewing and updating the requirements document: Project Goal
  • 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

tellthemachines 12:34 am on February 21, 2020
Tags: ,   

CSS Chat Summary: 20th February 2020

Full meeting transcript on Slack.

I (@isabel_brison) facilitated the meeting. 

The agenda was empty except for Open Floor.

I proposed a question to reflect on for this and future meetings: “What, if anything, should we improve about our CSS in core and/or gutenberg? And what, if anything, are we already doing particularly well? “ (If anyone reading this would like to contribute an answer, feel free to pop into the next meeting, or just add a note to the agenda if you can’t make it to the actual meeting!)

@bemdesign expressed concern that the adoption of modern development approaches, especially CSS-in-JS, and the build tooling necessary for React apps, might over-complicate the process for new developers to get started.

We discussed how to ease the learning curve and make it easier for new developers to get involved: 

  • Choosing tools with an easier syntax (in the CSS-in-JS case)
  • Education and documentation
  • Out-of-the-box build configs, such as @wordpress/scripts

Then, going back to the initial question, @peterwilsoncc suggested overly high specificity of some CSS selectors could be improved, and ideally we should have a consistent level of specificity throughout.

@youknowriad added that we should try to create style variations in components instead of trying to override default component styles with additional classnames.

@laras126 suggested using single-declaration utility classes that sit further down the cascade, and passing in classnames as props.

We agreed backward compatibility may make it hard to change our current approach completely.

Open Floor

@laras126 shared a link to a CSS working group discussion on the benefits of introducing a new CSS version.

We briefly discussed how a new version (CSS4) might be useful to us: adding visibility to current best practice approaches and as an encouragement to developers to learn the spec better.

That was all!

#core-css, #summary