Title: jonnwalker's Replies | WordPress.org

---

# jonnwalker

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

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

 Search replies:

## Forum Replies Created

Viewing 1 replies (of 1 total)

 *   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/)
 *  Thread Starter [jonnwalker](https://wordpress.org/support/users/jonnwalker/)
 * (@jonnwalker)
 * [3 weeks, 1 day ago](https://wordpress.org/support/topic/memberpress-results-filter/#post-18972014)
 * Hi Rafał,
 * Thanks for the detailed reply. An update, plus two findings that should be useful
   when you build the feature.
 * First, on the setting you suggested checking: MemberPress doesn’t actually have
   a native “hide unauthorised content from search results” option — hiding from
   search is done via a code snippet they publish, which hooks pre_get_posts with
   post__not_in. That snippet can’t work alongside Queryra anyway, since WP_Query
   ignores post__not_in when post__in is set.
 * I’ve solved my case in the meantime at the WP_Query level: a pre_get_posts hook
   at priority 20 (after your priority-10 override) that intersects the post__in
   list against the current user’s access, plus a the_posts fallback for when the
   plugin falls back to native search. Since your transient cache stores raw IDs
   keyed by search term and my filter runs after cache retrieval, per-user filtering
   works fine over the shared cache. Members now see only their own course’s lessons,
   and it’s been working well in testing.
 * Second finding, and this one matters for your roadmap design: my courses aren’t
   protected by entries in MemberPress → Rules at all. Access is set per-course 
   in the MemberPress Courses add-on’s own course settings (the Access column on
   the Courses screen), and lessons inherit from their parent course. I found MeprRule::
   is_locked() didn’t evaluate correctly against that setup — I ended up resolving
   each lesson to its parent course and checking membership against that. So if 
   the planned feature tags each synced record with “the MemberPress rule that protects
   it,” it would miss sites like mine entirely. You’d want to handle the Courses
   add-on’s course-level access as well as Rules, and resolve lessons/quizzes up
   to their course.
 * One small request that would make interim solutions like mine robust: an apply_filters()
   on the ID list before you set post__in — something like $ids = apply_filters(‘
   queryra_result_ids’, $ids, $search_term ); That gives site owners a supported
   hook that survives refactors, and costs nothing when unused.
 * The staging copy offer stands — five memberships mapped one-to-one to five courses,
   all access via course settings rather than Rules, so it’s exactly the setup your
   feature needs testing against. Happy to set it up with test accounts whenever
   you’re ready.
 * Thanks again for engaging with this so thoroughly.
 * Jon

Viewing 1 replies (of 1 total)