Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add block: Navigation menu #13690

sarahmonster opened this issue Feb 6, 2019 · 36 comments

Add block: Navigation menu #13690

sarahmonster opened this issue Feb 6, 2019 · 36 comments


Copy link

@sarahmonster sarahmonster commented Feb 6, 2019

Since creating a block for navigation menus is one of the priorities for 2019, @melchoyce and I have been spending some time working on some ideas for a navigation menu block.

Lots of great work toward exploring a navigation block has already happened in #1466. In the interests of refocussing the conversation, I'm opening a new issue for this as we attempt to reach a solution.

First, let's establish a framework for understanding and evaluating the proposed solutions.

1. What’s the problem we’re trying to solve?

Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of your site often requires manual work.

2. What existing research do we have?

Menus came up a few times in our sitebuilding research. Relevant takeaways: some people model the structure of their menus on the structure of their sitemap (or vice-versa).

Competitive analysis:

Mel reviewed existing explorations to compile the discussion and ideas that have emerged around navigation blocks over the years.

Functionalities to consider:

  • sticky menu
  • horizontal or vertical menus
  • nested menus
  • social menu
  • mega menu: image, description, button, etc

3. What are our guiding principles?

After discussion with developers, accessibilities, and other designers, we've decided that in order to support the problem:

  • building a menu should be as WYSIWYG as possible
  • menus should be as flexible as possible
  • there should only be a single experience for building and editing a menu, even if that experience is duplicated in different parts of the UI
  • the menu-building experience should be consistent with existing Gutenberg design patterns
  • the solution should allow for all functionalities identified in “existing research” section
  • should allow for adding pages and defining page/sitemap structure

4. How do we choose a successful solution?

Using prototypes, we’ll test and time the creation of a simple menu and a complex menu. We’ll also ask users to rate their experience from a scale of 1-5.

This quantitative data (experience rating and time to creation) will be used alongside the qualitative data (user feedback, your feedback!) to determine which solution is the most effective and should be pursued. @melchoyce will be responsible for this selection. We'll then iterate on the solution until we hit on what we think is the best approach.

Copy link
Member Author

@sarahmonster sarahmonster commented Feb 6, 2019

In exploring solutions, @melchoyce and I narrowed down to two paths.

These particular prototypes focus on creating a new menu from scratch. Not every state or setting has a mockup — the focus right now is to go broad, not deep, in this exploration. We'll test these two approaches and then narrow down in iterations, based on your feedback as well as user feedback.

Concept: Going all-in on child blocks





This approach takes advantage of some smart patterns introduced by the Jetpack contact form block and WooCommerce products blocks. Each page type is its own child block. We focused on two things: using as many established Gutenberg patterns as possible for consistency, and retaining existing navigation menu features so the block can be a direct port for backwards-compatibility purposes.


  1. We’ve introduced a “hide menu” setting, which is to tackle the issue of some themes providing default menus, some setting fallbacks, etc., which means there’s no consistent way to get rid of a menu. In the future when we have full site editing, this could come in handy for themes or sites that don’t allow you to delete global blocks. For now, it’s a bit superfluous and we might remove it.
  2. The navigation menu should include a “Login” and “Logout” item, as well as an RSS feed link menu item — should these be their own menu types, or listed in “Pages?” Maybe they should be in a “Meta” page type?
  3. We’ve included menu descriptions inline, but we're wondering if, since not a lot of themes currently support them, if they should live in the sidebar?
  4. Should we deprecate any menu features, like XFN, from the block?
  5. Should any other menu options live in “Advanced Settings?”
  6. Anything missing?

Concept: Menus are just links


Desktop prototype:


Mobile prototype:

Inspired by Material Design’s chips, this option aims to present the menu as closely as possible to the way it looks on your live site.

