On Multisite Editing Blog Posts Bumps Original Activity To Top

[nahummadrid]

I didn't see a ticket in this latest group so I'm adding this hopefully it wasn't already ticketed.

When a user edits a blog post, the activity items gets a new timestamp and then moves back up to the top of the activity stream.

[seagrinch]

I have the same problem.

Line 193 in bp-blogs/bp-blogs-functions.php should be

'recorded_time' => $post->post_date_gmt

instead of

'recorded_time' => $post->post_modified_gmt

In addition, the format of the activity notice has changed (again), which means you may have to update any custom parsers. I'd prefer the colon to the comma in line 181, but I'd take either as long as it stays the same.

[boonebgorges]

See #2546

[seagrinch]

To me, that functionality is incorrect.

Now, if you make a small change to a post (or even just click the publish button again), the post appears at the top of the activity feed.

For example, I recently installed a new theme that required updating the metadata of some old posts. This caused posts from over a year ago, that had not substantively changed, to appear at the top of the activity feed.

As for thekmen's issue, if you have a draft post which you then publish, the publish date should be updated to the present. If it doesn't (perhaps because the user published a post, then set it to draft, and then published it again), it's up to the user to ensure the publish date is correct.

Bottom line, to my mind, the official date of record for a post should be the published date, not the modified one, and the activity stream should reflect that. On the other hand, for a "page" content type...

[boonebgorges]

That argument seems sensible. Wondering if anyone else has anything else to add - another core dev, maybe?

[nahummadrid]

Replying to boonebgorges:

That argument seems sensible. Wondering if anyone else has anything else to add - another core dev, maybe?

So will seagrinch's Line 193 code change work to fix this...this bug is really killing me, I can't see what the purpose is for it. If a forum post is edited it doesn't get bumped to the top, as well it shouldn't. So what is the purpose for having this currently for blog post edits. I don't mind waiting for 1.6 but man is it silly for blog posts to be reappearing because a minor fix or edit is done to an old post and the activity item says "posted 25minutes ago" and then the actual post says "posted 2 years ago"? I've seen plugins to bump activities to the top so I think if someone wanted this functionality for blog post then maybe they should apply a plugin.

[boonebgorges]

Yes, seagrinch's issue will make it behave the way it used to behave.

[boonebgorges]

I've seen plugins to bump activities to the top so I think if someone wanted this functionality for blog post then maybe they should apply a plugin.

Also, let me reiterate that "bumping" is not intended to be a "feature". The behavior is the result of a fix for #2546.

I will be happy to fix the issue when I have a good solution that addresses both #2546 and the issue being discussed in the current ticket.

[boonebgorges]

I'm about to commit the following fix:

• Keep 'recorded_time' pegged to post_modified_gmt, to prevent recurrence of the problem described in #2546
• Before recording a new_blog_post activity item, check to see whether an activity item exists for this specific blog post. If so, bail. That will prevent bumping.

[boonebgorges]

(In [5562]) Don't rerecord an activity item for a blog post being edited, to prevent bumping up the stream. Fixes #3746

[boonebgorges]

In 7577:

Publish blog posts to the activity stream based on transition_post_status

BP has historically had problems when posting certain kinds of blog posts to
the activity stream, such as improper bumping for post edits and incorrect
timestamps for scheduled posts. These problems stem from the fact that
bp_blogs_record_post has been hooked to the generic 'save_post'. Using
'transition_post_status' instead allows BP to prevent edit-bumps, while
allowing bp_blogs_record_post() to use post_date_gmt for activity timestamps
(thereby properly attributing scheduled posts).

See #3746, #2546.

Fixes #4090