Activity stream doesn't like scheduled post in multisite

[Prometheus Fire]

I didn't see this any where in the 1.6 roadmap, but I'm getting a bug with how BP handles putting scheduled posts into the activity stream.

The behavior that is occurring goes like this;

I have a blogger who works about a week ahead. She writes her post on a sunday, finalizes and does a final save, then schedules it to publish the following friday. When WP changes the status of the post from scheduled to published, BP adds the post to the activity stream based on the timestamp of the last save (which was Sunday). This is likely because the status of the post is changing, not the timestamp.

If WP were made to do an auto-save when it publishes a scheduled post, then the last timestamp would coincide with the publishing date, this is based on the behavior that BP updates the activity stream whenever a post is resaved (Unfortunately, I see that you guys changed that behavior here in #3746) so forcing WP to resave on publish won't work.

There needs to be some way of accurately recording a scheduled post in the activity stream. BTW, this was a tricky bug to see, it is best noticed using the RS Buddypress Activity Refresh plugin (​http://wordpress.org/extend/plugins/rs-buddypress-activity-refresh/). With that plugin, when a post is published, the new record prepends to the top of the activity page when left idle, when you refresh the page, the activity stream resorts into its correct chronological order (thus causing the record of that recently published scheduled post to drop down to its spot in the stream). In order to get these posts in properly based on their publication date, we've been having to manually resave them to make them appear in the current stream correctly (which is why I mentioned ticket #3746).

[boonebgorges]

Gah, not this issue again. Last time I "fixed" it, a bunch of people jumped down my throat because clearly I did not know what I was talking about; now this issue is showing the merits of the way it was before I "fixed" it again. Oy :)

One simple strategy is to use the current server time, instead of post_date or post_modified, when tagging the activity item. In the case of normal write-and-then-publish posts, the values will be the same anyway; in the case of scheduled posts, it'll end up with the correct published date. I'll have to think about whether this would have any effect on other types of scenarios (backdating, for instance). Feedback welcome.

Another option is to check the previous status of the post before deciding on a timestamp for the activity item. The problem with this is that there's not really a reliable way of checking this. I'll have to do more research to see if there's a place in the post-publishing process where we can hook in and detect that a scheduled post is being published.

FWIW, it would be worth seeing what WP itself does with scheduled posts. I don't know off the top of my head. Do they get post_date of the *scheduled* time, and a post_modified of the time of the last save? Is post_date set only once (at the time of writing), or is it changed when the post is published? Etc.

[prometheus fire]

With the release of 1.6 I'm finally really seeing the impact of #3746 - scheduled posts that are written a week before they are published are now never seen in the current activity stream. The bug that 3746 fixed, made for a good workaround to allow us, as moderators, to bump those scheduled posts up in the stream. Since the fix of 3746, we now have no way of getting scheduled posts into a reasonable place in the activity stream.

Am wondering if this ticket can be boosted in priority and setup for a quick release. Not sure how others feel about it, but for us, we now have one of our most prolific bloggers virtually absent from the daily activity.

[boonebgorges]

I think it's a reasonable thing to put in the 1.7 milestone (which I will do). But I don't know about a "quick release". We have to have a viable solution first, and it's likely that whatever is implemented will not be appropriate for a bugfix release.

I'm wary of going solo on this patch, since the last few times I've dealt with the issue I have angered approximately half the users of BuddyPress (go figure that one out). So any feedback or ideas on how to honor scheduled posts without also allowing for stream-bumping through edits would be most welcome. (I think the answer may be in wp_transition_post_status, but that'll require a fairly significant refactor of how blog posts are currently published in the activity stream.)

[rogercoathup]

My thoughts (from forum thread):

I think it’s a site by site, use case by use case, issue. I don’t think one or the other approach should be forced. Would be nice if the core functions for blog post updates / edits provided a parameter to set one or the other behaviour.

Some sites may want a snapshot in time, others will want activity stream content that evolves with changes to the underlying content.

I suspect in the majority of cases, edited blog posts after publishing are relatively rare, but can also envisage situations where they are a fundamental part of the site operation — and may also require bumping to the top of the stream.

You also have the issue of minor edits (fixing typos) versus major edits (fundamental content changes) — they may logically need handling in different ways, but are complex to differentiate between in code.

In the short term, the solution is to build or own hooks to give site specific behaviour.

Thread here: http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/can-you-check-if-this-is-intended-activity-stream-behaviour-in-bp-1-6-please/

[prometheus fire]

@rogercoathup - Thing to remember here is that this is not an issue of bumping posts. For us, we found that the bug that allowed bumping posts was a workaround for the fact that BP doesn't honor scheduled posts. It made it possible to push those posts manually into the current daily stream when they would otherwise go unnoticed. Though, with 1.6, I see post bumping as a effectively solved and I think the solution for that is fair and reasonable.

The issue here is that there is a core blogging feature of WP (scheduled posts) that BP doesn't support yet. Scheduled posts is a feature that we've found to be used by some of the more professional and dedicated bloggers. These are people that are diligent and disciplined to the blogging method and generally have a longer blogging lifecycle than immediate publishers. Unfortunately, these highly valuable bloggers for any BP/Multisite setup don't get the exposure they deserve when deployed on BP because of this bug. These are the kind of bloggers we want to support because they make our networks look busy and active.

As an aside: I do agree that a short term fix would be to re-insert the post bumping bug on networks that have bloggers using scheduled posts. This would allow network operators to moderate those posts into the activity stream for exposure.

[boonebgorges]

Thanks for the thoughtful feedback, guys.

In the short term, the solution is to build or own hooks to give site specific behaviour.

I have no problem adding hooks as a short-term solution, but I'm at a bit of a loss as to what those hooks would be. rogercoathup, is there any chance you could whip up a patch, even something very rough?

I do agree that a short term fix would be to re-insert the post bumping bug on networks that have bloggers using scheduled posts.

Agree with whom? I don't think anyone suggested this :) In any case, you can reinstate your desired behavior today by unhooking our bp_blogs_record_post() function and supplying your own version that is modified to respond in the desired way to scheduled posts. Thus, on your installation, you can reinstate the post-bumping bug as you suggest.

[johnjamesjacoby]

Agree this needs attention, but needs a patch first. Punting to 1.8.

[boonebgorges]

Rereading this ticket has given me a stomachache :) I think that the appropriate way to handle the issue will be by moving from 'save_post' to 'transition_post_status', and then doing the relevant status checks before going through with the activity creation/bumping. I'll take this on as a task for 1.9, possibly in conjunction with #3460.

[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