All notable changes to LH Membership are documented here. This entry is canonical and append-only.
2.71 2026-08-18
Added a sixth lh-competitions-family integration for restrict, this time into lh-buddypress-check-ins: new method add_restricted_to_check_ins_event_statuses() hooks the new lh_bp_check_ins_event_post_status filter (lh-buddypress-check-ins 3.03) so restricted events are included in the check-ins plugin's next-event and listing shortcodes for users who can view them (current_user_can_view() — same gated pattern as round-nav, event-listing, and game-edit-event). This closes the root cause of lh_bp_check_ins_display_next surfacing the wrong event on Princes Park Touch: the shortcode's hardcoded post_status => 'publish' was skipping every restricted-status Wednesday-night round in favour of whichever publish-status round happened to be furthest in the future.
2.69 2026-08-17
Added a filterable capability-based exemption from the member-onboarding BuddyPress gate: LH_Membership_private_buddypress_class::non_member_requires_access() now returns false immediately for any user with the promote_users capability (default, filterable via lh_membership_return_gate_exempt_capability), regardless of their own membership/approval status. New method return_gate_exempt_capability() added alongside the class's other filterable whitelists.
2.68 2026-08-03
Added a sixth restrict integration, this time into lh-buddypress-log-entry rather than lh-competitions: hooks the new lh_bp_log_entry_return_event_post_statuses filter (lh-buddypress-log-entry 1.03) so restricted events are included in the log entry form's event lookup, the open/closed shortcodes, and the past-events listing. Per Peter's explicit instruction, this integration is unconditional — not gated by current_user_can_view() — same rationale as the standings integration: it's just adding restrict to the set of statuses queried, not deciding what a particular viewer gets to see.
2.67 2026-07-18
Added a fifth lh-competitions integration for restrict: hooks the new lh_comps_latest_scoresheet_event_query_args filter, so the "Latest {Night} Scoresheet" dynamic menu item can resolve to a restricted event for users who can view them (current_user_can_view() — same gated pattern as round-nav, event-listing, and game-edit-event; unlike standings, which is deliberately unconditional). Default query status ('publish', a string rather than an array here) is normalised to an array before appending restrict.
2.66 2026-07-18
Added a fourth lh-competitions integration for restrict: hooks the new lh_comps_standings_event_query_args filter (lh-competitions 1.80, applied without a version bump per Peter's 2026-07-21 instruction — see that plugin's own changelog) so events with status restrict are included in standings table calculations alongside publish. Unlike the other three restrict integrations (round-nav, event-listing, game-edit-event), this one is deliberately unconditional — not gated by current_user_can_view() — since the standings table is a computed aggregate (wins/points) rather than per-viewer visible content; gating which events feed into the calculation by the current viewer's access would make the resulting numbers inconsistent depending on who's looking. Flagged this deviation from the established gated pattern to Peter before implementing; proceeded on this assumption pending confirmation.
2.65 2026-07-18
Added a third lh-competitions integration for restrict, matching the existing round-nav and event-listing ones: hooks the new lh_comps_game_edit_event_post_status filter (lh-competitions v1.79+) so restricted events are selectable in the Event dropdown on the game edit screen's Game Data meta box, for users who can view restricted content (self::current_user_can_view() — same check as the other two integrations). Not extended to confidential/logged_in, per the standing decision to keep this integration restrict-only.
2.64 2026-07-18
Reworded the BuddyPress access-denied flash message. Since the person only sees it after being redirected to their own profile, "This area is only visible to current members" reads as if it's describing the page they just landed on. Changed to "You tried to access an area that is only visible to current members" to make clear it's referring to where they came from.
2.63 2026-07-18
Fixed 2.62's BuddyPress no-access page: the title correctly changed to "No Access" but the actual screen content (groups directory, members directory, etc.) kept rendering underneath it. Root cause: BuddyPress doesn't render through WordPress's normal template/404 flow at all — it has its own screen-rendering system that runs regardless of is_404() or the 404_the_content filter. LH_Membership_access_control_class::show_no_access() only ever affects the page