David Baumwald 6:32 pm on January 20, 2020
Tags: ,   

Bug Scrub Schedule for 5.4

Now that 5.4 has been officially kicked off, bug scrubs will happen weekly all the way up to the final release. Keep an eye on this schedule – it will change often to reflect the latest information.

  1. 1/21/2020 19:00 UTC
  2. 1/29/2020 23:00 UTC
  3. 2/7/2020 05:00 UTC (APAC-Friendly)
  4. 2/10/2020 16:00 UTC
  5. 2/18/2020 20:00 UTC
  6. 2/27/2020 23:00 UTC
  7. 3/2/2020 16:00 UTC
  8. 3/11/2020 TBD (If Necessary)
  9. 3/17/2020 TBD (If Necessary)
  10. 3/27/2020 TBD (If Necessary)
  11. 3/30/2020 TBD (If Necessary)

These scrubs are separate and in addition to the normal scrubbing and triage by individual components. Some of those sessions include:

Design Triage: Every Monday 17:30 UTC at #design
Gutenberg Design Triage: Every Tuesday 17:00 UTC at #design
Accessibility Scrub: Every Friday 14:00 UTC at #accessibility

Also, the ongoing APAC-friendly #core bug scrub session every Thursday at 06:00 UTC will continue during the cycle, alternating focus between core and editor.

Next, the Accessibility team has announced a few extra scrubs for the 5.4 cycle. You can read about those here.

Finally, a reminder that anyone — Yes, you! — can host a bug scrub at anytime. You can work through any tickets you’re comfortable with. In fact, if you plan one that’s 5.4-focused, we’ll add it to the schedule here along with your name. Finally, you’ll get well deserved props in the weekly Dev Chat, as well as in the #props Slack channel!

All open tickets for 5.4, in order of priority, can be found here. Tickets that haven’t seen any love in a while are in particular need. Those can be found in this query.

If you’d like to lead a bug scrub or have any questions or concerns about the schedule, please leave a comment or reach out to me directly.

#5-4, #bug-scrub

Jonathan Desrosiers 6:22 pm on February 21, 2020  

Working on Trac Tickets Using GitHub Pull Requests

WordPress development uses SVN, but many contributors prefer to work in Git though GitHub. For some contributors, that means working with a cumbersome workflow within Trac. Many contributors create pull requests using their own forks of the official WordPress Develop mirror so that they can use features like continuous integration and inline code commenting. Historically, though, it has been hard to cross-reference between the two systems.

Starting today, an experimental feature has been added to Trac that will let you link GitHub pull requests opened against the official WordPress Develop Git mirror to tickets. This makes GitHub contributions more visible directly in their related Trac tickets and makes collaborating across the two repositories easier. (Better contributor experiences, ftw!)

Note: this is not a signal of any decision to start moving WordPress to Git, GitHub, or GitLab. That is something that is still being explored separately and independent of this feature. There is no further update on that at this time.

How It Works

In GitHub

In Trac

  • The PR will be displayed below the attachments area on tickets with the following information:
    • How many lines were modified
    • Status of the PR checks (Draft/Closed, Travis CI, merge conflicts, etc.)
    • A button to view the PR
    • A button to view the raw diff
  • A bot comment will be added to the ticket’s timeline of events indicating when the ticket was mentioned and where.
  • Every time the PR receives a comment, a PR bot will post the comment onto the Trac ticket.
A screenshot of a WordPress Core Trac ticket with the new linked Pull Requests between the ticket attachments and comments.
Pull requests show between Attachments and Change History.

Important Notes

Trac remains the source of truth for all discussion. If you prefer to continue working in Trac, that’s OK! Nothing will change on Trac itself other than what is noted above. Nothing about how you contribute has to change!

When the PR bot syncs comments over to Trac, it will not trigger an email notification to the subscribers of the Trac ticket. For this reason, it is recommended to provide some type of ticket update in Trac itself. Most likely there will be a need to update the keywords anyway (add has-patch or needs-testing, etc.).

Inline comments made during a code review on the PR will not be posted to the Trac ticket. These comments are contextual to specific lines at a specific state (commit) of a PR, so this should be OK. If this causes confusion, syncing these can be explored.

No changes to WordPress Core will be merged through GitHub pull requests. This is not new and remains the same. This feature is meant to make contributions done through PRs on GitHub more transparent in Trac.

Pull requests on GitHub are not monitored. No one will be checking for new pull requests regularly. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core.

Clean up after yourself occasionally. Right now, PRs are not automatically closed when the associated Trac ticket is resolved. If you open a PR, do your best to close PRs that have been merged into Core whenever you are able to.

And finally, this is an experiment. There will likely be some small bugs and things that can be improved since this is the first iteration. Please open up tickets in Meta Trac for any issues that you find. All feedback is welcome! Please leave your thoughts in the comments of this post below.

Props go out to @noisysocks, @pento, @desrosj, @andraganescu, @isabel_brison, and @talldanwp for working on the initial iteration of this feature, @dd32 for heavily overhauling for and deploying to production, and @chanthaboune for helping to proof read this post.

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

Robert Anderson 12:20 am on February 21, 2020  

Components Maintainers and Gutenberg

In this week’s DevChat, @jeffpaul asked:

One thing I’ve become curious about is how some components should potentially be looking to support current/future phases of Gutenberg? Thinking here about Customizer, Widgets, Menus, and the like. Is there anyone on the Gutenberg team that’s working with those components to see how those maintainers/contributor teams could help advance Gutenberg development from their unique perspective from a core component team?

Some discussion ensued, but it’s an important topic that’s worth discussing in an asynchronous forum where people from all timezones can participate.

So: How do we ensure that there is good collaboration between Component Maintainers and the Gutenberg project?

Jonathan Bossenger 7:25 am on February 20, 2020
Tags: , ,   

WP Notify Meeting Recap – February 03 2020

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

We opened by reviewing the Use Cases section. We moved an item related to which users plugin or theme notifications should be shown to, down to a later section in the document (Wish List Items), to be discussed at the relevant time.

@folletto noted that “here we are a bit playing a double role, use cases for users and use cases for developers. These luckily overlap a bit, and I think what we have is a good compromise”. @psykro left a comment that we might need to expand on use cases. We also had a brief discussion about the section on state changes. While the ultimate goal would be for WP Notify to replace those as well, this might not happen in our first release.

We reviewed the current status of the new Current Status section and had a discussion on the terminology related to the different types of notifications. @folletto suggested the following:

  • Notification = a notification hub, with maybe a dropdown or a container of some sort, that shows alerts across pages
  • On Page = a local notification, shown only on a specific page, and contextual to the page content

Finally we removed the admin_notices graphic from the Current Status section.

As always, we invite the community to share their feedback on any of these changes to the document, either here in the comments or on the document itself.

Next Slack Meeting

📅 Monday, February 24 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

Paul Barthmaier (pbrocks) 2:35 am on February 20, 2020  

Editor chat summary: 19 February 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, February 19, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. The meeting was moderated by @gziolo.

WP 5.4 Beta 2 Released

The release contained several fixes for the editor. A few notable items:

  • Block editor: Columns in the Block Library that have unassigned-width will now grow equally.
  • Block editor: The custom gradient picker now works in languages other than English.
  • Block editor: When choosing colors is not possible, the color formatter no longer shows.

Everything can be viewed here. We still have some ongoing work in the must have board. Props to all involved in the process, with the big shootout to @jorgefilipecosta for wrangling all the boring work of syncing all those fixes in WordPress core. Friendly reminder for those who are aware and explanation to everyone else about the workflow during WordPress release cycle. Next release will be the last beta version. That means the first RC and the string freeze is very close. Until WordPress 5.4 is out, we do the regular release for the plugin every 2 weeks. At the same time, we only backport essential bug fixes to WordPress core. It means that we don’t do regular publishes to npm for WordPress packages.

The dev notes work is going well and post notes are already written. Thank you to all the helped this effort and wrote dev notes

Weekly Priorities

The February plan is still in motion: 

  • Expect Gutenberg G2 to land in the next weeks
  • Global styles being a focus
  • FSE ongoing project that will continue for a few weeks/months

Get involved in FSE work (blocks being added, themes being explored). There’s room for a lot of work there and not enough people at the moment. There is work being shared around the UX flows for template-parts, and navigation. Providing feedback there can help move things.

Task Coordination

@karmatosed deep down in global styles-land we have new mocks. I’ve also been giving feedback where can on some tickets, keeping that triage flowing.

@youknowriad

  • Still working on my ongoing wordpress/icons project
  • Added a bot that shows the impact of PRs on bundle size (I hope it’s not annoying you and that we’ll actually pay attention to the changes)
  • Working on the last G2 details before initial merge (hopefully this week or beginning of the next one)
  • A lot of reviews (SlotFill, FSE blocks…)
  • Some block-based themes explorations.

Nothing blocking so far

@itsjonq

  • Continue with Global Styles. Hands on with FSE integration alongside @nosolosw. Otherwise, planning/coordinating
  • Helping folks like @youknowriad on G2 (Movers interaction specifically)

