You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the content liberated, we are still not handling the media assets, the images and whatnot, they would be hot linked to the origin URL. One of the ways we (@psrpinto and I) think would be to rely on a third party plugin to fix this for us afterwards as if you would do in a regular migration from a WordPress host to another host. That way we don't have to write a lot of code to do the things for which WP plugins exist out there and we can call them programmatically.
The text was updated successfully, but these errors were encountered:
I think we need to drill-down on this issue. For example:
At what point does the ingestion happen? Does it happen when the subject is created, or when it is transformed? Or between being created and transformed?
Which existing code we can leverage? Maybe something from data-liberation, or if it's a third-party plugin, we need to choose one.
Ideally speaking, storing raw data and running transformations, should be separate and the act of "transformation" should do everything that's required for the data to exist in WordPress.
But practically, this is what we have:
We have our raw data and partially transformed data (whatever transformations run on frontside via paste_handler of Gutenberg) saved together in a single subject, which is then used to create the final transformation output. No clean separation here.
Some of the transformation work (such as media assets import) would be handled in a post-transformation setup at the very end of the entire liberation process. This is where the libraries residing in Playground repo would come in.
With the content liberated, we are still not handling the media assets, the images and whatnot, they would be hot linked to the origin URL. One of the ways we (@psrpinto and I) think would be to rely on a third party plugin to fix this for us afterwards as if you would do in a regular migration from a WordPress host to another host. That way we don't have to write a lot of code to do the things for which WP plugins exist out there and we can call them programmatically.
The text was updated successfully, but these errors were encountered: