What

Fixes #61266

Fixes current-menu-item and aria-current="page" not being applied to Navigation Link blocks in several scenarios that should produce an active state.

Why

The PHP render function used a fragile dynamic property lookup to determine whether a nav link is active:

$kind      = empty( $attributes['kind'] ) ? 'post_type' : str_replace( '-', '_', $attributes['kind'] );
$is_active = ! empty( $attributes['id'] )
    && get_queried_object_id() === (int) $attributes['id']
    && ! empty( get_queried_object()->$kind ); // ← dynamic property on queried object

This converts kind from kebab-case to snake-case and then reads a property of that name off the queried object. It works for "post-type" (→ WP_Post->post_type) and "taxonomy" (→ WP_Term->taxonomy), but silently fails for any other value:

• kind: "custom" — links saved before the current entity-link conventions, or links where the editor resolved a URL to a post ID, store id alongside kind: "custom". The property get_queried_object()->custom never exists, so $is_active is always false.
• kind absent, type: "category" or type: "tag" — the JS editor omits kind from the stored attributes when newKind is empty and the type is a built-in (see update-attributes.js). Defaulting to "post-type" causes a WP_Post check against a WP_Term archive page.

How

During development, the classic WordPress menu system (_wp_menu_item_classes_by_context() in wp-includes/nav-menu-template.php) was reviewed as a reference for how active-state detection should work and how post/term ID collisions should be prevented. That analysis directly informed the approach taken here and identified the follow-up gaps noted at the bottom of this PR.

Replaces the property-lookup approach with explicit instanceof checks, mirroring how the classic menu system avoids post/term ID collisions:

• $stored_kind and $stored_type are read from attributes
• When kind is absent, taxonomy_exists( $resolved_type ) infers whether the link targets a taxonomy — handles category, tag (mapped to post_tag), and any registered custom taxonomy
• $is_taxonomy_link drives an instanceof WP_Term vs instanceof WP_Post check, replacing the unreliable property lookup
• $link_id uses is_numeric() to guard against the historical case where id could be a URL string
• Post/term ID collision protection is fully preserved (a taxonomy link never becomes active on a post page with the same integer ID, and vice versa)

Testing Instructions

1. Create a page (e.g. "About") and publish it
2. Add a Navigation block and insert a Custom Link item pointing to that page's URL, using the search/autocomplete to select the page (so an id is stored)
3. Visit the page on the front end — the nav item should now have current-menu-item and aria-current="page" ✅
4. Repeat with a Category link and a Tag link — both should activate correctly on their respective archive pages ✅
5. For custom post types: register a CPT, create a post of that type, add a navigation link to it, and verify the active class appears when viewing that post ✅
6. Verify no false positives: a category link should not be active when viewing a post whose ID happens to match the category term ID

Backwards Compatibility

Tests

24 PHP unit tests added to phpunit/blocks/class-block-library-navigation-link-test.php covering:

• Active state for pages, standard posts, custom post types, legacy links without kind, and kind: "custom" links with id (the confirmed bug)
• Active state for categories, tags, and links where kind is absent but type identifies a taxonomy
• Inactive state for non-matching pages, absent/zero/string IDs
• Post/term ID collision guards (must pass both before and after the fix)

Known gaps — follow-up issues

As part of this work the classic WordPress menu system (_wp_menu_item_classes_by_context()) was reviewed in detail. It handles four distinct match branches (A–D); this PR addresses Branch B (direct ID + type match). The following gaps should each be tackled as a separate follow-up issue:

1. core/navigation-submenu has the same bug — the submenu block's index.php contains an identical copy of the broken ->$kind property lookup. The same fix applies. There is also an opportunity to extract the shared $is_active logic into a single utility function rather than maintaining it in two places.

2. No URL-based matching for links without an id (Branch D) — the classic system matches custom type items by comparing the stored URL against REQUEST_URI. A kind: "custom" link with no id (severed entity links, manually-typed URLs) will never receive current-menu-item even when the URL exactly matches the current page.

3. No taxonomy ancestor propagation (Branch A) — when viewing a singular post, the classic system flags any category/tag the post belongs to as an active parent, walking the full ancestor chain. The block system has no equivalent.

4. No ancestor/parent classes — current-menu-ancestor, current-menu-parent, current-{object}-parent, and related classes from the classic system's second pass are largely absent from the block implementation (the submenu block has partial support via an inner-block scan, but nothing systematic).