@nosolosw

  • Iterated on a proposal for the resolver that enables authors to target specifics parts the post (“all block paragraphs”, “cite within blockquotes”, etc): PR 20290
  • Bootstrapped a barebones global styles theme for demo purposes PR 22
  • Prepared a PR to explore a different isolation mechanism and how the process of migrating blocks to use CSS variables may look like PR 20273 
  • For next week, I’m going to carry on that work and potentially resume the PR to connect the server data to the UI Controls PR by @itsjonq.

@getdave

  • Merged a PR to enable the creation of Pages from within the Navigation Block.
  • Seeking reviews on another PR to improve the documentation around the `<LinkControl>` component:

@mapk 

  • Working through Block Patterns with . He’s going to explore a simpler MVP approach to get patterns in quicker.
  • Exploring UX around template parts.

@brentswisher 

  • Getting caught up to start contributing again after being away for a few months while moving into a new house. You all move so fast! The last thing I had been working on was going through all the components to add them to Storybook.
  • Doesn’t look like there has been a ton of movement there, thoughts if that would still be worth my time, or should I look for somewhere else to start contributing (FSE?)

@gziolo 

  • Working on documentation, dev notes, e2e tests for block variations API.
  • Introduced stable BlockSettingsMenuControls slot
  • Planning to help land changes for SlotFill refactor, want to finish Puppeteer upgrade, also want to work on optimizations for block editor build process in core.

Open Floor

Conflicts in Blocks with Vertical Aligned Columns

@leemon asks for a look at this Issue 19962, please. This bug affects many block plugins. I think it should be fixed in 5.4 @jorgefilipecosta This issue was already part of the must have board, unfortunately we did not fix it before the beta. If the fix is something very simple that we could include as a bug fix it would be good, but it is not something critical given that 5.3 already contains this bug.

Conflicts in Blocks with Vertical Aligned Columns

@isabel_brison General comment and feature proposal: gutenberg.run has been extremely useful for cross-platform testing, especially in an accessibility context. It would be great to have something similar for Storybook too! A few months ago, before gutenberg.run was working, I investigated using Tugboat for generating PR previews. It might be a good tool for a storybook preview, as it’s fairly simple to set up.

@gziolo There are two parts there, it feels like it’s time to document and promote gutenberg.run. It works great! @youknowriad For the second part, we discussed building Storybook into WPAdmin somehow and just use a single tool (gutenberg.run) for all. @gziolo  We had integration for Storybook but there were some issues with using commercial hosting. I remember that discussion. It sounds great. Let’s open an issue for that if it doesn’t exist.

Nested Blocks in FSE

@BMO  Does anyone have any updates on nested blocks and the impact on FSE? For example, being able to use semantic HTML in a template file? @jorgefilipecosta I think the solution is to provide head blocks and things like that @gziolo opened a PR 20218 that explores ways to make Group block flexible enough to cover this use case. @jorgefilipecosta making the group support several different tags may be a good solution.

@kjellr  The current block-based themes spec doesn’t include anything about structural tags like <head>. That’s probably something we should consider separately.

@gziolo It raised the question how flexible it should be, should we allow any tag?, etc. I’m sure other questions will follow, like how to mark those groups as landmarks, whether to include visually hidden heading and similar accessibility related optimizations to start we should define the list of core supported semantic tags used for grouping and how they would look in the inserter. I would also like to discuss it with the accessibility team on how we can ensure the best possible experience

@BMO  To ask what is probably an obvious question, is the focus or intent to prevent arbitrary HTML inside of template files? Because everything could/should be handled with a block? @youknowriad the answer is yes, because it needs to be editable as a block, though we have custom HTML block, custom classNames, etc. @BMO The group block solution looks interesting because it keeps these things nested.

Block-Based Theme Bi-Weekly Meeting 

@kjellr  Since we’re on the topic: every other week there’s a block-based themes meeting where we’re discussing these things too. The meeting is held in the themereview slack channel. For more information visit https://make.wordpress.org/themes/ 

Amy Kamala 7:16 pm on February 19, 2020
Tags:   

Agenda: Release Model Working Group – February 19, 2020

Here is the agenda of the chat happening today, Wednesday, February 19, 2020, at 08:00 PM UTC.

Some progress has been made following last week’s meeting! This week, we’ll discuss:

  • Kan Ban Board and Project for the Release Model Working Group
  • New issues/tickets added to the Github Repo
  • Issues/tickets that need volunteers

Looking forward to our chat!

#release-process

Francesca Marano 1:40 pm on February 19, 2020
Tags: , ,   

Dev Chat Agenda for February 19, 2020 (5.4 Week 6)

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

Announcements

  • This week marks week 5 of the 5.4 release cycle 🙌
  • WordPress 5.4 Beta 2 was released yesterday, February 18, as scheduled.

Highlighted Blog Posts

Upcoming Releases – 5.4

  • Beta 3 to be released on February 25
  • Status report on the About page – content and design
  • Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide

