Closed matt-h closed 4 years ago
Hi @matt-h
Thanks for the proposed solution! Although the method you suggest makes sense, we'll be taking an even simpler approach. Instead of considering two sets, one cached, we'll hook our filter with a late priority which will give everybody else a chance to add whatever capabilities needed before we get to it in Groups.
Cheers!
PS You'll see this in Groups 2.11.0 about to be released. Please check it out ...
PS2 ... there will be a new filter groups_user_has_cap which will allow to hook into after Groups has handled them, so we have the same flexibility
This caches just the capabilities that were granted from the Group check instead of all capabilities that were passed in as args.
This prevents capabilities that were added in other filters from being cached and restored when it is testing the group capabilities.
The issue that we were seeing that started this change is WooCommerce also has a filter that adds capabilities here: https://github.com/woocommerce/woocommerce/blob/4.1.1/includes/wc-user-functions.php#L409
If the capability check was called twice in one request then the first time the function from the groups plugin would fire first and cache the options without the WooCommerce capability added then the WooCommerce filter would fire and add the proper capability.
But, because the
remove_fitler
/add_filter
dance happened in the Groups plugin function the filter would then be added to the WordPress filters after the WooCommerce one.So the second time it was called, the WooCommerce filter fired first and added the capability to the array, however the Groups one ran second and retrieved the array from the cache from the first run which didn't have the WooCommerce capability and returned that overriding the incoming capabilities.