Content restrictions with WordPress.com

  • joshheald

    (@joshheald)


    4 days, 6 hours ago

    Hi folks,

    I’ve been trying to use Members to set up restricted pages on my WordPress.com blog. It restricts the posts just fine when I select a role or two in the post’s settings, meaning that logged out users see “Sorry, but you do not have permission to view this content.”

    However, when I log in with a different user who has the correct permission, the post still shows the blocked comment, not the content.

    The same even happens when I grant restrict_content to the role, or use a different user with Administrator role.

    I suspected caching, however, if I remove the role requirements from the post it will immediately load again for the user… and using a cache-busting query string didn’t change the result either.

    I might have configured something wrong, but I can’t see many more levers to pull in my debugging, so thought I’d check whether you were aware of this issue when running on WordPress.com?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Hesham Gaber

    (@heshamgaber)

    4 days, 5 hours ago

    Hi @joshheald,

    That combination shouldn’t be possible from Members’ side. The access check passes automatically for the post author, for anyone with restrict_content, and for anyone who can edit the post — so an Administrator hitting the block message means the page is almost certainly being rendered without your login attached. Members sees user ID 0 and blocks correctly for that context.

    Quickest way to confirm: load the restricted page while logged in as the admin and check whether the admin toolbar appears at the top. If it doesn’t, you’re being served as a logged-out visitor and the restriction result is expected.

    Your two caching tests don’t quite rule caching out, by the way. Removing the role meta saves the post, which purges the cached copy, and WordPress.com’s edge cache generally ignores arbitrary query strings — so neither would have registered as a cache miss.

    Let us know how it goes.

    Thanks!

    Thread Starter joshheald

    (@joshheald)

    3 days, 7 hours ago

    Thanks for the quick reply @heshamgaber.

    You’re quite right; after accepting the invitation for one of my test users, I was logged in to WordPress.com and confirmed as a member of the site with the correct role, however, that didn’t translate to being logged in to my site until I went to /wp-login.php.

    I did also disable caching in WordPress.com just to fully rule that out, though memcached couldn’t be fully disabled.

    I also notice that the users with required roles see the post content in WordPress.com Reader, while other users only see the restricted notice, which is a good detail. Is that because of the REST API protection you’ve added?

    Edit — it seems inconsistent whether the reader shows content or the restriction message to subscribers who don’t have the required roles, so I’m not sure that’s actually working after all.

    • This reply was modified 3 days, 7 hours ago by joshheald.
    Plugin Support Hesham Gaber

    (@heshamgaber)

    2 days, 7 hours ago

    Hi @joshheald,

    Glad that pinned it down — WordPress.com account membership and a login session on the site itself are two different things, so that matches.

    On the Reader: the REST protection is real, but it’s narrower than what you’re seeing there. Members filters your site’s own REST API — restricted posts are excluded from /wp-json/wp/v2/… collections, and single-post reads are denied for users who can’t view them. That check runs against the viewer’s session on your site.

    The Reader isn’t hitting that API. It’s served from the copy WordPress.com syncs and caches from your site, so Members isn’t in the request path when the Reader renders a post. What you’re seeing is whichever version happened to get captured, which is exactly why it looks inconsistent between users and over time.

    So I wouldn’t treat Reader visibility as part of the restriction either way. To test the surface Members actually controls, load /wp-json/wp/v2/posts?slug=your-post-slug on your own domain — logged out, then as each test user — and check whether the post is returned at all.

    If the Reader is showing full restricted content to people who shouldn’t have it, that’s worth raising with WordPress.com support, since the lever for that (limiting what gets synced) sits on their side rather than in Members.

    Regards,

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

You must be logged in to reply to this topic.