This uses the some interface as adding links elsewhere (when creating an inline link, or when adding a button) so there’s consistency any time users add a link. (Note that this only works if users think of navigation in the same way they think of inline links, which may not be the case.) This is a good opportunity to refine and unify how this interface works (#6392) as well as evaluating other search interfaces. We can unify these experiences across the entirety of the product whilst also making a teensy accessibility win.

It tries to make as many smart default guesses as possible for the user: it allows for converting menus if you already have some saved, but if you don’t, it defaults to a small menu based on existing pages. Finding items to add to the menu is primarily based around a smart search that searches across all types of content on your site, as well as including pages for archives and recognising and adjusting for social media links. Pasting a link will work as expected, so the interaction will be immediately accessible in as few inputs as possible.


  1. Does the chip approach work here to add clarity and usability, or does it feel too divorced from existing Gutenberg patterns? Is there a better way to clearly communicate a link in a navigation menu while it's being edited? (See alternate style ideas.)
  2. This approach avoids putting settings in the sidebar as much as possible but doesn't include many fine-grained controls (beyond a horizontal/vertical option and alignment for the menu, and a few options for individual menu items). Are there other settings that should be included here?
  3. How can we improve on the existing "add link" interface to make it more accessible, usable, and flexible? (For instance, the ability to upload a file directly here would go over like gangbusters; see also #8322.)
  4. This isn't included in the prototype yet, but we'll want to include some options for adding new content here as well: maybe just a "Create new page" option below search results? Are there other types of content we should allow for dynamically creating from this menu?
  5. Sub-menus haven't been fully explored here yet either, and they open lots of questions. Should we allow for unlimited layers of sub-menus, or restrict the number of children? Should sub-menus be expanded by default, or should there be a way of expanding and collapsing them? Can you select a sub-menu individually? Would the toolbar be specific to the parent menu, or to the sub-menu? Is there such a thing as sub-menu settings, or are those settings owned by the parent menu and applied across all sub-menus?
  6. What happens when a user has a lot of items in their menu? How can we make it as easy as possible to navigate through those items across a range of devices?

What do you think?

At this point, we'd especially appreciate overall feedback about:

  • Technically feasability: Can we do all this? Are there ideas here that are too wishful thinking?
  • Accessibility: Are there things we could improve here? Does anything in particular raise a red flag? What can we do to ensure these approaches are as accessible as possible?
  • Experience: Do these feel like natural approaches? Are there any parts of the flow that feel awkward?
  • Settings & functionalities: What functionalities and settings are critical to meet the needs of the majority of users? Are there settings we can drop, or that we should be sure to include?

Leaving comments directly in Figma would be great, and you can also comment here. We'll work on refining these prototypes and running some lightweight usability testing to get a sense of how natural the interactions are.

Copy link

@deckerweb deckerweb commented Feb 6, 2019

Login, Logout, RSS etc. should be a "Meta" type, NOT "Page"

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

  • nofollow / dofollow (for SEO purposes)
  • noopener and noreferrer (both for security purposes)
Copy link

@melchoyce melchoyce commented Feb 6, 2019

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

  • nofollow / dofollow (for SEO purposes)

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

  • noopener and noreferrer (both for security purposes)

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

Copy link

@deckerweb deckerweb commented Feb 6, 2019

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

Yes, that was what I meant. I often times have a few menu items which I explicitely set to nofollow - for example an external link to a donation service or the internal link to the privacy page (because I don't need both to be indexed in Google...). I know lots of other devs and users doing this similar.

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

In my opinion yes, for all links that open in a new tab/window (_blank target).

Also, the option to set an optional link target (to open in new tab/window) must be kept - at it is currently. This is an essential user option.

Copy link
Member Author

@sarahmonster sarahmonster commented Feb 6, 2019

"Meta" may not have any meaning to the majority of non-technical end users, but you're right that log in, log out, and RSS links aren't the same as static pages. What's a way to communicate this clearly to users? Maybe the login and logout could be classified as "action" links? Perhaps the RSS feed is a special "feed" type, or maybe it acts the same way as a social media link (basically as a special type of link.)

XFN is pretty user-hostile as it currently stands, but it's helpful to get a sense of how that feature might be being used. It's actually intended to show a personal relationship and used to be more explicit when Blogrolls were still a Thing. I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

Copy link

@melchoyce melchoyce commented Feb 6, 2019

I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

That would also allow for some inline explanations, which would definitely help.

Copy link

@getdave getdave commented Feb 6, 2019

Thank you so much for this. Great to see this moving along. Some thoughts...

Concept: Going all-in on child blocks

Technically feasability

Everything I see looks doable.


  • What would re-ordering items in the menu look like?
  • Veritcally displaying the Menu whilst editing is good when constructing a Menu that maps to a Sitemap in the user's mind. However visually I feel the preview will need to better reflect the reality on the frontend (ie: most menus are't vertical). However will the change between the two states be too jarring?
  • Visually the items don't feel like "menu items" they just feel like links. I appreciate this is fundementally what they are but a Menu item implies much more. If each item were more of a contained "unit" then you could give them their own controls. Perhaps more closely aligned to the existing WordPress menus?
  • Once added there isn't a way to visually see the type of the menu item (eg: Page, Post, Category...etc) without interacting.
  • How do I remove a Menu item once added? Nothing visually shows up? Also an a11y concern.

Concept: Menus are just links

Technically feasability

Everything I see looks doable.


  • I like the "chips"
    • make it easy to remove an item
    • the inline auto complete is a nice touch*
  • I believe adding Social to this is a step too far. See notes below.
  • It's not immediately clear to me as a user how I crate hierarchies
  • Can we stress test the design a bit with the horiztonal layout? It's fine with 3 items but what happens when you have 10? You can't easily wrap as that could be confused with a hierarchy. How will this scale? (see comments above re: vertical layout when in editing mode)
  • I preferred the explicit choices (Page, Post, Link...etc) in the "child blocks" prototype. It was clear what you were adding to the menu and the search was a nice extra. Could we merge the two?
  • How do I reorder items?

General: Settings & functionalities

  • Login/out and RSS should be separated under Meta as suggested
  • Gut feeling is that Description is rarely used. Put that in sidebar. Prioritise the UI space elsewhere.
  • I'm fairly against muddying the concept of creating a Menu with the concept of adding new Pages. The act of creating a Page feels like it needs to be explicit and not part of creating a Menu Block.
  • I'd say remove as many "rarely used" (TBC) features as possible. Keep the UI nice and focused wherever possible. We can always add more settings later if user demand dictates it.

Relationship to "Social Links"

There is an existing Issue for Social Links. I (and others) don't believe the Menu Block precludes the need for a dedicated Social Links block.

Most users won't cognatively assiociate "Menu" with "Social Logos". When searching Blocks they'll expect "Social Icons/Logo/Links" not "Menu".

I appreciate at a deep level Social Links and Menu Items are similar in concept but to me they feel like distinct Blocks. I fear that if we get too "meta" on our Blocks and try and require overconfiguring them then UX may suffer.

I'm very interested in hearing your thoughts on this as I am (was going to be) taking on the Social Links Issue...

Again, thanks for moving this conversation forward.

Copy link

@LukePettway LukePettway commented Feb 6, 2019

Some of the accessibility concerns that come to mind would be:

Keeping control of user focus throughout the flow

When clicking the Add a Menu Item button, a dropdown appears which then provides a search input as well as several sections to locate a page or pages to add to the navigation. Once a page or pages have been added to the menu, the dialog closes and returns the user back to the block. That is a lot of moving around between different components on the page.

The most important thing here is to make sure that we are updating the focus and placing it in the next logical spot. I also wonder to what extent focus might need to be trapped within these elements because it might be really easy to escape the component before the workflow of adding a page has been completed.

Providing Additional Context to Assistive Technology

When selecting any number of menu items, having some way to inform assistive devices about their current selection state is crucial. This could be notifying them that the number of selected items changed from 3 to 5 for example.

Another area of consideration is the approach to nested page structures. To a user who is not blind, it is easy to infer the hierarchy of content when adding a category and pages under that category for example. This might become an issue for those using assistive technology. Am I adding these pages inline?, how do I know that the pages I am adding will be children of the parent they are currently under. This is especially the case if selecting the parent could potentially also select the children (solved again by announcing the selection to the assistive device).

I'll spend some more time thinking about this experience and please let me know if you have any questions about my comments. Thank you for all of this!

Copy link

@alexislloyd alexislloyd commented Feb 6, 2019

My hypothesis is that there are three primary types of user intent when inserting a nav menu:

  1. I’m a business owner who wants a menu linking to all the top-level pages
  2. I’m a blogger who wants a menu linking to all the top-level categories
  3. I want to make something custom from scratch

I also suspect number 1 is the most common, and that users who are in the number 1 category have the highest likelihood of not being experts.

I was originally thinking that we could give users a choice between 1, 2, and 3, like option A in the sketch below.

However, it occurred to me that instead of confronting the user with a choice, number 1 could just be the smart default, and you could make it easy to infinitely customize from there. I imagine most “custom” menus are actually just variations on one of the first two, so having that populate as a default and then be able to take out a link here, add a link there, add a social button, etc. is likely easier than starting from scratch anyway.

So, in option B below, the user inserts a menu and it defaults to a menu of all the top-level pages, with an easy toggle to switch to categories. Each menu item is selectable, editable, movable. You can add new items. And the sidebar could support lots of more advanced options like adding additional levels to the navigation.

untitled_artwork 6

@getdave getdave mentioned this issue Feb 7, 2019
5 tasks
Copy link
Member Author

@sarahmonster sarahmonster commented Feb 7, 2019

Thanks for the feedback! We're going to keep collecting more feedback and then iterate on these designs based on feedback and testing. A few quick-ish notes:

@getdave We've definitely seen some evidence that indicates users tend to think of adding pages (building their site structure) and building a menu as an intertwined process, and they can often become confused when pages they've created don't automatically appear in their menu. The social links is just a hunch, though, and it might be based on the existing pattern of themes registering social menu areas, so it's worth evaluating if that's how users see things.

I'm going to see if I can test these hypotheses a bit when we usability test these designs. If you have any insights on users' thought processes around these components, it'd be super useful to incorporate those!

@LukePettway Thank you so much for the accessibility feedback! For the focus consideration, do you think either of these methods of adding a menu item (the child block interface vs the link interface) presents fewer hurdles?

Your point about nested page structures is especially helpful, since nested structures are a bit tricky to design for. Thinking about how to non-visually indicate this hierarchy to users of assistive technology may actually be key to unlocking some good ideas here—I'm adding to the list of "things to explore more".

@alexislloyd it sounds as though what you're suggesting here is similar to the "auto-populate" option presented in the "Menus are just links" option, where users who haven't already created menus are given a menu populated from their pages, rather than an empty menu, and users with existing menus are shown those menu.

screenshot 2019-02-07 11 03 38

The idea here is that we'd try to make smart guesses for what they'd want in their menu, but immediately allow for customisation of those items, which I suspect most people would immediately want to do.

I think we could possibly take this a step or two further and try to add other helpful, smart defaults, so rather than just including top-level pages, leverage certain common naming patterns to determine order, or which pages to include or exclude. My suspicion, based on a cursory evaluation of common menu patterns across blogs, is that #2 is actually a less likely scenario than we might think, and that most blogger sites use a combination of categories and pages in their menu.

Rather than asking users to reckon with the choice between pages and categories, we can skip this step altogether and provide them with a ready-to-go menu that includes pages as well as categories (perhaps above a certain threshold), along with other suggested links based on common patterns and their existing site structure. I have a few thoughts for how this might work, but I'm going to look for some data to back them up and explore a few alternate ideas. This should also allow us to test if our smart defaults will actually feel smart for the majority of people.

Copy link

@scruffian scruffian commented Feb 7, 2019

Following on from @alexislloyd's point, something I have seen in usability tests and research, time and again, is that users conflate their navigation with their site structure. If they add a page they expect it to appear in the navigation. If they add an item to their navigation, they expect a page to be created.

I wonder if we should consider creating two different blocks. One very simple "page navigation" block, which maps 1:1 to a user's pages - when they add an item to the navigation a new page is created; when they add a page to the site, its added to the navigation.

Then we can add a second "custom navigation" block which will allow for all of the complexity that many users need.

Copy link

@alexislloyd alexislloyd commented Feb 7, 2019

@scruffian you make a very good point about the conflation of navigation and site structure. That might be a secondary problem to try and solve once the fundamental insertion of the block is nailed down.

As to insertion, I still think we could do it with one block — I think the ideal experience would be one where someone doesn't have to stop and think "Do I want a page navigation block or a custom navigation block?" Ideally, we can remove any friction that makes someone stop and wonder if they understand the choices. If we provide something relatively smart but make it incredibly easy to modify, it seems like it would be able to satisfy everyone's needs, whether simple or custom, without having to create any friction or potential confusion for the user up front.

@sarahmonster I like how you're going even further with the smart defaults idea — the approach you're suggesting also really supports users who don't know the difference between pages and categories (and shouldn't have to!).

Copy link
Member Author

@sarahmonster sarahmonster commented Feb 8, 2019

Thanks for all the helpful feedback here! In the interests of maintaining focus and ensuring that we've fully explored all parts of the problem before moving toward a solution, we're going to break the problem into smaller parts to explore individually:

  1. What happens when I add a menu? (smart defaults, onboarding)
  2. How do I add an item to my menu? (child blocks, link interface, types of content to include)
  3. How do I edit that menu item? (renaming, settings)
  4. How do I rearrange items in my menu? (ordering, hierarchy, sub-menus)
  5. How are menus and menu items presented visually? (focussed state, horizontal/vertical styling)

We’re going to discuss each of these problem areas individually in more detail, then return here with the resolution once we’ve reached a consensus. (Links coming as new issues are created!)

We’re also going to do some additional research to inform these explorations:

  • digging up insights from support forums
  • collecting common menu patterns from a range of different sites

If anyone would be interested in helping with any of these tasks, we'd definitely appreciate the help!

Copy link

@draganescu draganescu commented Jul 15, 2019

@idea--list thank you for the great analysis of the challenge for implementing a menu.

It is indeed a complex feat and that is why we'll go from simple to complex in iterative steps. I believe by the iterations @sarahmonster meant prototyping phases.

Copy link

@idea--list idea--list commented Jul 16, 2019

@draganescu I wanted to make sure all the challenges will taken into account before writing any line of code ;-) Just because i read about the several tiny phases. I mean in most cases you begin with multiple phases if it is still not crystal clear what will you end up with. And we all know the feeling when you recognize in phase 5 that you should have coded something completely differently in phase 1... :-)

