Ability to add custom Navigation area types

[getdave]

What problem does this address?

Currently, out of the box the Navigation Area block supports

• Primary
• Secondary
• Tertiary

Developers should be able to extend this list.

What is your proposed solution?

Add a filter or provide some other means of extending the list of areas.

[getdave]

@anton-vlasenko Might you be able to help out with this one?

[talldan]

@getdave I think there's already a register_navigation_areas function that developers can call. It probably needs some testing to make sure it works ok for themes.

I don't know that a filter is needed given the function already exists. Could you add a use case for such a filter to the issue description?

[getdave]

Hi Dan. If register_navigation_areas already exists (and works!) then we're all good and this issue isn't needed. I was wrong. As per #36178 (comment) we should avoid functions that make it super easy to wholesale overwrite good solid defaults. Instead the filter based approach would be much better.

I'll run some tests and document what I find.

[talldan]

Lets move the conversation over here.

I think we should provide some strong defaults but allow users to change extend how they like.

I think it's fine to let users change the public facing names of a navigation area (e.g. from 'Primary' to 'Header'). But we should do our best to promote keeping the 'keys' (primary, secondary, tertiary) that are used internally by WordPress the as non-modifiable. This is what theme switching depends on.

Perhaps something like this would make it clearer and more declarative for users:

register_navigation_area( array(
    // These three areas will migrate menus on theme switch
    array(
        'name' => 'Header',
        'type' => WP_NAVIGATION_AREA_PRIMARY
    ),
    array(
        'name' => 'Footer',
        'type' => WP_NAVIGATION_AREA_SECONDARY
    ),
    array(
        'name' => 'Sidebar',
        'type' => WP_NAVIGATION_AREA_TERTIARY
    ),
) );

I think it might be a problem that we only support three 'types' or 'keys' at the moment. Should we add more names (like you mentioned with quaternary, quinary, senary, septenary, octonary, nonary, denary?).

I didn't realise that register_navigation_areas would overwrite the existing items. If that's the case then I think we should make that function private and instead provide a filter.

Filters usually also allow overwriting, they can return completely different data.

That's why I'd prefer a register function as a starting point, as it'd be more possible to promote an API that encourages the right behavior from implementors.

A filter is also something to consider in the future, but there should be a clear use case for it.

This approach is more "WordPress" and also tends to encourage extension rather than wholesale overwriting.

There are lots of 'register' functions across the WordPress codebase: https://wordpress.org/search/register_

[anton-vlasenko]

@anton-vlasenko Might you be able to help out with this one?

Sorry for the delay.
I will take a look at it.

[talldan]

For reference, here's an example of how it works currently:
https://github.com/WordPress/wordpress-develop/blob/9b142dd26498392577d2ea4930fea45e61790a05/src/wp-includes/navigation-areas.php#L33-L39

Perhaps it's ok. We should definitely test that it works for themes. Maybe we can try it out in Twenty Twenty Two or one of the theme experiments.

I think it could be an idea to improve the docs to recommend not changing the default (primary, secondary, tertiary) keys in the array, and also include examples that show registering more than just the default areas as well as using different names. e.g.:

	register_navigation_areas(
		array(
			'primary'   => _x( 'Header', 'navigation area' ),
			'secondary' => _x( 'Footer', 'navigation area' ),
			'tertiary'  => _x( 'Sidebar', 'navigation area' ),
			'shop'.     => _x( 'Shop sub-navigation', 'navigation area' ),
		)
	);

[anton-vlasenko]

I think it could be an idea to improve the docs to recommend not changing the default (primary, secondary, tertiary) keys in the array, and also include examples that show registering more than just the default areas as well as using different names. e.g.:

Nothing stops us from disallowing developers to change the default keys via the filter programmatically while allowing them to change titles.