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:
For anyone familiar with unix, 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:
The metaphor is not 100% accurate, because we get the data back from our “tee”, unlike the real tee, which just redirects it to an additional output.
It’s really weird to pronounce “tee” because I think about a cup of tea when I say it
I think having separate server/static URLs is a must.
We also need a query to bypass the Theme Bridge and see the original theme. We can use that for previews as well.
We let Frontity manage the 404’s.
We recommend using our fork of Simple Cache for caching.
Later on:
We add the possibility to change the publicPath in Frontity.
We add the possibility to populate that publicPath directly from the Theme Bridge settings.
We add the possibility to have different sets of configurations, so people can easily switch between production, staging, local development (using ngrok is site is live). Those configurations can be changed for everyone or only for that user.
We add the possibility to embed the statics inside the server for people who want to use only a serverless function.
We add the possibility to exclude some URLs from the Theme Bridge and fallback to the PHP theme.
We add the option to warn the developer when a URL is a 200 in Frontity but a 404 in WordPress (so they can fix it).
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.
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:
Decoupled mode.
Embedded mode.
And tell that “Frontity supports two modes, decoupled and embedded”.
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:
There’s a POC being used successfully with some partners
There’s been some developments related to this mode (Preview for example)
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.