Apart from all the implementation, we’d like to know your opinion about the name of the plugin. We were thinking about using something more specific than just Theme Bridge, something like Decoupled Theme Bridge or Headless Theme Bridge.
We think that Theme should be included in the name because it’s a theme substitution.Maybe Bridge could be changed, or even use a completely different name 
What do you think guys?
I think that the “Theme Bridge” is more like a tee than a “bridge”: 
Pros:
tee is also a command that redirects input to another output in addition to standard output. So, that semantic similarity can help people grasp the design quicker.Cons:
About settings, I agree with you @SantosGuillamot.
This is my opinion of what should go in the MVP:
Later on:
publicPath in Frontity.publicPath directly from the Theme Bridge settings.What if the theme bridge would be just an option of the main Frontity plugin?
Imagine a configuration screen that starts with these two questions:
Then, more options appear when they choose one option or the other.
I’m telling this because to make the preview work in the external domain mode we also need to know the URL of the external domain.
@SantosGuillamot and I have been taking a look at the different options to serve the static assets and we made a diagram.
External domain and Nginx/Apache file reads will be possible when we implement the publicPath option.
EDIT: I have remade the diagram: https://excalidraw.com/#json=5094249578102784,nCtvPMn8e--i6pbAOxUUGg
After some more investigation, we think it would be also a great idea to add support to configure all the settings with ENV variables.
Regarding this, it could be a great idea, I’ll give it a thought, thanks for the suggestion Luis! I feel it could improve the user experience of linking your WordPress and Frontity and I guess that, as it’s happening with the preview, sometimes it will be better to have this in the same plugin.
This will work similarly to what we did for the CLI: Expose Frontity commands to be used programmatically
I would like to add another setting which can be useful for multisite configurations.
For this to work, the Theme Bridge should simply add that ?name=XXX query to the request.
I have added another FD to rename ?name= to ?frontity_name= .
Good one! 
I’ve added it to the opening post so we keep track there of all the possible settings.
I’m going to back off a little because it looks like this is causing some confusion when people still think about it as decoupled. I think we should choose a name that helps with that confusion.
My proposal is to use the terms:
And tell that “Frontity supports two modes, decoupled and embedded”.
I agree with you @luisherranz, this is still a bit confusing. I think that your proposal would help to clarify this.
Thanks @pablo. I guess that nobody has additional complains, so I’m going to use these terms in the WCEU talk.
I have moved the proof of conecpt repository to the Frontity organization in GitHub and I have:
The new URL is:
We have added support for the post preview 
You also need to update Frontity and its packages to the latest version: https://docs.frontity.org/guides/keep-frontity-updated
If you have problems or want to give feedback, please do so in the FD of the preview: WordPress preview support
Thanks!!
In order to clarify a bit more what this Embedded Mode is, here you have some diagrams diagrams that show how this Embedded Mode works (compared to the current “Decoupled Mode”)
I’d like to have more clear the current status of this Feature Discussion.
As far as I know:
Also, I guess this Embedded Mode FD is very related with some of the current OKR’s.
So, what is the prioritization of next big features (AMP, Source v2, Embedded Mode,…) ? What is the planned order to do them? Does this FD need some other FD to be done before event start researching it? Which ones?
@SantosGuillamot can you summarize the current status of this FD?
As you mention right now we have this proof of concept that we are testing and it is running in frontity.org for example. It has been great so far but we have to keep in mind that it doesn’t have an interface or even tests, so it’s not a beta yet. Moreover, we would like to improve some aspects so it is more reliable and easier to use.
Finally, the first stable version of the Embedded mode will be included in the Frontity PHP plugin, where you could select which mode you want to use and it will include some functionalities like the preview.
It is hard to define and order these features. They are included in the mid term roadmap so we will be working on them during next year, but I’m afraid I cannot define an order right now, because it will likely change. The AMP package is one of our top priorities right now, and our initial idea is to work also on the Server Extensibility and the Frontity hooks.
We are working on a roadmap public page where we will explain everything related to this, to give more visibility. I think it will be published during next week probably.
