To vote or comment, enter your email and we'll send a magic link


SearchWP compatibility improvement for search queries changed with pre_get_posts()


FacetWP is is not functioning properly in combination with SearchWP, when the main query for the search results page uses pre_get_posts() to filter out certain posts.

The retrieved posts on a search page DO reflect the filtered posts, also when using facets. But the Facets themselves (and their counts) act like the pre_get_posts() is not there.

For example I use pre_get_posts() to filter out Events (Custom post type Events) that are in the past, using a custom event date field. This works great for every query where this happens. It works with normal WP Search and with SearchWP.

But when using Facetwp facets on the search result page, the filters go wrong.

The cause is in Facetwp > integrations > searchwp > searchwp.php, where the original WP query is killed and a new fresh new \SWP_Query is created.

There is a workaround: to double all filtering done with pre_get_posts() in a searchWP hook: https://searchwp.com/documentation/hooks/searchwps-wp_query-args/

It works, but it would be great is the search wp integration just works and takes any adaptations to the search query into account.

I suspect this happens more often but is not noticed, because the retrieved posts themselves are correct, only the facets (and their counts) go wrong.

2 years ago

Comments (5)

What priority was your pre_get_posts hook running at? The default 10?

2 years ago

I tried different priorities. Now they are at 100, but nothing works. I think I tracked down the cause in the searchwp integration file of facetwp. See my string of support emails with Jenny from 26 july - 4 august where I documented this as a bug.

2 years ago

Here's your support reply (for context: https://d.pr/n/knE0Iq)

This is a tricky one! The reason why we don't just grab SearchWP's query is because it only fetches one page of results, and it loads entire post objects.

We run a separate query because we need unpaginated results (to generate accurate facets / counts), and we load only post IDs to save resources.

I think you're right about that SWP hook being your best bet. I suppose it's possible for FacetWP to first check for other URL arguments (e.g. post_type) before passing them into SWP.

2 years ago

ah ok, that explains the reasoning. But passing on the original query arguments to the new SWP query, would that not work? I my case meta_query, but also post__in, post__not_in, post_type etc. The extra swp hook works okay for me. But generally, an altered main query is not really that exotic I guess for users with FacetWP + SearchWP (many will have excluded pages for example), but not everybody will notice their facets + counts are off, and only on the search page.

2 years ago

Email sent 😇

2 years ago