Parse Query Variables in the WP Query Object

“The search results are not displaying correctly on my phone.” They extended their phone to me so I could take a look and confirm the results looked awkward. Instinctively I ran the search on my laptop and the results displayed perfectly as intended. “Well that’s not right,” I commented. Time to troubleshoot.

This was a typical WordPress application that I’d inherited some 10 years ago. Even back then it was obvious the previous developer was primarily concerned with making the final product look good and paid little attention to the code itself or how it was generated. But we shoulder the work and press on.

In the case of the “Strange Search Results Layout” the problem did not lie with CSS as I’d initially thought. No wayward styles or misinterpreted media queries here. Digging into the code I quickly realized that there were actually 2 search forms: 1 for narrower screens (e.g. mobile phones) and 1 for wider ones (e.g. laptops). I let out a heavy sigh as I realized the problem: the search form on narrower screens was not sending all the data that WordPress needed to generate the results. I quickly tested my theory by appending the necessary data to the live code and to no one’s surprise the correct layout appeared.

Unfortunately adding the necessary data to the search form wasn’t as straight-forward as I’d hoped. The previous developer had used a third-party plugin to generate a mobile menu that was the craze back then. For convenience, the plugin also displayed search bar after the mobile menu. The previous developer probably thought they’d killed 2 birds with 1 stone.

What made things difficult was that the plugin did not provide any way for us to add the required data short of editing the code itself (which is an absolute last resort). The search form was generated by JavaScript meaning even if we wanted to write our own code to inject the data we would first need to poll the source to make sure the form was already present (and that opened a host of performance-related questions I did not want to deal with).

We decided to intercept the search request and inject the data before WordPress performs the actual search. This involved using the WP_Query Object and setting the appropriate query variables (not to be confused with the WP_Query Object itself). Generally straight forward but what we did not realize (because it was poorly documented) was that you also need to call parse_query_vars() for the whole thing to work.

Here is a modified version of the code we used:

function adjust_search( $query ) {

  if ( $query->is_main_query()
    && $query->is_search()
    && !$query->get( 'MISSING_DATA' ) ) {

    $query->set( 'MISSING_DATA', 'DATA_VALUE' );
    $query->parse_query_vars();
    }
}

add_action( 'pre_get_posts', 'adjust_search' );

What if this hadn’t worked? Our fall-back plan was to use a server-level rewrite rule. The issue with this method was that it would have to be re-applied if we ever migrated the application to another host.