@karmatosed karmatosed removed this from Navigation in Phase 2 Jul 16, 2019
@karmatosed karmatosed added this to In Progress in Blocks Jul 16, 2019
@draganescu draganescu added this to Doing in Navigation editor Jul 17, 2019
@draganescu draganescu removed this from Doing in Navigation editor Jul 17, 2019
@karmatosed karmatosed added this to To Do in Navigation editor via automation Jul 19, 2019
@karmatosed karmatosed removed this from In Progress in Blocks Jul 19, 2019
Copy link

@draganescu draganescu commented Jul 30, 2019

Hi, while working on implementing the block itself I found it quite challenging to figure out how nesting should work. Thinking about it I have explored simple linear interaction that would allow both nesting and menu item creation and arrived at this sketch:


The advantages of this approach to the creation flow would be:

  • easy to implement using only standard Gutenbeg inner block mechanics and components
  • visually clear nesting interaction
  • easy to switch from vertical to horizontal menu creation

This is JUST A SKETCH not an actual design :) of course.

Thanks and let me know any thoughts you might have on it.

@sarahmonster @mapk

Copy link

@mtias mtias commented Jul 30, 2019

This is JUST A SKETCH not an actual design :) of course.

This is interesting. I think a mode that represented the menu as a tree will be needed (might open it in a modal instead of inline, but we'll see) and using the "block navigator" makes a lot of sense, as we'll get interactions for free. Particularly once we allow dragging elements in the navigator to reorder blocks.

Copy link

@mapk mapk commented Jul 30, 2019

After a discussion between @sarahmonster, @melchoyce, @karmatosed, @mtias and myself, we've decided to make a few design pivots on this block. I'll outline them here with the goal of closing this particular issue. A new issue #16821 has been created to track these changes.

Native block patterns

  • Use existing block patterns whenever possible (ie. the block toolbar).


  • Refine the horizontally aligned inner blocks.
    • Explore how this pattern can extend to other blocks like button, columns, etc.
  • Improve how child blocks perform in narrow spaces.

Adding a new block & Block Library

  • The add block icon + should add an inner block with one click.
    • The inner block can then be defined as to whether it's a category, page, post, etc.
  • Explore how the Nav block works when added to the page.
    • Does it default to the primary menu?
    • Does it offer an empty state for creating new Navs?
      • Are there helper messages?
      • Tips?
      • Place holders?

Nesting blocks

  • Moving into/out of nested areas.
  • Data tree structure: #16812
  • (idea) Possible drag and drop interactions similar to #11408
  • (idea) Possible document outline repositioning? #9628 (comment)

URL and permalink structure

  • First iteration should offer a link in sidebar to the permalink page.
  • Any changes in the settings should reflect in the Nav block.

Customize options

  • Backgrounds (possible Group block)
  • Link colors
  • Font sizes
  • Background colors/gradients for dropdowns
  • Current menu item color/background options

Backward compatibility

  • When editing a Nav block that was created from existing wp-admin menu screen, should this action create a new menu?
    • Allow for manual conversion.
Copy link

@WayneAnderson WayneAnderson commented Oct 27, 2019

Would it be possible to accelerate the feature with an interim deployment of a part which simply deploys/displays an existing menu sourced from the WP menus functionality?

Copy link

@scottsawyer scottsawyer commented Feb 9, 2020

@WayneAnderson I am totally onboard with this, and was completely baffled not being able to select the native WP menu that I already spent 10 minutes making.

It seems a lot of effort going into recreating an existing, battle tested WordPress pattern. Native WordPress menus already solve so many of these challenges. While they don't provide much in the way of styling, they handle all of the questions about structure, custom links, categories, automatically adding of pages, attributes, etc.

In my opinion, the Nav block should focus on providing styling options, which is actually the hard part of WordPress menus in this context.

If adding the current page to a menu while in the edit context is a priority, I feel like that is more of a WordPress core issue, as pages already have the ability to select parents in the sidebar, thereby affecting site structure, so I think it makes sense to be able to add the current page to a menu in the same context.

A use-case that I commonly encounter is a "Section Sub-menu", that is, a page that is the parent for several child pages, where a menu is needed for the child pages, rather than an entire site structure.

The site I am working on right now has "Services", with several child pages, each with their own child pages, so 3 levels, a total of 12 pages so far and more to come.

  • Services
    • Service 1
      • Service 1.a
      • Service 1.b
    • Service 2
      • Service 2.a
      • Service 2.b
    • Service 3
      • Service 3.a
      • Service 3.b

What we want is a menu of this particular tree, which is very easy to build using existing WordPress menus, however, its more than a little painful to create in the current Nav block.

For starters, the search auto complete does not distinguish page hierarchy at all, so it's trial and error to ensure you are selecting the correct page level for similarly named pages. We have two pages titled "Buyers", but they are under different services. Impossible to tell which is which in the autocomplete as they have the same top level parent.

Secondarily, the Nav block does not allow for leveraging the existing ecosystem of WordPress menu enhancing plugins, such as ones that allow for setting classes, adding icons, etc.

Third, we now have two completely unrelated and incompatible methods of creating menus. This is very confusing and frustrating.

I understand the desire for creating a navigation in the page context, but I strongly recommend the Nav block at least support rendering a native WordPress menu.

Copy link

@javierlorente javierlorente commented May 12, 2020

Will it soon be possible to add native wordpress menus as a block in a post or even in the post and category editor?

Copy link

@mapk mapk commented May 12, 2020

Yes, there's a PR in the works, @javierlorente! 😄 #18869

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet