[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

adamziel · 2024-09-05T10:59:29Z

Description

Implements a large part of the website redesign:

High-level changes shipped in this PR:

Multiple Playgrounds. Every temporary Playground can be saved either in the browser storage (OPFS) or in a local directory (Chrome desktop only for now).
New Playground settings options: Name name, language, multisite
URL as the source of truth for the application state
State management via Redux

This work is a convergence of 18+ months of effort and discussions. The new UI opens relieves the users from juggling ephemeral Playgrounds and losing their work. It opens up space for long-lived site configurations and additional integrations. We could bring over all the PR previewers and demos right into the Playground app.

Here's just a few features unblocked by this PR:

Save Playgrounds by default to avoid data loss #1438 – no more losing your work by accident 🎉
Sync Protocol #797 – with multiple sites we can progressively build features we'll eventually propose for WordPress core:
- A Playground export and import feature, pioneering the standard export format for WordPress sites.
- A "Clone this Playground" feature, pioneering the Site Transfer Protocol.
- A "Sync two Playgrounds" feature, pioneering the Site Sync Protocol
Improving "Export Pull Request to Github" functionality #1445 – better git support is in top 5 most highly requested features. With multiple Playgrounds, we can save your work and get rid of the "save your work before connecting GitHub or you'll lose it" and cumbersome "repo setup" forms on every interaction. Instead, we can make git operations like Pull, Commit, etc. very easy and even enable auto-syncing with a git repository.
Blueprints: Transition from a TypeScript library to a PHP library #1025 – as we bring in more PHP plumbing into this repository, we'll replace the TypeScript parts with PHP parts to create a WordPress core-first Blueprints engine
A Playground server package #1056 – Site transfer protocol will unlocks seamlessly passing Playgrounds between the browser and a local development environment
Tracking: WordPress-powered Apps #1558 – we'll integrate [the Blueprints directory] and offer single-click Playground setups, e.g. an Ecommerce store or a Slide deck editor.
Use Theme Unit Test Data as a starter content #718.
Blueprints Recorder #539 – the recorded Blueprints would be directly editable in Playground and perhaps saved as a new Playground template
Pull Request previewer for all WordPress projects #696 – the new interaction model creates space for additional integrations.
Static site generator #707 – you could create a "GitHub–synchronized" Playground
Block theme builder on WordPress.org #760 – we can bootstrap one inside Playground using a Blueprint and benefit the users immediately, and then gradually work towards enabling it on WordPress.org
Communicate new features #768 – the new UI has space for a "new in Playground" section, similar to what Chrome Devtools do
Idea: Add code editor for PHP files #629
Run the same WordPress instance across many browser tabs #32
Extend towards full dev environment #104
Website: Onboarding modal for new users #497
Storage adapters #562
Shareable Playground links #580

Breaking changes

TODO

Remaining work

		/**
		 * @TODO: Fix OPFS site storage write timeout that happens alongside 2000
		 *        "Cannot read properties of undefined (reading 'apply')" errors here:
		 * I suspect the postMessage call we do to the safari worker causes it to
		 * respond with another message and these unexpected exchange throws off
		 * Comlink. We should make Comlink ignore those.
		 */
		// redirectTo(PlaygroundRoute.site(selectSiteBySlug(state, siteSlug)));

Follow up work

Closes #1719

cc @brandonpayton

WIP

…rams

brandonpayton · 2024-09-05T19:59:41Z

I've been reading over this and hope to contribute later today. (But if you happen to finish it, @adamziel, that is fine and good too :)

packages/playground/website/src/lib/router-hooks.ts

brandonpayton · 2024-09-05T21:03:58Z

packages/playground/website/src/lib/redux-store.ts

 	},
 	reducers: {
-		setPlaygroundClient: (
+		setActiveSite: (state, action: PayloadAction<SiteInfo>) => {
+			state.activeSite = action.payload;


Should we check whether the site is part of the current sites list?

packages/playground/website/src/lib/redux-store.ts

packages/playground/website/src/lib/router-hooks.ts

adamziel · 2024-09-05T21:46:45Z

I've been reading over this and hope to contribute later today. (But if you happen to finish it, @adamziel, that is fine and good too :)

Yay! I'm wrapping up for now so feel free to take over

adamziel · 2024-09-05T21:54:16Z

packages/playground/website/src/lib/site-storage.ts

@@ -22,7 +23,8 @@ const SITE_METADATA_FILENAME = 'playground-site-metadata.json';
 * NOTE: We are using different storage terms than our query API in order
 * to be more explicit about storage medium in the site metadata format.
 */
-export type SiteStorageType = 'temporary' | 'opfs' | 'local-fs';
+export const SiteStorageTypes = ['opfs', 'local-fs', 'none'] as const;


I temporarily changed all the storage options naming to these three, but before this PR is merged I'd love to ensure the Query API keeps working with today's storage options names.

It would be great if we could block merging PRs that contain changes with some special TODO pattern like @BEFORE-MERGE, so we could leave inline notes for ourselves and be stopped from merging if we forget to address them.

Actually, we could just do this with a CI test.

I would love that!

With this particular change, though, we may not need to do that since the storage Query API parameter is gone. Developer documentation will need updating for sure.

packages/playground/website/src/lib/site-storage.ts

brandonpayton · 2024-09-05T22:02:25Z

packages/playground/website/src/lib/site-storage.ts

+		wpVersion:
+			resolvedBlueprint.preferredVersions?.wp ||
+			LatestMinifiedWordPressVersion,
+		phpVersion: resolveVersion(


What if we allow site info to specify an unsupported PHP version and simply warn in the UI and tell the user how it will be handled by the runtime?

Over time, previous site configurations may have PHP versions that are no longer supported, and IMO, it would be better not to lose the information that a site was created for a now-unsupported PHP version. And if a site is now fataling due to back-compat breaks between the requested and actual PHP versions, it would give the user a chance to understand why.

Great point ❤️ Let's do that.

...ges/playground/website/src/components/ensure-playground-site/ensure-playground-site-slug.tsx

brandonpayton · 2024-09-06T02:44:50Z

...yground/website/src/components/ensure-playground-site/ensure-playground-site-is-selected.tsx

+			if (requestedSiteSlug !== 'create') {
+				const siteInfo = await getSiteInfoBySlug(requestedSiteSlug!);
+				console.log({ siteInfo });
+				dispatch(setActiveSite(siteInfo!));


What if the identified site does not exist?

One scenario:

User bookmarks Playground link for specific site slug/ID

User deletes site, perhaps unintentionally, or clears browser storage

User visits bookmark

We need a notification system to tell the user what happened as we redirect to the first site that exists. There are WordPress components for that. It should be fine to delay that to another PR.

packages/playground/website/src/components/ensure-playground-site/index.tsx

brandonpayton · 2024-09-26T20:39:33Z

It looks like we have code so there should be footer buttons, so this should be fairly straightforward to fix...

Check out #1759, I've adjusted how the panel works there – perhaps it will solve the problem here.

Thanks, @adamziel. Will do :)

Btw, I also noticed some errors with importing from Zip and GitHub integration auth and will be looking at those also.

The import error is database related, and I'm not sure if it has to do with a conflicting WP version or something else. The GitHub issue is that the OAuth connection flow led me to a GH page with a 404 response.

brandonpayton · 2024-09-26T20:48:37Z

And local directory storage is currently broken for Chrome because:

Uncaught (in promise) InvalidStateError: Failed to execute 'createSyncAccessHandle' on 'FileSystemFileHandle': Access Handles may only be created on temporary file systems

This is because I converted file writing to use createSyncAccessHandle exclusively because it was a single code path and tested as faster or as fast everywhere. I can revert that change.

adamziel · 2024-09-26T21:03:19Z

@brandonpayton would it be easy to keep using the sync handles? They're much faster in general.

…en faster in testing" This reverts commit 6169c26.

brandonpayton · 2024-09-26T21:20:53Z

@brandonpayton would it be easy to keep using the sync handles? They're much faster in general.

@adamziel, the problem was that we were using sync handles everywhere (or did you mean to suggest async handles where possible?). Writing to the local FS in Chrome requires using createWritable(), so I switched back to using that interface for browsers that support it.

But if you indeed mean to suggest we stick with the sync interface where possible, I can add an exception handler to fall back to createWritable() when createSyncAccessHandle() doesn't work and the former interface is available.

brandonpayton · 2024-09-26T21:23:39Z

I found an timing issue with converting legacy OPFS sites in Chrome Canary. Sometimes deleting the old site directory after mounting the new one fails due to a write conflict, and I wonder if it has something to do with journaling FS events to the legacy dir.

brandonpayton · 2024-09-26T21:25:04Z

And local directory storage is currently broken for Chrome because:

Uncaught (in promise) InvalidStateError: Failed to execute 'createSyncAccessHandle' on 'FileSystemFileHandle': Access Handles may only be created on temporary file systems

OK, this is fixed now by falling back to the createWritable() interface. And if we want to continue using createSyncAccessHandle as much as possible, I can make that change.

brandonpayton · 2024-09-27T03:37:22Z

I added the few remaining items to the checklist:

Make sure GitHub integration is working. Looks like OAuth connection leads to 404.

Fix style issue with overlapping site name label with narrow site info views

Fix style issue with bottom "Open Site" and "WP Admin" buttons missing for mobile viewports

brandonpayton · 2024-09-27T04:30:38Z

Fixed the overlapping name text.

From:

To:

…m of page

brandonpayton · 2024-09-27T04:59:21Z

It turns out the missing "Homepage" and "WP Admin" buttons in mobile layout were due to the Temporary site notice pushing them off the bottom of the page. I fixed that somewhat, but there are still page heights where they start being forced off the bottom of the screen. What I'd prefer in that case is for the center info panel to shrink vertically and become scrollable.

brandonpayton · 2024-09-27T05:39:53Z

OK, I fixed the bottom site info buttons being hidden for some mobile screen dimensions.

Fix issue with Edit Settings for Temp site showing different random name

This is not a logic bug but is currently a UX bug. The truth is that update settings for a Temporary site actually creates a new temporary site. Yet the link people click to do this says "Edit Site Settings", and the submit button on the settings dialog says "Update" which implies updating rather than creating a new thing.

brandonpayton · 2024-09-27T05:44:22Z

Fix issue with Edit Settings for Temp site showing different random name

This is not a logic bug but is currently a UX bug. The truth is that update settings for a Temporary site actually creates a new temporary site. Yet the link people click to do this says "Edit Site Settings", and the submit button on the settings dialog says "Update" which implies updating rather than creating a new thing.

For this PR, I think it makes more sense to have this button just edit the actual temp site settings, and if we want a way to create a fork of the current temp site, that should be via a separate button in a follow-up PR.

Updated the TODO to be:

Fix temp site "Edit Settings" functionality to actually edit settings (forking a temp site can come in a follow-up PR)

bgrgicak · 2024-09-27T06:31:22Z

Should the site manager be closed by default so users see a running site before anything else?

Yes, on small screens when the preview isn't available.

On mobile, you will first see the menu, click on the menu to see your settings, and click on the Homepage button to get to the actual site.

This isn't an issue when the preview is visible because you can see the site and the full view is just one click away.

adamziel · 2024-09-27T07:57:14Z

For this PR, I think it makes more sense to have this button just edit the actual temp site settings, and if we want a way to create a fork of the current temp site, that should be via a separate button in a follow-up PR.

We don't have the plumbing to, e.g., change the WordPress version. I'd just change the label on that button to "Create a similar Playground" or so for now.

brandonpayton · 2024-09-27T15:41:03Z

The GH OAuth issue appears to be related to a testing detail on my end. And @adamziel fixed the temp site editing concern.

I think we are good to ship this.

adamziel · 2024-09-27T21:51:10Z

Let's make sure we don't default to the sidebar view on mobile.

Edit: Done in a415c79

## Motivation for the change, related issues #1731 introduced multiple Playground management. However, visiting a URL containing a Blueprint sometimes led to a creation of multiple temporary sites due to a React effect running twice. This PR prevents that error by delaying the new site creation until the effect settles down. In particular, we're waiting for the site list to either get loaded or error out. ## Testing Instructions (or ideally a Blueprint) Go to http://localhost:5400/website-server/?plugin=classic-editor&blueprint-url=https%3A%2F%2Fwordpress.org%2Fplugins%2Fwp-json%2Fplugins%2Fv1%2Fplugin%2Fclassic-editor%2Fblueprint.json%3Frev%3D3158978%26lang%3Den_US and confirm you only got a single temporary site

## Motivation for the change, related issues Some Playwright tests were broken by last-minute changes to #1731. Fixes #1818 ## Implementation details - Fix selection of "edit settings" and "save settings" buttons to select "Create a similar Playground" and "Create" buttons instead. - Change playground viewport selection to account for there being multiple possible viewports now. We were using an ID, but now we're using a CSS class. - Some expect() calls were failing, at least locally, and that was fixed by awaiting them. They need to be async. ## Testing Instructions (or ideally a Blueprint) - CI

Bring in a router and ensure site-slug is always present in the URL

cddec5e

WIP

adamziel added [Type] Developer Experience [Focus] Developer Tools [Type] UI / UX / User Experience [Aspect] Website and removed [Type] Developer Experience labels Sep 5, 2024

adamziel added 3 commits September 5, 2024 14:24

Move Playground boot to an isolated component that responds to URL pa…

dad4104

…rams

Temporarily rename "browser" storage to "opfs". TODO: Rename it back

1549065

Fix sidebar navigation

60a7465

brandonpayton reviewed Sep 5, 2024

View reviewed changes

packages/playground/website/src/lib/router-hooks.ts Outdated Show resolved Hide resolved

adamziel added 5 commits September 5, 2024 22:19

Store Playground client in the redux store

d25b5e6

Get initial Playground boot to work

6bb40a4

Use the correct OPFS mount handle when booting

9158c0b

Remove siteViewRef

51d5abf

Display the initial selected site info in the site manager

7d4726c

brandonpayton reviewed Sep 5, 2024

View reviewed changes

Rip out PlaygroundContext

f211db9

brandonpayton reviewed Sep 5, 2024

View reviewed changes

packages/playground/website/src/lib/redux-store.ts Outdated Show resolved Hide resolved

brandonpayton reviewed Sep 5, 2024

View reviewed changes

packages/playground/website/src/lib/redux-store.ts Outdated Show resolved Hide resolved

brandonpayton reviewed Sep 5, 2024

View reviewed changes

packages/playground/website/src/lib/redux-store.ts Outdated Show resolved Hide resolved

brandonpayton reviewed Sep 5, 2024

View reviewed changes

packages/playground/website/src/lib/router-hooks.ts Outdated Show resolved Hide resolved

adamziel commented Sep 5, 2024

View reviewed changes

Remove unnecessary useCallback usage

9e5ad4a

brandonpayton reviewed Sep 6, 2024

View reviewed changes

...ges/playground/website/src/components/ensure-playground-site/ensure-playground-site-slug.tsx Outdated Show resolved Hide resolved

brandonpayton reviewed Sep 6, 2024

View reviewed changes

...ges/playground/website/src/components/ensure-playground-site/ensure-playground-site-slug.tsx Outdated Show resolved Hide resolved

brandonpayton reviewed Sep 6, 2024

View reviewed changes

packages/playground/website/src/components/ensure-playground-site/index.tsx Outdated Show resolved Hide resolved

brandonpayton added 2 commits September 26, 2024 17:17

Revert "Use createSyncAccessHandle for all browsers because it has be…

df2eeb4

…en faster in testing" This reverts commit 6169c26.

Add more log messages for moving legacy OPFS sites

0dcf4ac

Speed up saving site to local FS

dc1217d

Stop overlapping text with long name in site info view

568b9a4

brandonpayton added 2 commits September 27, 2024 00:44

Stop temp site notice from forcing mobile open-site buttons off botto…

7e6e7b2

…m of page

Make open-site label consistent among site info view buttons

da2fb8d

More fixes for bottom buttons in mobile site info view

886648a

Differentiate between SiteCreateButton and StartSimilarSiteButton

49f335f

brandonpayton merged commit 39d0023 into trunk Sep 27, 2024
5 of 6 checks passed

brandonpayton deleted the routing branch September 27, 2024 17:00

This was referenced Sep 27, 2024

Language switcher #199

Closed

[Website] Prevent creation of two temporary sites #1817

Merged

brandonpayton mentioned this pull request Sep 28, 2024

Fix broken Playwright tests #1819

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

adamziel commented Sep 5, 2024 •

edited

Loading

brandonpayton commented Sep 5, 2024

brandonpayton Sep 5, 2024

adamziel commented Sep 5, 2024

adamziel Sep 5, 2024

brandonpayton Sep 6, 2024 •

edited

Loading

brandonpayton Sep 6, 2024

adamziel Sep 6, 2024

brandonpayton Sep 5, 2024

adamziel Sep 6, 2024

brandonpayton Sep 6, 2024

adamziel Sep 6, 2024 •

edited

Loading

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

adamziel commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

bgrgicak commented Sep 27, 2024 •

edited

Loading

adamziel commented Sep 27, 2024 •

edited

Loading

brandonpayton commented Sep 27, 2024

adamziel commented Sep 27, 2024 •

edited

Loading

[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

[UX] Stored Playgrounds (no more data loss), multiple Playgrounds, UI WebApp Redesign #1731

Conversation

adamziel commented Sep 5, 2024 • edited Loading

Description

Breaking changes

Remaining work

Follow up work

brandonpayton commented Sep 5, 2024

brandonpayton Sep 5, 2024

Choose a reason for hiding this comment

adamziel commented Sep 5, 2024

adamziel Sep 5, 2024

Choose a reason for hiding this comment

brandonpayton Sep 6, 2024 • edited Loading

Choose a reason for hiding this comment

brandonpayton Sep 6, 2024

Choose a reason for hiding this comment

adamziel Sep 6, 2024

Choose a reason for hiding this comment

brandonpayton Sep 5, 2024

Choose a reason for hiding this comment

adamziel Sep 6, 2024

Choose a reason for hiding this comment

brandonpayton Sep 6, 2024

Choose a reason for hiding this comment

adamziel Sep 6, 2024 • edited Loading

Choose a reason for hiding this comment

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

adamziel commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 26, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

brandonpayton commented Sep 27, 2024

bgrgicak commented Sep 27, 2024 • edited Loading

adamziel commented Sep 27, 2024 • edited Loading

brandonpayton commented Sep 27, 2024

adamziel commented Sep 27, 2024 • edited Loading

adamziel commented Sep 5, 2024 •

edited

Loading

brandonpayton Sep 6, 2024 •

edited

Loading

adamziel Sep 6, 2024 •

edited

Loading

bgrgicak commented Sep 27, 2024 •

edited

Loading

adamziel commented Sep 27, 2024 •

edited

Loading

adamziel commented Sep 27, 2024 •

edited

Loading