A good search engine can make all the difference between a happy website visitor … and a frustrated, annoyed lost customer.
Being able to find what you’re looking for is crucial, especially if the site has a large or complicated menu navigation, and most people would prefer to simply type in their query rather than click around and hope they find what they need.
When it comes to WordPress search, there’s a number of options we recommend for a good experience, though usually we’ll use the Relevanssi plugin and tweak the results according to the site’s needs.
If the site features date-based events, we’re often asked to make sure that past events don’t show up in search results for fear of confusing users; this is especially true with recurring events, where the same event happens multiple times on different dates.
We’re big fans of The Events Calendar by Modern Tribe — it’s the most full-featured, easy-to-manage WordPress plugin for events. When we have a website that requires complex events (be they recurring, need a traditional 30 boxes calendar layout, or have associated locations and/or organizers), we use The Events Calendar.
Since each event — and each instance of a recurring event — is treated as its own post, you can imagine that the search results for a popular topic can overflow with events.
In order to hide events that have already occurred from displaying in search results, we can add a filter to make the magic happen.
Here’s the code (with an explanation of how it works after).
function dgtlnk_search_results($query) {
if ( !is_admin() && $query->is_main_query() ) {
if ($query->is_search) {
$meta_query = [
'relation' => 'or',
[
'key' => '_EventEndDate',
'value' => date('Y-m-d').' 00:00:00',
'compare' => '>=',
'type' => 'DATETIME'
],
[
'key' => '_EventStartDate',
'compare' => 'NOT EXISTS',
],
];
$query->set('meta_query', $meta_query );
}
}
}
add_filter('pre_get_posts', 'dgtlnk_search_results');
Simple enough, right?
This function filters the pre_get_posts action, which means it happens after the query object is created, but before the query actually runs. In English, that means it takes the query and adjusts it before any results are output.
We’re running the query only on the front-end of the site (not the admin) and we’re making sure it’s the main query of the page (and not a secondary query). We’re then checking to see if the query is a search query, and if so, we’re making some changes.
In order to filter out past events, we’re looking for two meta keys: “_EventStartDate” and “_EventEndDate”. Working from the bottom up:
You can see we’re comparing the current date/time to the the event’s end date and not to its start date; we’re doing that if there are multi-day events that have started but haven’t ended yet.
This type of filtering can be adjusted as necessary to tweak your search results however necessary.
Have a WordPress or web development question you need help with? Reach out and we’ll do our best to respond.