CUNY Academic Commons

This is not exactly a recurrence of #6350, though the filter introduced in #6350 accidentally caused the problem in this ticket to be covered up. The workaround in #6350 was rolled back as part of #7683.

Briefly, this problem only exists for legacy posts. A number of years ago (it appears to be May 2013 or so), bp-groupblog was modified so that groupblog activity items had the type 'new_groupblog_post' rather than BP's default 'new_blog_post'. Posts created before this date (actually, most posts - some have new_groupblog_post, for reasons I don't recall) have 'new_blog_post' activity items. When bp-groupblog looks for existing groupblog activity items corresponding to the currently edited post, it looks for 'new_groupblog_post' items. As such, it misses the existence of the existing activity item, and creates a new one.

Ray - Rather than writing a kludge workaround, my inclination is do something like this:

UPDATE wp_bp_activity SET type = 'new_groupblog_post' WHERE type = 'new_blog_post' AND component = 'groups'

Can you spent 60 seconds thinking about whether this would have any weird consequences? I'm 95% sure it's safe.

Sounds safe to me.

Maybe the cac_block_groupblog_activity_bump() function can be removed after the DB query is run?

Thanks to you both!

This bug has re-emerged, on this post https://jitp.commons.gc.cuny.edu/the-places-of-mentorship-and-collaboration/, triggering a notification in this group: https://commons.gc.cuny.edu/groups/journal-of-interactive-technology-and-pedagogy-public-group/

Luke - I've opened #8535 to track the new issue, which seems similar to this one on the surface but appears to have a different cause.