Add Post Type Archive variation to `core/navigation-link` block

[getdave]

What problem does this address?

Currently you cannot add a Post Type Archive link to the Navigation block. However you can do this via the currently Menus screen.

Here's how you add a Post Type Archive to a menu.

What is your proposed solution?

Add a post-type-archive block variation for the core/navigation-link block. We'll also need to add test coverage for this in the navigation editor.

[gwwar]

@priethor I'm not sure this one needs to be marked as high. With a lighter nav experience in mind, #34041 folks have been chatting about de-emphasizing link variations in the quick inserter #35056 and have also chatted about a bulk inserter option in #31667

[priethor]

Yup, thanks for double checking, @gwwar !

[mgratch]

+1 This issue is... not fun to work around. Thanks!

[Humanify-nl]

This issue is the one reason I still have to remove archives and use normal pages instead,(1) the navigation-block doesn't recognize them. (2) the 'is-active' class is not placed on it, making standard navigation UX totally impossible.

Not fun indeed. Such a standard and crucial feature that still doesn't work after 1 year of FSE.

[Odinnh]

+1 This should be considered a core aspect of the nav block,

we have categories and custom taxonomies, we dont have a user friendly way of adding an archive page.

@priethor I'm not sure this one needs to be marked as high. With a lighter nav experience in mind, #34041 folks have been chatting about de-emphasizing link variations in the quick inserter #35056 and have also chatted about a bulk inserter option in #31667

IMO, it should be high priority seeing as this should be one of the fundamentals of the nav

[getdave]

@scruffian @priethor Should we look to pull this into the scope of work for 6.3? Seems achievable.

[priethor]

@getdave I think the Nav block experience is in a stage where we can re-prioritize this kind of issues; it seems a good thing to tackle for 6.3

[getdave]

Added to High priority on tracking issue for consideration for 6.3 cycle.

[cr0ybot]

As a stop-gap, I wrote this quick and dirty JS function to add current-menu-item to any navigation block item that matches the current URL. There are probably a lot of edge cases it won't account for, but it's working ok for me (for now).

Maybe there is a better way to do it server-side, but I'm hoping this issue with the navigation block is resolved before I feel the need to figure that out...

/**
 * Set current-menu-item class on link that matches current URL.
 */
export function setCurrentMenuItemClass() {
	const menuItems = document.querySelectorAll( '.wp-block-navigation-item' );

	if ( ! menuItems.length ) {
		return;
	}

	// Check for .current-menu-item class on any item and stop if found.
	for ( let i = 0; i < menuItems.length; i++ ) {
		if ( menuItems[ i ].classList.contains( 'current-menu-item' ) ) {
			return;
		}
	}

	// Add trailing slash to path if missing.
	const url = window.location.href.endsWith( '/' )
		? window.location.href
		: `${ window.location.href }/`;

	// Check for matching URL path on any child link of menuItems.
	for ( let i = 0; i < menuItems.length; i++ ) {
		const link = menuItems[ i ].querySelector( 'a' );
		const linkURL = link.href.endsWith( '/' )
			? link.href
			: `${ link.href }/`;

		// Note: link.href returns full URL, even if it's a relative link.
		if ( linkURL === url ) {
			menuItems[ i ].classList.add( 'current-menu-item' );
		}
	}
}

[Humanify-nl]

@cr0ybot Thanks for sharing your code.