Improve the "Add item" function in menus

[diebombe]

When the number of pages is getting higher and higher (~30+) it is really hard to find pages when adding them to a menu.

Suggestion:

• Make the #pagechecklist bigger (or adjustable) for more overview

I have to say, that sometimes i don't get the search.

2. suggestion:

• limit the search to the title

Thank you so much!

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that fixing the hierarchy issue in #18282 would likely resolve this as well.

[diebombe]

Replying to SergeyBiryukov:

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Just noting that fixing the hierarchy issue in #18282 would likely resolve this as well.

Thanks for this link! But 8 years old...? Hui... ;-)

[afercia]

This ticket was discussed during today's accessibility bug-scrub: agreed to scrollable divs need accessibility improvements. The accessibility team recommends to implement some of the recommendation from this post:
​https://developer.paciellogroup.com/blog/2016/02/short-note-on-improving-usability-of-scrollable-regions/

Beside that, there are also UI / UX considerations as pointed out by @diebombe that would need UI / design feedback.

[afercia]

Screenshot for reference.

[audrasjb]

Related: #49211

@afercia let's use #49211 to handle keyboard navigation enhancements, as pointed out in the 5.3 post-mortem blogpost ;-)

[davidbaumwald]

This ticket still needs design feedback and a direction, and with 5.4 Beta 1 landing tomorrow, this is being moved to Future Release. If any maintainer or committer feels this can be included in 5.4 or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[nickjbedford]

I also agree that the Add menu items > Pages search and View All tabs become hard to use with a large page structure.

For example, we have pages with specific titles but entering the exact title in the "Search" query returns anything but the page with the matching name, instead returning results at random that contain the word. Trying to find it in the View All tab requires endless scrolling and page turns.

I have to resort to adding Custom Links that to the menu that don't store the "Original" page reference, which I'd prefer not to do.

[joedolson]

The container was made resizable in #60763, so part of this is done; but the search is still extremely poor for adding menu items. I'd like to add this to 6.9 to explore improving that experience.

[joedolson]

#64092 was marked as a duplicate.

[joedolson]

See the PR on #64092: ​https://github.com/WordPress/wordpress-develop/pull/10237

Improve the menu item search by matching terms on post_title only.

An adjustment to the Appearance > Menus search feature so that only post_title is used for matching. This results in a more intuitive UI that aligns with what many people expect, and improves the ability to build a menu on sites many posts or pages.

Trac ticket: Add Menu Items search

[kevinlearynet]

All set, I've just updated the PR to use the older existing ticket.

Changes the menu quick search utility to only query the post_title column and adds a filter to enable previous functionality to be restored or customized.

Trac ticket: https://core.trac.wordpress.org/ticket/48655

[joedolson]

I just added an alternate solution, @kevinlearynet - this is a more core-native way of doing this, since it doesn't depend on adding a new action and a direct SQL filter, but makes use of existing features.

Can you test this and ensure it works the way you think it would?

In order to get this in to WordPress 6.9, I'll need to be able to commit before beta 1 (10/21/2025), so time is fairly tight.

[joedolson]

This will need a dev note to explain the change and provide information on how to reverse it, should that be needed.

[joedolson]

To test:

• Create multiple posts in a single post type. Have at least one post with a search term only in the post content, e.g. 'foo', and at least one post with the search term in both the post title and the post content.
• Before patch: search should return both posts.
• After patch: search should only return the post with the search term in the title.

[kevinlearynet]

This is tested and passes:

• Searching "lift" shows all posts and pages with the phrase or word "lift" in the title, in any case
• Search "lift" does NOT include pages with the phrase in post_content

But there's one enhancement I think we should make:

• When search results exist and a user remove the search term by clicking (X) within the search input it should clear the search results
• When search results exist and a user removes them manually, by selecting and deleting the input text or by pressing DELETE to remove existing terms, the results should reset when less than or equal to the minimum search terms length

I have a code adjustment for this, but I couldn't easily get it into your PR (sorry):

    updateQuickSearchResults : function(input) {
      let panel, params,
        minSearchLength = 1,
        q = input.val(),
        pageSearchChecklist = $('#page-search-checklist');

      /*
       * Avoid a new Ajax search when the pressed key (e.g. arrows)
       * doesn't change the searched term.
       */
      if ( api.lastSearch == q ) {
        return;
      }

      /*
       * Reset results when search is less than or equal to 
       * minimum characters for searched term.
       */
      if ( q.length <= minSearchLength ) {
        pageSearchChecklist.empty();
        return;
      }

      api.lastSearch = q;

      panel = input.parents('.tabs-panel');
      params = {
        'action': 'menu-quick-search',
        'response-format': 'markup',
        'menu': $('#menu').val(),
        'menu-settings-column-nonce': $('#menu-settings-column-nonce').val(),
        'q': q,
        'type': input.attr('name')
      };

      $( '.spinner', panel ).addClass( 'is-active' );

      $.post( ajaxurl, params, function(menuMarkup) {
        api.processQuickSearchQueryResponse(menuMarkup, params, panel);
      });
    },

Changes include:

• Replaced var with let
• Adjusted minSearchLength to be 1 and used LTE operator (previous was LT and 2, which is less clear)
• Added pageSearchChecklist selector
• Split the logic for last search and below minSearchLength to handle clearing of results

​https://github.com/WordPress/wordpress-develop/blob/f6cf8fae73d98c29d51d7c70a687211f8dd7f6dc/src/js/_enqueues/lib/nav-menu.js#L1407-L1437

[joedolson]

As I was testing the patch, I also noticed that this behavior was kind of annoying. It's a pretty minor change to make this behavior more clear, so I think incorporating it makes sense.

[joedolson]

Test with updated patch:

1) Confirmed: search results return only values where the term is in the title, also has unit tests.
2) Confirmed: reducing the search query below the query length limit or deleting it clears search results.
3) Confirmed: screen reader messages spoken when results cleared, if there are no results for search, and with the number of results returned.

No visual changes, so no screenshots.

[joedolson]

There's an outstanding request on the PR for a change to the unit tests, but I'm unclear what that request is looking for. The test change can be committed as a follow up at any time, so I don't consider it a blocker for this change.

Marking for commit.

[joedolson]

In 60991:

Menus: Improve usability and accessibility of menu quick search.

Change the admin menu quick search to limit to searching post titles. Add filter wp_ajax_menu_quick_search_args to support customizing post columns in query. Clear quick search results when search query is cleared. Send announcements about search status via wp.a11y.speak().

Props diebombe, afercia, audrasjb, nickjbedford, kevinlearynet, mukesh27, joedolson.
Fixes #48655.

[desrosj]

The miscellaneous developer-focused changes developer note mentioned the new wp_ajax_menu_quick_search_args filter hook introduced in [60991], but did not cover it's usage in depth: ​https://make.wordpress.org/core/2025/11/17/miscellaneous-developer-focused-changes-in-6-9/.

Stay tuned for a separate, proper dev note.