Feature Request: new action for dt_pre_post_push

[aaronware]

Is your enhancement related to a problem? Please describe.

Have a defined action to do some preflight/setup things prior to pushing a post.

Designs

In our implementation related to #992 (which we resolved with a custom extension). We're mapping distributing site with existing posts to cloned sites w/ existing posts. This is working great however we have a lot of posts/pages/products etc that already exist. One thing that would be great is the ability to have an additional do_action within the internal and external push methods to also allow for dt_pre_push_post that passes along the current post_id to be pushed and args. This allows for developers to possibly do some preflight checks prior to push.

In our scenario. We're mapping to existing posts. However, sometimes an admin user may forget to do the existing mapping (since we have different stakeholders, turn over, etc). So prior to pushing the content, we want to hopefully help the user automatically map the existing posts for them using the mapping functionality we've created, if the post exists in the distributed site, map to the existing post and return the deets and run the push as normal.

Describe alternatives you've considered

The same check could, in theory, be done in the save_post and not necessarily need this hook. It could also be done using dt_push_post_args since for this implementation we are manipulating the ExternalConnection the first time.

Let me know if you think using the existing hooks is the best approach vs adding a do_action earlier the push is useful.

Again I think realistically this can be done in save_post, now that I put the idea out, but maybe it would be useful as it's own hook w/ not a lot of overhead. If you think it's beneficial I'd do a pull request for review. If not feel free to close and give a recommendation for others in the future.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[jeffpaul]

@peterwilsoncc I'm curious with the work going into 2.0.0 if this might be worthwhile in that release or something to tackle in the follow-on 2.1.0 perhaps?

[jeffpaul]

Tagging this for discussion once v2 is released to see about best approach for handling the request here.