Title: Rafał Groń's Replies | WordPress.org

---

# Rafał Groń

  [  ](https://wordpress.org/support/users/aisearch/)

 *   [Profile](https://wordpress.org/support/users/aisearch/)
 *   [Topics Started](https://wordpress.org/support/users/aisearch/topics/)
 *   [Replies Created](https://wordpress.org/support/users/aisearch/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/aisearch/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/aisearch/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/aisearch/engagements/)
 *   [Favorites](https://wordpress.org/support/users/aisearch/favorites/)

 Search replies:

## Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Filter Support](https://wordpress.org/support/topic/filter-support-4/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [1 week ago](https://wordpress.org/support/topic/filter-support-4/#post-18984885)
 * Hi Joe,
 * Short follow-up, because the question I left you with now answers itself.
 * Version 1.5.3 adds a **Search filters** section under Queryra → Support. It lists
   the filter parameters for your site with the real values read from your own catalogue
   next to each one, and where a taxonomy is empty it says so. So rather than working
   out which of your company attributes are taxonomies and which are Meta Box fields,
   you can open that panel and see exactly what is filterable on your directory.
 * One rule that catches people out: the value is the term name, not the slug. `
   Legal%20Services` works, `legal-services` returns nothing.
 * Worked examples and the rest of the rules: [https://queryra.com/blog/…](https://queryra.com/blog/filter-ai-search-results-category-taxonomy)
 * Rafał
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] show the matched passage as the result excerpt](https://wordpress.org/support/topic/show-the-matched-passage-as-the-result-excerpt/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [1 week ago](https://wordpress.org/support/topic/show-the-matched-passage-as-the-result-excerpt/#post-18984267)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] show the matched passage as the result excerpt](https://wordpress.org/support/topic/show-the-matched-passage-as-the-result-excerpt/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [1 week, 1 day ago](https://wordpress.org/support/topic/show-the-matched-passage-as-the-result-excerpt/#post-18983293)
 * Thanks for writing this up properly, and for the second half in particular.
 * You are right that the results page currently looks the same as it did before.
   The matching happens, but the page gives the member no way to see that it happened.
   I would not have put it as sharply as you did.
 * On the excerpt itself I would rather be straight with you than optimistic. It
   is a much bigger change than it looks from the outside, and there is work in 
   the core search that has to come first. I am not going to promise it or put a
   date on it.
 * What I will say is that you are the first person to put into words why it matters,
   and requests like this are how I work out what gets built. Noted, and thank you
   for the offer to test.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Memberpress results filter](https://wordpress.org/support/topic/memberpress-results-filter/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [2 weeks, 6 days ago](https://wordpress.org/support/topic/memberpress-results-filter/#post-18973001)
 * 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ł
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Filter Support](https://wordpress.org/support/topic/filter-support-4/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [2 weeks, 6 days ago](https://wordpress.org/support/topic/filter-support-4/#post-18972996)
 * Hi Joe,
 * Following up because the latest version changes the answer for you.
 * Queryra can now filter its own search results while keeping the semantic order
   intact — you pass a filter alongside the query and it narrows the result set 
   before the ranking is finalised, so faceting no longer means losing the semantic
   sort. That’s the thing you were worried about, and it’s the cleaner path than
   having FacetWP re-filter Queryra’s output.
 * One important scope note, because it decides whether this fits your directory.
   It filters by taxonomies and by category/tag/brand. Meta Box **text** fields 
   are searchable but are not yet available as filters. So the deciding question
   is: are the company attributes people filter on stored as taxonomies, or as Meta
   Box custom fields? If taxonomies — this works today. If custom fields — that’s
   the part not yet covered, and worth knowing before you build around it.
 * For FacetWP specifically: your developer can use the `queryra_result_ids` hook
   to intersect FacetWP’s selection with Queryra’s results in PHP, which keeps the
   ranking. The two-step test I mentioned still gives you the definitive answer 
   for your exact stack.
 * Marking this resolved for now since the capability is in place — but tell me 
   which way your filters are stored and I’m happy to go deeper, or open a new thread
   anytime.
 * Rafał
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Memberpress results filter](https://wordpress.org/support/topic/memberpress-results-filter/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [3 weeks ago](https://wordpress.org/support/topic/memberpress-results-filter/#post-18972142)
 * 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 wrongI 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 findingThis 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 copyYes, 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 indexA 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ł
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Memberpress results filter](https://wordpress.org/support/topic/memberpress-results-filter/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [3 weeks ago](https://wordpress.org/support/topic/memberpress-results-filter/#post-18971681)
 * Hi Jonathan,
   Thanks for writing this up so precisely. The approach you outlined—
   tagging each record with the rule that protects it at sync time, then passing
   the user’s active memberships with the query and filtering server-side — is exactly
   the right shape, and it tells me you know how WordPress fits together. That is
   the design I would build.Let me take the listing wording first, because you are
   right to raise it.What that line means today, and where it is impreciseQueryra
   returns a ranked list of post IDs along with display metadata such as titles 
   and URLs, and the plugin passes only the IDs on to WordPress. The body of a lesson
   is not part of that response and is never served by Queryra. WordPress and MemberPress
   then handle rendering and the access check, so a member who is not entitled to
   a lesson cannot read it through search any more than they could by guessing the
   URL.What does appear is the title and excerpt in the results list, which is the
   same thing WordPress core search does with protected content. Our documentation
   describes it that way, but the one-line summary on the plugin listing compresses
   it into something that reads like Queryra enforces access itself. That was my
   wording and I have reworded it — the listing now says it works alongside MemberPress
   access rules.Why the default is to show everythingOn most sites running Queryra—
   shops and content libraries — everything in the index is meant to be discoverable,
   and surfacing something adjacent to what a visitor searched for is the point 
   rather than a defect. Site search is one of the highest-intent moments on a commerce
   site: someone types what they actually want, and showing them a related item 
   they had not found on their own is where a large part of its value comes from.
   That is the behaviour the default is tuned for.Why your case is different, and
   legitimateYours inverts that assumption. Five parallel courses, one purchased
   at a time, where content from another pathway is not merely unavailable but often
   wrong for that member’s situation. Recommending it is not an upsell, it is a 
   source of incorrect expectations — and your point that it generates support requests
   rather than interest is the part that convinced me. That is a filtering problem,
   not a presentation problem, and you are right that labelling the results would
   not fix it at your ratio of content.Where it standsScoped filtering is not available
   today. Yours is the second request this month for the same underlying capability—
   the other is a company directory that needs faceted filtering over the same mechanism—
   so it is on the roadmap as one generic feature rather than a MemberPress-specific
   one, which is also the only way it stays maintainable over time. I am not going
   to give you a date I cannot keep.One thing worth checking before thatIf you have
   MemberPress set to hide unauthorised content from search results and archives,
   and results still cross courses, tell me — that would point at something on my
   side that I can fix quickly, and it would be a far shorter path than the full
   feature. If you have not, it is worth trying: it may get you most of what you
   need today.On the staging copyYes, please — ideally with test accounts rather
   than real member data, so there is nothing sensitive in play. When I build this,
   a real five-membership setup is exactly what it needs to be tested against, and
   I would rather validate against yours than an approximation of it.How the two
   plugins divide responsibility today is written up here: [https://queryra.com/docs/memberpress-integration](https://queryra.com/docs/memberpress-integration)—
   I will update that page when this changes.Rafał
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[AI Search for WooCommerce – Semantic Search] Filter Support](https://wordpress.org/support/topic/filter-support-4/)
 *  Plugin Contributor [Rafał Groń](https://wordpress.org/support/users/aisearch/)
 * (@aisearch)
 * [3 weeks, 2 days ago](https://wordpress.org/support/topic/filter-support-4/#post-18970140)
 * 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 companyrecords
   and the Meta Box text fields on them are searchable. Meta Box documentsthe compatibility
   on their side as well. You can also choose which post types aresearchable, 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 setQueryra 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
   wouldwork 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-
   sortsloses 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 Icould 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 thebuilder
       and goes to the path Queryra hooks into. Tell me whether those resultslook 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 mattershere: [https://queryra.com/blog/wordpress-search-plugin-not-working-theme-override](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 thatis not a search page? If the facets live on the archive and search
   is its ownsurface, 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 ananswer this week.
 * Rafał

Viewing 8 replies - 1 through 8 (of 8 total)