Are you a GenerateCustomer?

Do you have an active GP Premium or GenerateBlocks Pro license key?

Create a GenerateSupport account for GeneratePress and GenerateBlocks support in one dedicated place.

Create an account
Already have a GenerateSupport account? Login

Just browsing?

Feel free to browse the forums. Support for our free versions is provided on WordPress.org (GeneratePress, GenerateBlocks).

Want to become a premium user? Learn more below.

Unescaped submenu code showing after updating to GenerateBlocks Pro 2.4.0

  • Hey everyone,

    After updating to GenerateBlocks Pro 2.4.0 (GenerateBlocks 2.1.2 / GeneratePress Pro 2.5.5), my main menu that’s built as an Element using the new Site Navigation and Menu blocks started showing some unescaped code next to the submenu toggle arrows.

    Here’s what’s showing on teh front end:

    Sub-Menu" role="button" aria-expanded="false" aria-haspopup="menu" tabindex="0">

    Before the update everything looked normal.

    The menu item that’s acting up has an SVG icon pasted into the Navigation Label field on the menu page. It was working fine before the update.

    I noticed an earlier unresolved post from another user mentioning the 2.4.0 changelog note:

    “Tweak: Set dropdown menu aria-label in HTML”

    That seems to line up — looks like the new aria-label handling might be outputting unescaped HTML.

    For now I just removed the SVG from teh Navigation Label as a temporary fix, but I’ve re-enabled the version showing the issue here in case anyone wants to take a look:
    👉 https://marineconstructionmagazine.com/article/case-study-deconstructing-the-tappan-zee-bridge/

    Screenshot from the inspection tab for reference. Inspection Panel screen Shot

  • Hi there,

    Thanks for reporting this issue.

    Yes, the new GB pro version adds aria-label based on the menu item label, so it includes the SVG code in the aria-label as well.

    I’ll forward the issue to the dev team 🙂

  • Hi there,

    Sorry for the inconvenience here!

    Until we can release a patch, you can use this filter to fix the issue:

    add_filter(
    	'nav_menu_link_attributes',
    	function( $atts ) {
    		if ( isset( $atts['aria-label'] ) ) {
    			$atts['aria-label'] = esc_attr( wp_strip_all_tags( $atts['aria-label'] ) );
    		}
    
    		return $atts;
    	},
    	20
    );
    
    add_filter(
    	'nav_menu_item_title',
    	function( $title ) {
    		if ( ! class_exists( 'WP_HTML_Tag_Processor' ) ) {
    			return $title;
    		}
    		
    		$processor = new WP_HTML_Tag_Processor( $title );
    		$update = false;
    
    		// Use processor to find the gb-submenu-toggle class and escape its aria-label.
    		while ( $processor->next_tag( 'span' ) ) {
    			if ( ! in_array( 'gb-submenu-toggle', explode( ' ', $processor->get_attribute( 'class' ) ), true ) ) {
    				continue;
    			}
    
    			$aria_label = $processor->get_attribute( 'aria-label' );
    			if ( $aria_label ) {
    				$processor->set_attribute( 'aria-label', esc_attr( wp_strip_all_tags( $aria_label ) ) );
    				$update = true;
    			}
    		}
    
    		return $update ? $processor->get_updated_html() : $title;
    	},
    	20
    );

    Let us know if that helps or not 🙂

  • Thanks Tom, I tried adding the filter you shared, but it doesn’t seem to be targeting the right part of the output. It’s definitely running, just not catching that specific output.

    I dug around with some AI help and couldn’t find any workaround that keeps the original SVG appearing after the menu label while still preventing the raw code from showing. The SVG is decorative, it visually replaces a “+”, and it’s important that it stays inline with the label rather than being handled as a dropdown indicator.

    For now, I’ve swapped the SVG for a “+” sign, but would love to get back to the original look if there’s a clean way to do it.

  • Thanks Tom, appreciate you taking the time to look at this.

    I poked around a bit more and it looks like the issue’s coming from the Navigation block markup itself. The <span class=”gb-submenu-toggle”> is getting that extra text right inside the <path> before the submenu arrow SVG.

    From what I can tell, this is being output by the block render, not anything that runs through wp_nav_menu_* filters, so the snippet never actually touches it.

    If there’s a filter for the block render output I can test it there, but otherwise it looks like something that would need to be fixed in GenerateBlocks directly.

    For now I’ve switched the SVG to a plain “+” until there’s a fix.

  • The above snippet(s) should fix it. I tested entering HTML in my menu item labels on my local install, and it stripped the HTML successfully from the aria-label attribute.

    Our Navigation block uses the core menu system, so all of those filters are in use.

    Is it still not working on your end, even with the updated functions?

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.