WIP: Use selected site settings #1707
Conversation
brandonpayton
added
[Type] Bug
|
I am currently working through boot issues with this. The initial site boots, but selecting another site leads to a "Playground already booted" error. Planning to resume looking at this in the morning. |
This is a fragile change but should be only temporary as we try tighten up the site storage data model.
|
The already-booted message seems to have been caused by This is pretty messy stuff and will be until we finishing building out the models for temporary, browser-stored, and device-stored through redux. |
|
|
||
| collectWindowErrors(logger); | ||
|
|
||
| const query = new URL(document.location.href).searchParams; | ||
| const blueprint = await resolveBlueprint(); |
There was a problem hiding this comment.
To support switching between persisted sites, we can no longer just resolve the blueprint once in module scope but rather need to do it within the component every time the selected site changes or the site settings change.
There was a problem hiding this comment.
Blueprint, as in site setup steps, should only run once when a site is created. To load the site we only need the same runtime configuration, e.g. the PHP version.
The problem seems to be calling startPlaygroundWeb() twice in a row while targeting the same remote.html frame. We might need to rethink this flow entirely, e.g. create a new remote.html iframe instance for each booted site.
| * @param siteInfo The site info to convert to Playground query params | ||
| * @returns URL with query params representing the site info | ||
| */ | ||
| export function siteInfoToUrl(baseUrl: URL, siteInfo: SiteInfo): URL { |
There was a problem hiding this comment.
Aha! We've hit the runtime configuration vs site configuration problem (see "Runtime setup options"). This is an important one. Let's not rush a solution but take it slow and methodically. We're effectively building a v1 of the runtime configuration interface here.
Let's treat things like languages, themes, plugins, multisite etc. as build-time features that are only relevant when the site is first created. If we tried re-applying them to an existing site, we'd end up with, say, two copies of the same theme – that's not what the user expects.
That leaves us with settings that don't trigger any filesystem– or database–level updates in /wordpress. For sure that's networking, PHP version, and landing page. Probably also login, even though it causes some database writes. What else?
We don't yet have the plumbing to hotswap the WordPress version so let's remove the "WP Version" from the "edit site" form for now. Same for the language and the storage option. That's tangential but relevant.
Here's another question: When user changes the runtime configuration of an existing site, how will we save that information? We can either alter the original Blueprint, or store runtime configuration in another file. What would you do here?
Tangentially related: Down the road we will provide a way of applying a Blueprint to an existing site. At that time, we will want to combine the new Blueprint with the original one used to boot that site. There's nothing immediately actionable today. Regardless of the direction this PR takes, I'm just noticing the problem of rewriting/merging Blueprints will come back on more than one occasion.
There was a problem hiding this comment.
I wonder what would be the ripple effect of decoupling the runtime options across JS API, Blueprints API, Query API, if any.
For example, imagine a version of the Query API that distinguishes between "site build options" and "runtime options":
https://playground.wordpress.net/?build[plugin]=gutenberg&runtime[networking]=yes
These long names would be difficult to type and to remember so our current short parameters (?plugin=gutenberg&networking=yes) seem to be a more useful choice.
However, Blueprints and JS API are quite verbose already so maybe there may be an opportunity for an API refresh in there. If not, perhaps the documentation could distinguish between the two types of configuration options 🤔
There was a problem hiding this comment.
Also, notice this translates Blueprint->Query args only for Playground to do Query args->Blueprint. What if we passed the Blueprint directly? Or even just the site slug, since we know the config for each slug?
There was a problem hiding this comment.
It would be highly useful to have stable site URLs. Say I go to playground.wordpress.net/my–base–theme and it always brings up the same site. Also, the site itself wouldn't use a random numeric scope, but the slug
There was a problem hiding this comment.
Then we could pair that with github autocommit and offer public site urls, e.g. public.playground.wordpress.net/adamziel/blog
There was a problem hiding this comment.
And that could later form v1 of collaboration and site sync. Cc @akirk @griffbrad @dawidurbanski @dmsnell
|
I think #1731 supersedes this one so I'll go ahead and close. |
Motivation for the change, related issues
The settings for the selected site are not properly applied when switching between sites with the site switcher. This PR is meant to fix that.
Implementation details
TBD
Testing Instructions (or ideally a Blueprint)
TBD