[buddypress-trac] [BuddyPress] #5130: Synchronizing activity comments to main component

buddypress-trac noreply at wordpress.org
Mon Sep 2 17:50:00 UTC 2013


#5130: Synchronizing activity comments to main component
-------------------------+--------------------
 Reporter:  r-a-y        |       Owner:  r-a-y
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  1.9
Component:  Core         |     Version:  1.2
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+--------------------

Comment (by boonebgorges):

 Awesome, r-a-y! You've thought this out really thoroughly (as usual, it's
 more complex than I'd originally thought). Some thoughts and questions, in
 no particular order:

 > // we still have to disable activity commenting for 'new_blog_comment'
 > // commenting should only be done on the parent 'new_blog_post' item

 How does this work with WP comment threading, where you can reply to a
 comment (`comment_parent`)? Should we be checking the `'thread_comments'`
 setting, and recording the thread position appropriately in WP
 (`comment_parent`) and BP (`item_id` + `secondary_item_id`)? Not a
 showstopper for 1.9, but just throwing it out there.

 > // handle timestamps for the WP comment after we've switched to the blog

 Maybe we should use the actual activity item timestamp rather than the
 current time? We're already loading the activity item later in the
 function; could just move it up. (Very minor, obviously.)

 > // what if a site already has some comment email notification plugin
 setup?
 > // this is why I decided to go with bp_activity_add() to avoid any
 > // with existing comment email notification plugins

 Ugh, yeah, we're going to get complaints either way :) Your method seems
 good for now.

 > Changing bp_get_option() to check the buddypress()->site_options array
 first before querying with get_blog_option(). This allows me to use
 bp_disable_blogforum_comments() again as intended. (Should probably create
 a new ticket for this.)

 Probably falls under #4913

 > Still need to think of a decent strategy. I'm thinking of deleting all
 WP comment children and all BP activity children instead of trying to
 emulate WP's "move comments up a level" technique

 I'm wary of messing with WP content in this way. How complicated is WP's
 method? Do they have a sort of walker/recursive function that we could
 borrow?

 > Fixing activity comment permalink when posting via AJAX to use WP
 comment permalink. This is fixed after AJAX posting (when you refresh the
 page) though. A slight niggle.

 Very slight. I'd put this at the bottom of the priority list.

 > There is a lot of manual code that needs to be written if a plugin dev
 wants to sync activity comments with their component.

 Your ideas here sound good to me, but I would deemphasize this for now. I
 can think of very few plugins where this would even make sense (maybe
 BuddyPress Docs). If it's not modular for 1.9, I think it'll be more than
 fine.

 > People will undoubtedly ask about supporting forum threads. I don't want
 to do this for the legacy forums because 'bbpress_init' is kind of a
 killer, but we'll probably want to add support to bbPress 2.4.

 Agreed about not supporting legacy forums. bbPress 2.x support would be
 great; let's get blogs working the way we want it, and then do forums as a
 second pass. I want to be sure we're happy with the technique before
 getting it copied over to bbPress. (Also, if this were not to happen for
 1.9, it probably would not be the end of the world. This is probably
 related to the point about a plugin API above.)

 > I'll probably start breaking up the patch into smaller commits once the
 deletion issue is handled.

 Awesome, I am excited about this one. Thanks, r-a-y.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5130#comment:8>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list