get post from original id

[avag-novembit]

Added function to get posts using original post id stored in postmeta table. closes #410.

[jeffpaul]

@adamsilverstein @dkotter if either of you have time to review this that would be great, thanks!

[adamsilverstein]

@jeffpaul I'll take a look

[adamsilverstein]

Hey @avag-novembit thanks for your contribution.

I have a few questions about the Issue/PR:

• Can you describe your use case and why this should be in the plugin itself rather than handled in custom code?
• Can we address posts that are distributed using a network connection, meaning over a REST API connection not posts on the same network install?
• Can the functionality match the name get_post_from_original_id and return the full post object - (currently returns the post ID?)?
• Can you use switch_to_blog (using the dt_original_blog_id) and then use get_post_meta to get the id to avoid the direct database query?

[adamsilverstein]

left some questions and feedback

[avag-novembit]

Hey @adamsilverstein, thanks for getting back. Let me try to answer the questions.

• Can you describe your use case and why this should be in the plugin itself rather than handled in custom code?

The purpose of this pull request, and most of the my pull request, is to make the plug-in more extendable. It's used in add-ons (e.g. handle distribution of Advanced Custom Fields or WooCommerce products) which are in the development process currently. I think it'd be better to have a function inside the plug-in to provide API for add-ons, though open to other suggestions.

• Can we address posts that are distributed using a network connection, meaning over a REST API connection not posts on the same network install?

Distributed to the so called external connections? If so, we can.

• Can the functionality match the name get_post_from_original_id and return the full post object - (currently returns the post ID?)?

Agreed that it'd be better to call it get_post_id_from_original_id(..), changed accordingly.

• Can you use switch_to_blog (using the dt_original_blog_id) and then use get_post_meta to get the id to avoid the direct database query?

For the internal connections I think it would be possible, however for the external connections I believe it won't work out.

[adamsilverstein]

The purpose of this pull request, and most of the my pull request, is to make the plug-in more extendable.

If I understand this PR correctly, its purpose is to find the post or posts that are distributed from a particular post. EG you pass a post ID and the function would return all posts that (are on the same network install) and contain the dt_original_post_id reference back to the original (passed) post id.

To be genuinely useful as a plugin helper I would expect this function to work for any connection type: external or network (or others - connection types can be added). The current implementation only works with network connections.

Looking into the code I found that for the information you need is already tracked and available in the connection map stored in post meta on the original post under the key dt_connection_map. In this data point you will find a (serialized) array of the post IDs (along with which connection id and a timestamp). We use this data in part to ensure updates to the original post are propagated to distributed copies.

For example here is the data stored in a post I have distributed to both internal and external connections:

You can search the codebase for usage to see where we set up and use the connection map.

I still feel like this PR could be useful for retrieving the list of distributed post ids from a post. I would consider adding a helper function that:

• Pulled data from the dt_connection_map meta and extracted the data in a usable format
• Returned the full distribution map: the list of remote connections / posts (post ids alone aren't that useful)
• Named to reflect its function, maybe get_distributed_post_data

[avag-novembit]

Yes, the purpose of PR is to find the "child"/"dependent" post or posts that are distributed from a particular post. In essence the logic could be organized using dt_connection_map, it has written this way to be more convenient to operate with. Also, the functionality can be implemented in add-ons.

[jeffpaul]

Unassigning reviewers here while we focus on the v2 refactoring and can then reassess how best to handle the root issue here.

[github-actions]

@avag-novembit thanks for the PR! Could you please rebase your PR on top of the latest changes in the base branch?