Transform a Subject

[psrpinto]

Once extracted, a Subject needs to be "converted" into its target plugin. For example, a subject of type product, can be transformed into a Woo product, or an Easy Digital Downloads product.

[psrpinto]

@ashfame already did considerable research on this, for example in #125

[psrpinto]

I think effectively addressing this issue requires clarifying the following points:

1. At any point in time, how many transformed posts can one subject have?
   • 0 or 1
   • exactly 1
   • 0 or N
2. How does the user provide the information of which plugin they want to use (Woo or EDD)?
3. At what point does the transformation happen?
   • Is it triggered by the user? If so, how could the UI for that look?
   • Does it happen behind the scenes without any required action by the user? If this is the case, then point 2. is relevant.

---

Regarding the case where the answer to 1. is "0 or N":

I think that brings considerable complexity. For example, we would need to change our data model to accommodate for that. Currently, in our data model, a subject has a transformed_id, it would need to instead have an array of transformed_ids.

This also has consequences in terms of UI. If there can be more than one transformed post for a subject at a time, that needs to be exposed in the UI. For example, the user might want to see the previews of all transformed posts.

Given that we don't have users asking for having support for "0 or N", my suggestion would be to not implement that feature at this time.

[ashfame]

I believe it's best to keep it simple with always exactly 1:1 relationship between liberated_data post and transformed post (effectively only 1 plugin running that transformation). So exactly 1 answer to 1.

This means we always know what preview to showcase as well. And if the user were to browse the site how it looks in the preview, it's exactly how it would be if they were to conclude liberation at that point & export their site.

We could keep it very simple and work under the assumption that there would always be a single plugin operating during liberation. Anything else is not supported. But this means, we are not letting plugins participate "during" liberation more than the default choice of plugins we come with, to handle different types of subject. That weakens the stance of keeping things simple for now and postponing all this decision making to future.

---

Only reason I am going to mention details beyond that assumption is because I solved this exact problem in the design of the API itself (first in #123 and then in #125), so it's worth mentioning here, to paint the complete context of this problem.

Problem: The user intentionally installs a plugin that handles something we already have a default plugin for.

This is what I call as a "compete" situation and because we have established there will always be a 1:1 relationship, so we need to make a choice for handling it:

• Prevent it
• Resolve it
• Ignore it

Prevention could mean as much as displaying a message and asking the user to disable one of those plugins to continue. Simplest solution as we only need to detect the "compete".

Resolving could mean presenting an option to the user, as to which one they would like to proceed with. More work for something that's quite an advanced use case and probably not enough ROI this early on. Only merit for it, would be to allow the API design account for this possibility.

Ignoring could mean working under the assumption there is always one. And unexpected/unhandled behavior due to compete is outside of what we are willing to support. Personally, not a fan of this route.

---

The API we offer for integration right in the beginning could set the foundation for controlling this behavior. If we postpone the decision making to future and not design the API considering these future decision points, more than likely final design won't be as good as it would be when all things are considered right from the beginning.