Calling WP_User::add_cap does not flush capabilities

[rmccue]

After calling $user->add_cap(), both $user->get_role_caps() and $user->update_user_level_from_caps() need to be called to update $user->allcaps. Ditto $user->remove_cap().

Both $user->add_role() and $user->remove_role() do this automatically.

Steps to reproduce:

$user = wp_get_current_user();
$user->add_cap('some_test_cap');
$user->has_cap('some_test_cap');

// -> false

Possibly related to #19747.

[jdgrimes]

Related: #10201

I'm surprised that (what seems like) such a simple bug hasn't received any attention. However, given #10201, this could one day be moot.

[rachelbaker]

patch with unit test

[rachelbaker]

Related #19747

[wonderboymusic]

In 31190:

In WP_User, ->get_role_caps() and ->update_user_level_from_caps() must be called inside ->add_cap() and ->remove_cap() after updating user meta. ->has_cap() checks are currently failing directly after calling ->add_cap().

Adds unit test.

Props rachelbaker.
Fixes #28374.

[lgladdy]

#19747 was marked as a duplicate.

[rmccue]

Found another instance of this one: adding a cap to a role that the current user has. Requires a page reload for it to kick in.

Not sure how to get around that; maybe allcaps needs to be deprecated and replaced with a __get accessor instead?

[pikamander2]

This appears to still be an issue, at least in 5.8.

I was facing the exact same problem as @lgladdy where my custom role wasn't receiving the capability that I added to it via add_cap().

His blog post (​https://stormconsultancy.co.uk/blog/storm-news/custom-roles-in-wordpress-not-appearing-in-author-lists/) mentioned changing their role to something else and back as a workaround, but instead of trying that I just deleted the user and recreated them, at which point they had the new capability.

Is it possible that there was a regression here at some point?

I see that 5.9 is going to be fixing a semi-related longstanding issue (https://core.trac.wordpress.org/ticket/16841), so I'd be curious to know if that happens to fix it on its own.

[pikamander2]

I just tried @lgladdy's suggested workaround (changing their role to something else and back) on another affected account and that also fixed it, so it definitely seems like the original bug is still around.

For reference, I'm on WordPress 5.8.2.