Control preview automatically #128
Conversation
| add_filter( | ||
| 'data_liberation_preview_transformed_post_id', | ||
| function () use ( $transformed_post_id ) { | ||
| return $transformed_post_id; |
There was a problem hiding this comment.
I'm having some trouble understanding the purpose of this filter. What would be a use case where something other than $transformed_post_id would be returned?
There was a problem hiding this comment.
$transformed_post_id is the native transformed post id with filter on top of it, so plugins can modify its value to have their transformed post id be returned and hence used for preview.
There was a problem hiding this comment.
The result is obviously ambiguous when multiple plugins are competing since only value can be returned and shown in preview. The winning one would be the one that hooks last & would overwrite the value.
There was a problem hiding this comment.
Could you give an example of a use case where the plugin would need to do both the following:
- Call
store_reference()with a$transformed_post_idwith value A - Return a different value than
Ain thedata_liberation_preview_transformed_post_idfilter
In what situations do you see this happening?
There was a problem hiding this comment.
Literally every case :) Lets say X plugin takes over S subject type and run its transformation logic to produce P post_id post. We have also produced N post_id post with our native transformation.
With current approach, P doesn't automatically gets used for preview. So, this filter comes into play, where the plugin author would first plug in their own transformation and then return P as the post_id using the filter so that gets used for preview. Hope that makes it clear?
There was a problem hiding this comment.
Thank you for clarifying. If I'm understanding this correctly, that means that the decision of which transformed post (N or P) is used for the preview becomes the responsibility of plugins?
If so, what advantages does that bring compared to it being the responsibility of "core try-wordpress" to decide what gets used as the preview?
In other words, why should it be a plugin that decides what transformed post gets used for preview? To me this feels like a core responsibility of try-wordpress, I'm not sure I see the advantages of exposing that concept to plugins.
This PR attempts to explore the possibility of being able to control the preview automatically without having to do it separately.
I have added the filter call within the function responsible for storing reference, so that developers just have to do a single call and everything is taken care of.
This exposes a flaw in our current approach (#125) of letting multiple plugins compete for a subject type. In reality, we want the user to evaluate multiple options to see which one they want. Eventually, only one would/should win and be the final transformed output of that subject.
Additionally, only one preview can be rendered at any time, so it doesn't make sense to have multiple plugins compete & transform at the same time.
Its like buying shoes really, you want to evaluate multiple ones to see which one you like, even try them one by one but you can't try multiple ones at the same time and eventually you only buy the best one.
This is why in my previous approach (#123) I made it a point to detect when plugins compete and only advance with just the chosen plugin with previews functional without having to do anything. So, I propose the solution of being able to resolve this by exposing a dropdown in the UI for instance.
With this PR, I hope to finalize the decision of how we should handle previews.