[buddypress-trac] [BuddyPress Trac] #6482: Comment syncing between activity and post comments for Custom Post Types
buddypress-trac
noreply at wordpress.org
Tue Jan 19 07:55:23 UTC 2016
#6482: Comment syncing between activity and post comments for Custom Post Types
--------------------------------------------------+-----------------------
Reporter: shanebp | Owner: imath
Type: enhancement | Status: assigned
Priority: normal | Milestone: 2.5
Component: Component - Blogs | Version: 2.2
Severity: normal | Resolution:
Keywords: needs-testing dev-feedback has-patch |
--------------------------------------------------+-----------------------
Comment (by r-a-y):
@imath,
Thanks for working on this and apologies for not looking at this ticket
sooner!
I spent the last day or so looking at the code and I really appreciate the
thought that has gone into making sure that the "Show" dropdown filter
will work for post types that have registered comment tracking support.
Here are my notes:
'''1. action vs. type'''
This isn't really a problem with `03.patch`, but is a problem we've had
since BP v1.5.
Since BP v1.2, in `bp_has_activities()`, we accept a parameter called
`'action'`, which is really the activity `'type'`.
However, we also have several functions such as
`bp_activity_action_name()` that are marked as deprecated since BP v1.5 in
favor for their activity `'type'` equivalent function.
In multiple parts of `03.patch`, we reference the activity `'action'`.
Should we be referring to the the activity `'type'` instead?
'''2. bp_activity_action_is_post_tracking_action( $action_id ) and
bp_activity_action_supports_comments_tracking( $action_id ) functions'''
Instead of introducing these two new functions, I've created one function
called `bp_activity_type_supports()`, which works similar to WP's
`post_type_supports()` function and gives us some flexibility if we decide
to add more features to BP activity types in the future.
So instead of `bp_activity_action_supports_comments_tracking( $action_id
)`, we can use `bp_activity_type_supports( $activity_type, 'comment-
tracking' )` instead.
In `bp_activity_type_supports()`, you can also see that I also translated
`bp_activity_action_is_post_tracking_action()` over to what I named
`'post-comments'`.
In `03b.patch` (requires `03.patch` to be applied first), I've replaced
all instances of `bp_activity_action_supports_comments_tracking()` and
`bp_activity_action_is_post_tracking_action()` with
`bp_activity_type_supports()`. Let me know what you think of the
`bp_activity_type_supports()` function.
Perhaps the function should be renamed to `bp_activity_action_supports()`
instead? :)
'''3. Performance tweaks when the activity component is not active.'''
If for some reason, a site admin decides to disable the Activity
component, we shouldn't load any of the activity code for the Blogs
component.
In `03b.patch`:
- I've moved `BP_Blogs_Component::post_tracking_args()` from `bp-blogs-
loader.php` to `bp-blogs-activity.php`.
- I'm also conditionally loading `bp-blogs-activity.php` if the Activity
component is active. This does change a few functions that were
previously always available such as `bp_blogs_record_activity()` and
`bp_blogs_delete_activity()`, but those functions always checked to see if
the Activity component was active anyway.
'''4. Creating an activity item for an existing WordPress post.'''
This isn't really related to comment tracking, but when using the code
snippet from comment:15 during testing, I tried to edit an existing WP
page and hoped that would create an activity item for the page. It did
not.
I think we should go ahead and create the activity item in this case.
Patch adds support for this by adding a check in
`bp_activity_catch_transition_post_type_status()` and adds a unit test.
I also removed an older unit test that explicitly checked that a post edit
should not create a new activity.
----
'''Questions:'''
'''1. Should we move the majority of the "Post Comment Synchronization"
function hooks from bp-blogs-activity.php to the Activity component (under
bp-activity-actions.php)?'''
The reason I ask is `03.patch` already deprecates a few of our older blog-
specific activity functions such as `bp_blogs_record_comment()` and
`bp_blogs_remove_comment()`.
We probably should move those functions over to the Activity component as
well.
'''2. Potential problem with wp_new_comment()'''
If a dev programatically adds a comment using `wp_new_comment()`, this
bypasses checks for the post's comment status. So even if a post's
'comment_status' is set to 'closed', a comment can still be added with
that function. Since this is mostly a WordPress thing, I don't think we
need to do anything here, but thought I'd mention it.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6482#comment:23>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list