Bug: Member-level users get 404 on protected Events pages

[beginanew]

Environment: Hostinger shared hosting (LiteSpeed, PHP 8.3), WordPress 7.0.3, Astra 4.13.9, Kadence Blocks.

Plugins: Simple Membership 4.7.9 + official “SWPM Custom Post Type Protection” add-on 1.1, The Events Calendar 6.17.2, LiteSpeed Cache 7.9, Wordfence 9.0.0.

Bug?:
Admin account: Events archive and individual event pages work correctly.
Logged-in “Member”-level account (correct level, matches the event’s protection setting exactly): gets a raw “page doesn’t seem to exist” 404 on both /events/ and any individual protected event.
Logged-out/anonymous visitor on the same protected event: correctly shown Simple Membership’s “please log in” message — better behavior than a logged-in restricted member gets.

So access breaks specifically for authenticated non-admin roles, not admins, and not anonymous visitors.

Ruled out:
Membership level mismatch — confirmed exact match between event protection setting and member’s assigned level.
Events Calendar’s Month View Cache conflict (known issue) — disabled, no change.
Custom-post-type protection add-on — installed/active, has no separate settings to configure.
Caching — purged at plugin level and host level, no change.
Wordfence — confirmed not involved; reproduces identically with Wordfence fully cleared and member session confirmed active in the admin bar.

Ask:
Why does a correctly-permissioned logged-in member get a 404 instead of content or an access-denied message, specifically on tribe_events post type pages? Looking for a fix or supported workaround.

[The Assurer]

this looks like a genuine tribe_events/The Events Calendar CPT protection compatibility edge case. The fact that anonymous users receive the SWPM protection message while an authorized logged-in member receives a 404 is actually a strong indication that the failure is occurring in the authenticated CPT request path, rather than in the membership-level comparison itself.

The official SWPM documentation acknowledges that CPT plugins which use non-standard hooks can require the enhanced CPT protection mechanism, and SWPM’s own support history specifically identifies The Events Calendar as having non-standard calendar pages that don’t behave like ordinary WordPress Pages/Posts.

I would not call this a normal or expected result for a correctly authorized member. I would treat it as something that needs either a reproducible compatibility fix or a different protection mechanism.

The developers will be informed.

[beginanew]

Thank you for looking into this and confirming it’s a compatibility issue rather than something on my end — I appreciate you escalating it to the developers.

A couple of follow-up questions while I wait on a fix:

Do you have a rough sense of timeline for compatibility fixes like this one?
Is there a recommended workaround I could use in the meantime — for example, protecting a landing/gate page instead of individual events — so my members aren’t locked out while this gets resolved?

Happy to provide any additional diagnostic info if it helps (site details, error logs, etc.). Thanks again for the quick response.

[admin]

Hi, Instead of the Custom Post Protection addon, please try the following full page protection one. Does it work better with this tribe events post type?
https://simple-membership-plugin.com/full-page-protection-addon-simple-membership/

[beginanew]

I tried the Full Page Protection add-on instead, with “Handle Custom Post Type Protection” enabled (and the previous Custom Post Type Protection add-on deactivated to keep it a clean test). Same result as before — a logged-in member with the correct access level still gets “This page doesn’t seem to exist” on both the events archive and individual protected events. No change in behavior between the two add-ons.

Is there a debug/diagnostic mode I can enable, or any other angle worth trying?

[admin]

Thanks for the detailed testing.

Worth clearing up first: our plugin never returns a 404. Core protection replaces the post content with the protection message, and the Full Page Protection addon replaces the page output or redirects. Neither sets a 404 status anywhere. So the “page doesn’t seem to exist” result means WordPress is resolving that request as not-found before our access check runs, which is why switching addons changed nothing.

The quickest way to confirm this: deactivate Simple Membership and both addons entirely, log in as that member’s WordPress user, and visit /events/ and one event. If you still get the 404, our plugin is not involved.

Two other things to check while you are there:

1) The anonymous test may have been served from LiteSpeed’s cache rather than PHP. Retest anonymously with ?nocache=1 on the end of the URL, or with LiteSpeed Cache deactivated. If it 404s then too, the behavior is the same for all non-admin visitors.

2) Confirm the event’s Visibility is Public, not Private. Private posts show fine for admins but 404 for subscriber level users, which matches what you are seeing.

Let me know how the deactivation test goes and we will take it from there.

[Author]

Posts