Embedded mode

SantosGuillamot · 25 March 2020 09:14

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?

mmczaplinski · 25 March 2020 20:20

@SantosGuillamot

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

luisherranz · 26 March 2020 08:23

Haha, nice one.

“Bridge” also has an analogy. This is what’s inside my head when I think about it

luisherranz · 26 March 2020 08:37

About settings, I agree with you @SantosGuillamot.

This is my opinion of what should go in the MVP:

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).

luisherranz · 31 March 2020 10:57

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:

How do you want to use Frontity?

With an external domain.
Substitute the PHP theme.

Then, more options appear when they choose one option or the other.

1. With an external domain

Enter the URL of external domain: XXX
What do you want to do with the WordPress front-end?
- Show 404s.
- Redirect to the external domain.
  …

2. Substitute the PHP theme

Enter the URL of the server: XXX
Enter the URL of the statics: XXX
Do you want Frontity to bypass WordPress 404s? (danger: your sitemap won’t match)
…

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.

luisherranz · 31 March 2020 16:22

@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

SantosGuillamot · 1 April 2020 07:11

After some more investigation, we think it would be also a great idea to add support to configure all the settings with ENV variables.

SantosGuillamot · 1 April 2020 07:19

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.

luisherranz · 1 April 2020 10:40

This will work similarly to what we did for the CLI: Expose Frontity commands to be used programmatically

luisherranz · 7 April 2020 08:56

A post was split to a new topic: Frontity on WP Engine

luisherranz · 13 April 2020 10:07

I would like to add another setting which can be useful for multisite configurations.

Choose which Frontity site you want to use.

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= .

SantosGuillamot · 14 April 2020 07:26

Good one! I’ve added it to the opening post so we keep track there of all the possible settings.

luisherranz · 11 May 2020 18:50

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”.

Pablo · 11 May 2020 19:52

I agree with you @luisherranz, this is still a bit confusing. I think that your proposal would help to clarify this.

luisherranz · 16 May 2020 11:07

Thanks @pablo. I guess that nobody has additional complains, so I’m going to use these terms in the WCEU talk.

luisherranz · 4 June 2020 11:18

I have moved the proof of conecpt repository to the Frontity organization in GitHub and I have:

Renamed it to Frontity Embedded.
Added a proper Readme for people that want to test it out.
Added support for environment variables.
Added a bypass for previews, that fall back to the PHP theme.

The new URL is:

luisherranz · 30 September 2020 13:51

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!!

juanma · 13 October 2020 15:34

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”)

The current “Decoupled Mode”

This “Embedded Mode”

juanma · 22 October 2020 08:00

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?

SantosGuillamot · 17 December 2020 13:10

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.