A quick fix for the impossibility of building new menus on a WordPress site with a large number of pages

I’m working on a theme migration for a WordPress site that as a lot of pages. A lot of pages. 451 pages.

The old version of the site was using page menus, not custom menus, but it was relying on a constellation of abandoned plugins, and that approach just won’t work for the new theme. We need to build custom menus.

The problem is, building a new menu on a WordPress site that has 451 pages is a daunting task. Granted, only 39 of these pages need to go into the main navigation. (A lot of them really should probably be deleted, but that’s the client’s call, not mine.) So, I’m glad I don’t have to wrangle over 400 pages into a menu, but even 39 can be difficult given the shoddy interface WordPress provides for finding pages to add to your menu.

There are three tabs: Most Recent, View All, and Search. Most Recent is useless unless you’re just adding recently created pages to an existing menu. View All is useless because it’s paginated, inside this tiny box, and it lists the pages in an entirely inscrutable order. (OK, it’s not inscrutable. I can scrute it. But just because I understand the logic of how they’re ordered doesn’t mean that order is easy to work with.) And lastly we have Search which seems like the saving grace. But it’s actually the most maddening of the three because of two things:

  1. WordPress search sucks. It doesn’t give extra weight to page titles; it searches the full content. So even if I type in the exact title of the page I want, it’s usually not first in the list. And that’s a problem because‚Ķ

  2. It only returns 10 results. That’s it. Ten. No lazy loading of more, no pagination, nothing. If your page doesn’t come back in the top 10 results, it may as well not exist.

I’d really love to rebuild the internal WordPress search engine to be smarter about weighting titles. Well, OK, no I wouldn’t. That would be a project I would not enjoy. But I would like for it to be done by someone.

Since that’s not likely to happen, at least there’s a way we can modify the search results to change the number of pages returned. I found the solution, as I often do, on StackExchange. But I dislike a few of the answer’s coding conventions, and I wanted to make one specific change for myself, so here’s my version. (You may not like using closures, especially in a scenario like this because it prevents you, or anyone else, from being able to remove this logic elsewhere. If I were writing a public plugin for this, I’d definitely make it a named function, but this should be fine for a custom theme.)

add_action('pre_get_posts', function($query) {
  if (is_admin()) {
    if (isset($_POST['action']) && $_POST['action'] == 'menu-quick-search' && isset($_POST['menu-settings-column-nonce'])) {
      if (is_a($query->query_vars['walker'], 'Walker_Nav_Menu_Checklist')) {
        $query->query_vars['posts_per_page'] = -1;
  return $query;
}, 10, 2);

The important difference between the StackExchange sample and my code is that I changed the results from 30 to -1 which, in the WordPress universe, equals . Fun!

The standard warning is that setting posts_per_page to -1 is inherently risky because it could cause performance problems. But in my testing of this change, it does not appear to be an issue on this site with 451 pages, so I’m guessing it won’t be for you, either.

Now, instead of getting back a paltry ten results, you’ll get all the results that match your search. And the exact page title you typed in should be in there, somewhere.

Resizing and regenerating WordPress upload thumbnails

WordPressFor quite some time, I’ve been wishing the thumbnail images WordPress creates when you upload an image were slightly bigger. The function that generates the thumbnails accepts a maximum dimension as an input parameter, but then the value (a paltry 128 pixels) is hardcoded in the script that calls the function, and there’s no way in the standard WordPress configuration to change the value, other than manually editing the admin script where the call is made.

This is easy enough to do, if you know how to find the block of code in question, but it’s wrong wrong wrong in terms of ongoing WordPress updates: when a new version is released and you update your files, the changes you made will be lost.

So the right way to go about this is with a plug-in, and fortunately there is one. It’s simple and it works. Except for the fact that it doesn’t regenerate any of your existing thumbnails.

Maybe there’s something else out there, but I wasn’t able to find one, so I had to resort to rolling my own.

The script is incredibly rudimentary right now. It’s not a plug-in, it doesn’t interface with WordPress admin at all, setting the file path and dimensions require manually editing variable values in the script, there’s no security, etc. It does seem to work though, which is the most important thing. There were a few bugs earlier on that I believe I’ve squashed, but I can’t guarantee there aren’t others, and given how quickly I put it together this afternoon, with kids screaming and car dealerships calling me every 3 minutes (yeah, that’s another blog post), it’s probably not quite as efficient as it could be. (That’s why I cranked up the max_execution_time and memory_limit values. YMMV depending on how many files you have to process.)

As long as you understand that you’re using it at your own risk, feel free to download the script. In order for it to work it should be placed in your wp-admin directory. And remember, it’s not secured at all, so I recommend uploading it, running it, and then deleting it. (Well, now that I think about it, I’m pretty sure including admin.php does automatically provide standard admin security, but don’t quote me on that.)

If I have the time and if anyone actually cares, I’ll update this and turn it into a proper plug-in with all of the attendant niceties. Otherwise… well… never mind!