Components Check-in

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

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

Riad Benguella 11:49 am on February 19, 2020
Tags: , , ,   

Block Editor Keyboard Shortcuts in WordPress 5.4

In WordPress 5.4 a new package called @wordpress/keyboard-shortcuts has been introduced to centralize the registration/removal and documentation of the available keyboard shortcuts in the block editor screen.

Registering shortcuts

Registration of keyboard shortcuts should happen when first loading the screen/plugin. This can be achieved by calling the registerShortcut action.

wp.data.dispatch( 'core/keyboard-shortcuts' ).registerShortcut( {
	// Shortcut name (identifier)
	name: 'plugin/shortcut-name',

 	// Catergory (global, block or selection)
	category: 'block',

	// Description 
	description: 'Short description of your shortcut.',

	// The key combination used to trigger the shortcut
	// Could be just a single character or a character with
	// a modifier.
	keyCombination: {
		modifier: 'primaryAlt',
		character: 't',
	},

	// Some shortcuts can be triggered using several 
	// key combination, the aliases array is used to define
	// the alternative combinations
	aliases: [
		{
			modifier: 'primary',
			character: 'i',
		},
	],
} );

Registering a shortcut automatically add it to the keyboard shortcuts help modal to ensure its discoverability.

Implementing the keyboard shortcut behavior

The @wordpress/keyboard-shortcuts package also provides the useShortcut React hook to define the behavior triggered by the keyboard shortcuts.

import { useShortcut } from '@wordpress/keyboard-shortcuts';
import { useCallback } from '@wordpress/element';

const MyComponent = () => {
	useShortcut(
		// Shortcut name
		'plugin/shortcut-name',

		// Shortcut callback
		useCallback(
			( event ) => {
				// Do something when the keyboard 
				// shortcut is triggered
			},
			[]
		)
	);
}

Using this React hook instead of a custom implementation comes with a few advantages:

  • If the shortcut is unregistered by a third-party plugin, the callback is just ignored.
  • The shortcut key combination can be modified at runtime and the callback will still be called properly.

Removing existing shortcuts

Registered shortcuts can also be unregistered (and potentially replaced) by third-party plugins

wp.data.dispatch( 'core/keyboard-shortcuts' ).unregisterShortcut(
	'plugin/shortcut-name'
);

Next steps

In the next releases, this package will also allow offering a centralized UI to modify the keyboard shortcuts per user.

#5-4, #accessibility, #block-editor, #dev-notes

Jb Audras 10:11 am on February 19, 2020
Tags: , ,   

Enhancements to favicon handling in WordPress 5.4

WordPress 3.0 introduced wp_favicon_request() to avoid the performance hit that comes from serving a full 404 page on every favicon request. While that function works as intended, it doesn’t offer enough flexibility.

As of WordPress 5.4, theme and plugin authors can manage favicon requests much more flexibly, with the following logic:

  • If there is a Site Icon set in Customizer, redirect /favicon.ico requests to that icon.
  • Otherwise, use the WordPress logo as a default icon.
  • If a physical /favicon.ico file exists, do nothing and let the server handle the request.

This logic will only work if WordPress is installed in the root directory.

With these changes, /favicon.ico handling is now more consistent with /robots.txt requests.

New functions & hooks

WordPress 5.4 introduces a bunch of new functions and hooks for favicon handling:

  • is_favicon() conditional tag to complement is_robots().
  • do_favicon action to complement do_robots and use it in template loader. This hook will be fired when the template loader determines a favicon request.
  • do_favicon() function, hooked to the above action by default, to complement do_robots().
  • do_faviconico action to complement do_robotstxt, for plugins and themes to override the default behavior. This hook will be fired when displaying the favicon file.

With the above logic, do_favicon redirects to the Site Icon if it exists, or to WordPress logo as a default icon, using the following code:

function do_favicon() {
    /**
     * Fires when serving the favicon.ico file.
     *
     * @since 5.4.0
     */
    do_action( 'do_faviconico' );

    wp_redirect( get_site_icon_url( 32, admin_url( 'images/w-logo-blue.png' ) ) );
    exit;
}

Themes and plugins developers can use do_faviconico action to override the default behavior.

Deprecations

  • wp_favicon_request() is now deprecated in favor of do_favicon().

For reference, see the related ticket on WordPress Core Trac: #47398

#5-4, #dev-notes, #favicon

Paal Joachim Romdahl 4:29 pm on February 18, 2020  

Editor Chat Agenda: 19th February, 2020

Note taker: @pbrocks

This is the agenda for the weekly editor chat scheduled for 2020-02-19 14:00 UTC. This meeting is held in the #core-editor WordPress Slack channel.

  • WordPress 5.4 Upcoming Release
  • 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