Prevent comments on ap_post when create_posts is disabled #2664
Conversation
When the Reader UI is disabled, the create_posts option may also be disabled, but existing ap_post entries can still receive incoming fediverse replies. Previously, these comments would be created and trigger email notifications. This change adds a check in Interactions::persist() to reject comments on ap_post when the create_posts option is disabled, preventing unwanted notifications.
There was a problem hiding this comment.
Pull request overview
This PR prevents comments and reactions on ap_post entries when the create_posts option is disabled. When Reader UI is disabled, existing ap_post entries could still receive incoming fediverse replies, creating unwanted comments and email notifications. The solution adds an early check in the Interactions::persist() method to reject these interactions.
- Adds validation in
persist()to check if target post isap_postandcreate_postsis disabled - Updates existing tests to explicitly enable
create_postsoption where needed - Adds comprehensive test coverage for the new behavior with three new test cases
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| includes/collection/class-interactions.php | Adds check in persist() method to reject comments/reactions on ap_post when create_posts option is disabled |
| tests/phpunit/tests/includes/collection/class-test-interactions.php | Updates existing tests to explicitly set create_posts option and adds three new tests covering disabled/enabled scenarios for comments and reactions |
| .github/changelog/fix-ap-post-comments-when-create-posts-disabled | Adds changelog entry documenting the fix |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| */ | ||
| public static function persist( $comment_data, $action = self::INSERT ) { | ||
| // Don't allow comments on ap_post if create_posts is disabled. | ||
| if ( is_ap_post( $comment_data['comment_post_ID'] ) && '1' !== \get_option( 'activitypub_create_posts', false ) ) { |
There was a problem hiding this comment.
The option check uses strict string comparison '1' !== \get_option(...), which is inconsistent with other parts of the codebase. For example, includes/class-comment.php lines 707 and 771, and includes/handler/class-update.php line 97 use truthy checks without strict comparison. While this follows the pattern in includes/class-mailer.php, consider using a consistent approach throughout the codebase. The strict comparison is more explicit and safer since WordPress options are typically stored as strings.
|
I think it is fine to add comments to an |
|
Closing in favor of #2667. |
Proposed changes:
create_postsoption may also be disabled. However, existingap_postentries can still receive incoming fediverse replies, which would create comments and trigger email notifications.Interactions::persist()to reject comments onap_postwhen thecreate_postsoption is disabled, preventing unwanted notifications.Other information:
Testing instructions:
create_postson)ap_postposts be createdap_postpostsChangelog entry
Changelog entry was added manually via
composer changelog:add.