Skip to content

fix: always localize storefront-navigation script regardless of menu assignment#2212

Open
thisismyurl wants to merge 1 commit into
woocommerce:trunkfrom
thisismyurl:fix/localize-script-outside-nav-menu-check
Open

fix: always localize storefront-navigation script regardless of menu assignment#2212
thisismyurl wants to merge 1 commit into
woocommerce:trunkfrom
thisismyurl:fix/localize-script-outside-nav-menu-check

Conversation

@thisismyurl

Copy link
Copy Markdown

What

storefront-navigation.js is always enqueued, but wp_localize_script() was only called inside if ( has_nav_menu( 'handheld' ) ). When the handheld menu location is registered but no menu is assigned, has_nav_menu() returns false, the storefrontScreenReaderText global is never defined, and the script throws a JavaScript error:

ReferenceError: storefrontScreenReaderText is not defined

This can happen on a fresh Storefront install before a menu is assigned to the handheld location, and on any setup where menus are managed outside of Appearance → Menus.

Before:

wp_enqueue_script( 'storefront-navigation', ... );  // always

if ( has_nav_menu( 'handheld' ) ) {
    $storefront_l10n = array( 'expand' => ..., 'collapse' => ... );
    wp_localize_script( 'storefront-navigation', 'storefrontScreenReaderText', $storefront_l10n );
}

After:

wp_enqueue_script( 'storefront-navigation', ... );  // always

wp_localize_script(
    'storefront-navigation',
    'storefrontScreenReaderText',
    array( 'expand' => ..., 'collapse' => ... )
);  // always — matches script enqueue

The l10n strings are static translated values. There is no cost to outputting them whenever the script is enqueued. The has_nav_menu() guard was protecting something that doesn't need protecting.

Related to #2082


Development and testing assisted by AI. All code reviewed and verified manually.

…ndheld menu is assigned

storefront-navigation.js is enqueued unconditionally, but
wp_localize_script() was called only inside the has_nav_menu('handheld')
conditional. When a handheld menu location exists but no menu is assigned
to it, has_nav_menu() returns false, storefrontScreenReaderText is never
defined, and the script throws:

    ReferenceError: storefrontScreenReaderText is not defined

The l10n strings are static translated values that cost nothing to
output. Moving wp_localize_script() outside the conditional ensures the
global is always available whenever the script is enqueued.

The has_nav_menu() guard is not needed here — the JS uses the strings
for accessibility labels on any navigation it finds in the DOM,
regardless of whether a menu is formally registered via WP.
Copilot AI review requested due to automatic review settings June 9, 2026 14:19

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR simplifies how screen-reader strings are passed to the storefront-navigation script by inlining the localization call and removing the conditional wrapper.

Changes:

  • Replaced a temporary localization array variable with an inline wp_localize_script() call.
  • Removed the has_nav_menu( 'handheld' ) condition so the localized strings are always registered for the navigation script.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants