Anonymous users can always spectate

[kevinB]

The spectate capability is not useful because anonymous users have it implicitly. Blocked users lose all forum access (including viewing) but can again read public forums after logging out. In addition to this nonsensical anonymous > blocked behavior, the inconsistent handing of the spectate cap means it cannot be withheld from anonymous users nor verified via allcaps or current_user_can().

This could be remedied by including the spectate capability in the blocked role and mapping that role to anonymous users. The role map and caps could of course be filtered for sites that need to prevent both anon and blocked users from spectating (or need blocked users to have some additional access beyond anonymous).

[johnjamesjacoby]

Maybe the problem is verbiage: blocked VS banned?

Either way, once you allow anonymous posting, the concept of blocking/banning registered user accounts is pretty pointless.

[kevinB]

The issue is not anonymous posting, but viewing. Anonymous users can always read any public forum, while blocked users cannot (due to lack of spectate capability).

How is the spectate capability meaningful in this arrangement?

[johnjamesjacoby]

Replying to kevinB:

How is the spectate capability meaningful in this arrangement?

The idea is to send a message to a registered user that they are no longer welcome in your community, by blocking them from reading and writing to your forums. Sure, they can just log out, and if your forums are public (as they are by default) then that user will be able to read the forums again; if you enable anonymous posting, anyone is free to post whatever they like, registered or not.

I don't consider this a bug, I consider it a feature of the "Blocked" role. Closing as wontfix, but happy to keep discussing here. If I'm misunderstanding the issue, or there's a more logical capability arrangement worth exploring, we can figure that out here.

[kevinB]

Thanks for explaining the reasoning for spectate blocking. It still seems a little quirky to me but, like you said, it does send a message.

Aside from that functional issue, what do you think about handling the spectate cap as a normal capability by adding it to $user->allcaps for anonymous users and then making bbp_forum_enforce_blocked() call current_user_can('spectate') regardless of login? That way plugins could check for or modify the anon user's spectate access in the normal ways.

[johnjamesjacoby]

The problem with that approach is there is no user to attach capabilities to if you're anonymous. Registered users with no roles are granted the 'exist' capability, but that's it. Since anonymous users have no entry in the database, and only have comment cookies, there's no persistence we can trust.

[kevinB]

How about just appending the allcaps array dynamically in bbp_set_current_user_default_role():

if ( ! is_user_logged_in() ) {
   $bbp = bbpress();
   $bbp->current_user->allcaps['spectate'] = true;
   return;
}

I don't see that "hardcode" as being any worse than the implicit hardcode that's done in bbp_forum_enforce_blocked() now. At least then current_user_can() would be consistent and plugins could hook into bbp_setup_current_user late to remove the capability.

Mapping a role to anonymous users / non-members would be even better, but a more elaborate change.

[johnjamesjacoby]

It seems like it could work, though it's a bit unorthodox. I'm not sure since when, but the $current_user global is set to a WP_User object, even for anonymous users. So like you say, we could safely give them a role on the site.

Worth tinkering with.

[johnjamesjacoby]

The only other issue I see with anonymous users is page caching. Since most caching happens for anonymous users, it's possible that bbPress won't even have a chance to manipulate the $current_user. Not sure what exactly a work-around would be there.

[kevinB]

It would be nice if WP had a request_cache_flush() function that fired a corresponding action. Then caching plugins (regardless of their implementation) could be formally encouraged to implement the action as a WP 3.6 (and bbPress 2.3) compat issue.

[netweb]

Putting a milestone back in the ticket