Rafał Groń

One practical note while this sits in the queue. If you want to see what the search actually matched, your dashboard has a “View results” option on each query in the search history. It replays the query and shows the results in the order the engine returned them, grouped into exact and related matches.

That is not what you asked for. It helps you rather than your members, and it does not put the passage on the results page. But while you are evaluating, it does let you check that the right lesson comes back for a given member question, without having to click through each result.

Taking you up on the offer to test. I will come back to you when there is something worth looking at.

Hi Jon,

Closing the loop: it shipped. The queryra_result_ids filter is live under the name you proposed, so your interim solution now sits on a supported hook instead of plugin internals and will survive updates. The post__not_in subtraction is in as well, so a scope another plugin sets is honoured rather than dropped. You’re in the changelog for the hook.

Marking this resolved. If anything moves once your members are really leaning on it, a fresh thread and I’m on it.

Thanks again, Jon — genuinely one of the best threads I’ve had here.

Rafał

Hi Jon,

This is the most useful bug report I have had on this plugin, and you solved your own problem while I was still scoping mine. Thank you — genuinely.

Taking your points in order.

On the setting I suggested checking — you are right and my advice was wrong

I tested the MemberPress integration against Rules and membership groups, not against the Courses add-on’s course-level access, and I extrapolated from that. Worse, the snippet approach I pointed you at could not have worked even where Rules are used, for exactly the reason you gave: WP_Query ignores post__not_in once post__in is set, and this plugin sets post__in.

That is not just a bad suggestion, it is a regression this plugin causes. Any site following MemberPress’s published guidance to hide protected content from search silently loses that behaviour the moment Queryra is active. So I am not going to document it as a caveat — I am fixing it: before the ID list is applied, anything another plugin has placed in post__not_in gets subtracted from it. That makes the existing pattern work again, for MemberPress and for anything else using it, with no configuration.

On your filter hook request — yes, and it is going in

$ids = apply_filters( ‘queryra_result_ids’, $ids, $search_term );

Exactly as you wrote it, name included. It costs nothing when unused, and it turns your solution from something that depends on my internals into something that survives my refactors. It also happens to answer a second open request from another site that needs faceted filtering over the same list, which is a good sign that this is the right level to expose.

You will be credited for it in the changelog.

On your Rules-versus-Courses finding

This is the part that changes my design, so I want to be explicit that it landed. My working plan was to tag each synced record with the MemberPress rule protecting it. Your setup has no such rules — access lives in the Courses add-on’s own per-course settings, lessons inherit from the parent course, and MeprRule::is_locked() does not evaluate it. That plan would have shipped and missed sites like yours entirely.

You found that by building it. I had it in my spec as the number one open question. That is a week of my time you just saved, and it is why the hook is the right first move: the site knows its own access model, and I should not be guessing at five different ones.

On the staging copy

Yes, and I will take you up on it — but for the deeper version, not for this. The hook is small enough that I do not need to test it against a real membership setup. When I build proper scope filtering into the query itself, so that filtering happens before ranking rather than after it, that is when a real five-membership site earns its keep. I will come back to you then, with test accounts as you suggested.

One thing worth checking on your own index

A common one on membership sites: the index quietly picks up plumbing pages — checkout, account, login, and the default pages every fresh WordPress install ships with. They carry no real content, so they tend to surface on questions your actual material cannot answer. A visitor asking something like how to get in touch can end up looking at a login page instead of an honest no result.

Worth a scan of your Records list. Deleting a record removes it from the search index immediately and needs no re-sync, so it is a minute of work and you see the difference on the very next query. Skipping obvious plumbing at sync time is on my list, but this gets you there today.

Thanks again. This thread is going to be more useful to the next person than anything I could have written on my own.

Rafał

Hi Joe,

Thanks for laying out the full stack, that helps.

Let me split this into what I can answer definitively and what I cannot.

CPTs and Meta Box fields: yes. Queryra indexes custom post types, and it indexes
title, content, excerpt, text-type custom fields and taxonomies, so your company
records and the Meta Box text fields on them are searchable. Meta Box documents
the compatibility on their side as well. You can also choose which post types are
searchable, so search can be scoped to the company CPT.

FacetWP: I have not tested that combination, so I am not going to guess at it.

Here is what decides it, and it is worth knowing either way. Queryra hooks into the
standard WordPress search request and replaces the result set for that query.
FacetWP maintains its own index and applies its filtering to the query on the page.
So the question is whether, on your results page, FacetWP filters within the set
Queryra returned, or rebuilds its own query from scratch. In the first case,
faceting on top of semantic results should work. In the second, the facets would
work but the results underneath would no longer be the semantic ones.

The same question decides whether the ranking survives, because semantic search
puts most of its value in the order things come back in, and anything that re-sorts
loses that.

Now the practical part: you already have this stack running and I do not. That means
you can get a definitive answer today, on your actual configuration, faster than I
could by rebuilding an approximation of it. Two steps, about ten minutes:

1. Before touching any facet, run a plain search by typing this straight into the
   address bar: yoursite.com/?s=some+natural+phrase. That skips the theme and the
   builder and goes to the path Queryra hooks into. Tell me whether those results
   look right. This also settles Bricks on its own, which is still marked
   “verification in progress” in our docs. I wrote up why this exact test matters
   here: https://queryra.com/blog/wordpress-search-plugin-not-working-theme-override
2. Then apply one facet and send me the resulting URL plus what you see. Did the set
   shrink sensibly, or turn into something else? Did the order change?

With those two things I can tell you what is actually happening and what to change.
Without them, either of us is guessing.

One more question, because it might make this much simpler: is the filtering meant
to happen on the search results page itself, or on a separate directory archive that
is not a search page? If the facets live on the archive and search is its own
surface, the two never collide and there is nothing to reconcile.

I do work through compatibility testing for other plugins, but the queue is long and
honest timing on FacetWP from my side would be weeks. The route above gets you an
answer this week.

Rafał