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.

[masteradhoc]

+1 on this one, definately needed. just have to build custom links now for this.

[wpchannel]

+1 this is missing! I'm currently moving from custom theme to block theme and migrating menus is failing on this kind of links too.

[Humanify-nl]

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

Did this get picked up for 6.3? Didn’t see anything in the notes.

[getdave]

It didn't get address in the 6.3 cycle unfortunately.

Contributors are looking at priorities for 6.4 now based on capacity. As always PRs are always welcomed.

[walton-alex]

+1, definitely needed!

[WebGuyJeff]

+1

Just ran into this. I have a few CPTs which need the archive/child pages to be menu item/sub-menu items respectively.

[nathan-schmidt-viget]

+1
Running into this same issue

[ltrihan]

+1
People keep telling me about using the template hierarchy instead of page templates 😛 , but it's true that it's annoying not to have these little features natively.

[uladzimirkulesh]

+1

Just ran into this. I have a few CPTs which need the archive/child pages to be menu item/sub-menu items respectively.

I have the same problem.

[laurelstreng]

I had a similar issue with missing the 'active' class on menu items because they weren't available to add in the Menus screen. Based on @cr0ybot 's JS, I adjusted the function a bit so that it's just based on path. The current-menu-item class gets added to a menu list item if it's path matches the browser path.

This fixed my initial issue and also actually helped out on a separate header navigation/project where I always needed the parent menu item 'active' if on a 'child' post/page.

function setCurrentMenuItemClass() {
    // Get the current URL.
    const currentPath = window.location.pathname;
    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;
        }
    }

    menuItems.forEach(menuItem => {
        const link = menuItem.querySelector( 'a' );
        const linkURL = link.pathname;

        // If the current browser path includes the menu list item path, add the class.
        if ( currentPath.includes(linkURL) ) {
            menuItem.classList.add( 'current-menu-item' );
        }
    });
}

[getdave]

Steps to complete this work:

• add a new search handler REST API endpoint for post-type-archives
• update the fetchLinkSuggestions code to include the ability to search archives.
• apply any updates to the <LinkControl> component (TBD)

This work could be split into PRs for:

• REST API work
• fetch handler and component work

Prior art for this in Classic Menus (not using REST API) can be used as a basis for some of the code.

[getdave]

I had a PoC for this locally, so I got the ball rolling here with #66821