Adding More Data to aggregator_post_status Filter

[mikeselander]

We have a need to push different post statuses contextually dependent upon the original post. I'd like to pass through the entire post data and possibly the original blog ID to be able to find out this information and send a different post status through depending on certain conditions.

Current Filter apply_filters( 'aggregator_post_status', $orig_post_data['post_status'] );

However, adding all this extra data feels a little gross, especially when we're already passing through the status. I don't want to change the data passed through now because backwards compatibility but essentially doubling up on post data is also not preferential. #53 could potentially cover our needs but also feels heavy and we would need to update the post again that this filter could have just set.

Any thoughts on changes to this filter @philipjohn?

For reference, this is the logic we would want to implement: We have Categories A and B on posts that could be pushed. If a post assigned to Category A is pushed it should be published right away on the portal (child) site. If a post assigned to Category B is pushed it should be set to draft.

[philipjohn]

Hmm. If we were to add the post ID to that filter, would that do it? Something like:

apply_filters( 'aggregator_post_status', $orig_post_data['post_status'], $orig_post_id );

IIRC current implementations of that filter will be fine - to use the new parameter they'd just need to include the $accepted_args parameter in their add_filter() call.

[mikeselander]

Passing in the original post ID would be probably be enough form the original post - wouldn't we need to pass in the original blog ID or will you already be on the original blog when this is triggered?

[philipjohn]

aggregator_post_status triggers when we're switched to the portal blog to do the sync, so we would need to pass the original blog ID if we wanted that.

I guess we have two choices;

1. Pass $post_id and the hooking function would have to switch_to_blog() to get any data
2. Pass the entire post data as a second parameter.

Sounds like 2 would perform better.

[mikeselander]

Ah, yes I see that. 👍

@philipjohn I'm not entirely sure that the 2nd choice is the best option because we need to get taxonomy/term information for our use case. Perhaps if we did pass in just the post ID and the ID of the original blog it would work nicely.