Repository navigation
Fatal permission error during subscriber auto-moderation (Comment Moderation experiment) #515
Description
Description
Hey team! Following up on the newly merged Comment Moderation experiment ( #155 ). It looks awesome, but I found a specific edge case during local testing regarding user permissions.
The Issue:
If a logged-in Subscriber (or any user without the moderate_comments capability) leaves a comment on the front-end, the site throws a WP_Ability::execute permission fatal error.
The Cause: moderate_comment() hooks into wp_insert_comment, which fires under the current user's context. Because Comment_Analysis strictly requires the moderate_comments capability, the AI framework blocks the execution for non-admins and crashes the comment submission.
Thoughts on a fix:
a. Presently, I am temporarily using wp_set_current_user( $first_found_admin ) inside moderate_comment() right before the ability executes and restoring the original user immediately after.
Via the following code:
$original_user = get_current_user_id();
// Dynamically grab the first Administrator ID on the site
$admins = get_users( array( 'role' => 'administrator', 'number' => 1, 'fields' => 'ID' ) );
if ( ! empty( $admins ) ) {
wp_set_current_user( $admins[0] );
}
$analysis = $ability->execute( array( 'comment_id' => $comment_id ) );
// Restore original user context immediately.
wp_set_current_user( $original_user );b. For a more permanent architectural fix, we could add a method like execute_as_system() to the Abstract_Ability base class. This would allow us to safely bypass capability checks for internal system processes (like those triggered automatically by core hooks) without exposing that bypass to the REST API.
I was originally diving into this because I'm looking to pick up issue #509 (Add sorting and filtering plus additional labelling). I'd be happy to submit a PR to patch this permission bug first, based on whatever approach you prefer, so the moderation flow is totally stable before I start adding the filters to it!
Step-by-step reproduction instructions
- Install and activate the WordPress AI plugin.
- Configure any API (Google Gemini in my case) connector with a valid API key.
- Create a new user with Subscriber role.
- Log in as the user and comment on any existing post.
- Observe the error notice on the screen.
Screenshots, screen recording, code snippet
Environment info
- WordPress version: WordPress 7.1-alpha-62299
- AI plugin version: Version 0.8.0
- Active Theme: Twenty Twenty-Five
- Connector used: Google Gemini
- Browser: Opera GX (Chromium)
- Device/OS: macOS
Please confirm that you have searched existing issues in the repo.
- Yes
Please confirm that you have tested with all plugins deactivated except the AI plugin.
- Yes
Please confirm which theme type you used for testing.
- Block
- Classic
- Hybrid (e.g. classic with theme.json)
- Not sure
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
dkotter commentedon May 6, 2026
@Intenzi Thanks for the report! This was a miss on my part when building this out, I (obviously) never tested leaving a comment with a logged-out user.
I've opened #516 now to fix this, if you have some time to test/review that and ensure it fixes things for you, that would be great!
I didn't necessarily love the idea of trying to find an existing admin user to set as the current user and while I think having something like
execute_as_systemmight be nice eventually, at the moment this is the only experiment that would utilize that. As such, I kept it fairly simple and just added a new method to theComment_Analysisclass that is publicly available and doesn't trigger a permission check. This way anyone using the Ability directly will still run through the permission check but if we a trusted internal use case, we can call this new public method and bypass the permission check ourselves. But open to thoughts on this approach