Embedded mode

Regarding this approach, as said below, it doesn’t work with services like Nginx. I think we should have in mind what @luisherranz explained here:

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 :smile: What do you think guys?

@SantosGuillamot

I think that the “Theme Bridge” is more like a tee than a “bridge”: :sweat_smile:

image

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 :sweat_smile:

Haha, nice one.

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

2 Likes

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

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?

  1. With an external domain.
  2. 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.

2 Likes

@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

1 Like

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

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

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

1 Like

Good one! :slightly_smiling_face: 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:

  • Decoupled mode.
  • Embedded mode.

And tell that “Frontity supports two modes, decoupled and embedded”.

3 Likes

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

2 Likes

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

1 Like

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:

6 Likes

We have added support for the post preview :tada:

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

1 Like

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”

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)

From this RoadMap presentation I don’t have clear if this “Embedded Mode” is the one in the list “Auto Embedded Mode” so is supposed to be one of the nest priorities

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?