I had a client running a massive WooCommerce shop with about 600 separate landing pages for various seasonal campaigns. Their marketing team called me up, sounding genuinely stressed. They were trying to build out a new navigation structure for a holiday push, but they couldn’t find the “Black Friday Early Access” page in the Appearance > Menus interface. They were searching for “Black Friday,” and the results were coming up empty. Total mess.
The page existed. I could see it in the Pages list. But the admin menu search query was acting like it didn’t. My first thought? I figured it was a conflict with one of their SEO plugins or maybe a stray pre_get_posts filter I’d missed. I spent a good forty minutes digging through their custom theme’s functions.php, convinced some junior dev had written a bad query filter that was mangling the search. Trust me on this: it’s usually the custom code you didn’t write that breaks things.
Turns out, I was looking in the wrong place. The “culprit” was actually a core change introduced back in WordPress 6.9 that many devs—myself included at the time—glossed over. WordPress decided to change how the menu search works to improve performance. Instead of doing a heavy full-text search across your titles and content, it now limits the search specifically to the post title.
Understanding the Admin Menu Search Query Shift
The logic behind the change makes sense from a performance standpoint. If you have a site with thousands of posts, searching the entire content body just to find a menu link is overkill. It slows down the admin UI. But for my client, their page was titled “Early Access Campaign,” and the phrase “Black Friday” only appeared in the body text. Because of the new search_columns restriction, the search failed.
As noted in the official dev notes at WordPress.org, the query now explicitly adds array( 'post_title' ) to the search_columns argument. This is great for speed, but terrible for discovery if your naming conventions aren’t airtight. If you’re dealing with a site where the content team relies on keywords within the text to find pages, you’re going to hear about it. Just like that, a “performance upgrade” becomes a workflow bottleneck.
To fix this, you don’t need to hack core. WordPress provided a specific filter for this: wp_ajax_menu_quick_search_args. It allows us to intercept the arguments before the query hits the database. Here’s how I handled it for the client to bring back the old behavior.
/**
* Restore the ability to search by content in the admin menu editor.
*
* @param array $args The query arguments for the menu search.
* @return array Modified arguments.
*/
function bbioon_restore_full_menu_search( $args ) {
// We unset the search_columns to revert to the default full-text behavior
if ( isset( $args['search_columns'] ) ) {
unset( $args['search_columns'] );
}
return $args;
}
add_filter( 'wp_ajax_menu_quick_search_args', 'bbioon_restore_full_menu_search' );When Should You Actually Use This?
Now, I wouldn’t just drop this into every site. If you’re running a massive site with 20k+ posts, leaving the default title-only search is probably the right move for your server’s health. Full-text searches on the wp_posts table can be expensive. But for smaller sites or specific editorial workflows, the admin menu search query needs to be more flexible than just matching the title.
You could even get fancy and only enable this for specific user roles or post types, but for most clients, simply unsetting that restricted column array gets the job done. It’s a clean fix that stays within the WordPress way of doing things.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work without these hidden “gotchas” getting in the way, drop my team a line. We’ve probably seen it before.
Does your team struggle with finding content in the admin, or have you already moved everything to a more modern headless navigation? Let’s talk about it.
Leave a Reply