Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blueprints Recorder #539

Open
akirk opened this issue Jun 9, 2023 · 10 comments
Open

Blueprints Recorder #539

akirk opened this issue Jun 9, 2023 · 10 comments

Comments

@akirk
Copy link
Member

akirk commented Jun 9, 2023

It'd be nice to have a way to just record the blueprint JSON through actions you do in WordPress and a WordPress plugin could capture that.

Two potential ways to implement this:

  1. It could send postMessages on events and the blueprints would be built in the WordPress playground,
  2. or you record the steps in the WordPress database and write the JSON in PHP and offer it as a download.
@adamziel
Copy link
Collaborator

adamziel commented Jun 14, 2023

@adamziel
Copy link
Collaborator

adamziel commented Jun 14, 2023

Blueprints are not interchangeable with user actions in wp-admin

Imagine you install a plugin that attaches a hook running on plugin upload. The installPlugin step won’t trigger that hook. Blueprint don’t upload plugins but install them programmatically. Then, the plugin can be configured by interacting with wp-admin. Maybe that's just updating wp_options, or maybe that's setting up and populating custom db tables like WooCommerce does. There are no Blueprint steps for some of these and it's unclear how these actions could be recorded.

We could perhaps record every successful POST request and pacify nonces and then replay it on Blueprint application, but:

  • Those recordings would get very large very quickly
  • If a plugin verifies, say, that $_POST['date'] is a future date, that log could not be replayed

Recording user interactions could probably work 80% of the time, but the remaining 20% of the cases would be either impossible or burdensome to fix and maintain.

Alternative idea: diffs

To catch all site customizations, we need to export all files and a database. This feature already exists and can be used via the replaceSite Blueprint step.

The only improvement is reducing the bundle size. Right now it contains all WordPress core files and a full database. Perhaps it could consist of just the diff. Also, directory plugins and themes could still point to the directory, no need to include them in the diff.

The only problem with such a diff is that it wouldn’t cleanly apply against all WordPress versions. If it only adds plugin files, uploads, and db records - maybe it would. But if it also updates any existing core files, that would be challenging. The tool could detect any incompatible changes and fall back to a full export.

There is a downside, though - such a diff wouldn’t be easily composable like Blueprints sre.

Combining both ideas - Blueprint valet

With a smart diffing mechanism, the recorder could keep a “best effort” track of actual Blueprint steps and expose them to the developer not as a final product but as a starting point for development. Detecting any unrecordable SQL or filesystem changes would alert the user and fall back to the export feature.

cc @danielbachhuber who explored similar questions in a tool called Dictator

@adamziel
Copy link
Collaborator

adamziel commented Oct 25, 2023

About the recordings, they may not work for producing Blueprints, but they could still be useful for E2E testing.

Chrome Devtools recorder produces the following JSON file that Playground could reuse:

Recording 25.10.2023 at 12_09_38.json

That recording could potentially be replayed in Playwright to get a trace file that could be then inspected at https://trace.playwright.dev/ (thanks @kevin940726!)

Also, there's this browser for recording website interactions: https://www.replay.io/


For site setups, the recorded could perhaps export not a Blueprint but a complete WordPress site (without the core PHP files perhaps) that could be restored in Playground, wp-now, or hosted almost as is.

@adamziel adamziel changed the title Create a Blueprints Recorder WordPress plugin Blueprints Recorder Nov 22, 2023
@adamziel adamziel mentioned this issue Nov 25, 2023
@adamziel
Copy link
Collaborator

Here’s how all the ideas went:

I don’t believe anything more is technically possible. It’s the same problem as inferring a Dockerfile from a docker image — the only way seems to be reading the original Dockerfile from a cache.

I’m going to close this issue. Let’s explore a larger problem of making site/Blueprint setup easy separately. Perhaps a better setup UI on playground.wordpress.net would suffice.

@adamziel adamziel closed this as not planned Won't fix, can't repro, duplicate, stale Jan 23, 2024
@draganescu
Copy link

Recording user interactions could probably work 80% of the time, but the remaining 20% of the cases would be either impossible or burdensome to fix and maintain.

Isn't 80/20 quite good actually? I believe visually recording a blueprint from my WP admin actions - even if that supports only a smaller subset of all possibilities - would be amazing!

@adamziel
Copy link
Collaborator

adamziel commented Mar 4, 2024

@draganescu The more I think about this, the more I agree. Playground would just need to clearly communicate the limitations. @jdevalk I know you've been exploring such a recorder – is it available anywhere in GitHub? Would you be interested in bringing that feature into core?

@adamziel adamziel reopened this Mar 4, 2024
@jdevalk
Copy link
Contributor

jdevalk commented Mar 4, 2024

Absolutely. I’ll put it on GitHub! Gimme 24 hours

@adamziel
Copy link
Collaborator

adamziel commented Mar 4, 2024

Thank you so much @jdevalk! cc @ndiego @bgrgicak

@jdevalk
Copy link
Contributor

jdevalk commented Mar 6, 2024

My code is here: https://github.com/emilia-Capital/blueprint-builder

@bgrgicak
Copy link
Collaborator

bgrgicak commented Mar 7, 2024

My code is here: https://github.com/emilia-Capital/blueprint-builder

Thank you @jdevalk!

@adamziel Looking at the code it adds a method to get every blueprint functionality and creates an export file for data. Some features are missing, but they should be easy to add.
This code is a good fit for the Playground plugin.

@adamziel adamziel moved this to Project: Up Soon in Playground Board Jun 30, 2024
@adamziel adamziel moved this from Project: Triage to Project: Not now in Playground Board Jul 1, 2024
brandonpayton added a commit that referenced this issue Sep 27, 2024
… WebApp Redesign (#1731)

## Description

Implements a large part of the [website
redesign](#1561):

![CleanShot 2024-09-14 at 10 24
57@2x](https://github.com/user-attachments/assets/f245c7ac-cb8c-4e5a-b90a-b4aeff802e7b)


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](https://playground.wordpress.net/demos/) right into the
Playground app.

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

* #1438 – no
more losing your work by accident 🎉
* #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](https://core.trac.wordpress.org/ticket/60375).
   * A "Sync two Playgrounds" feature, pioneering the Site Sync Protocol
* #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.
* #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
* #1056 – Site
transfer protocol will unlocks seamlessly passing Playgrounds between
the browser and a local development environment
* #1558 – we'll
integrate [the Blueprints directory] and offer single-click Playground
setups, e.g. an Ecommerce store or a Slide deck editor.
#718.
* #539 – the
recorded Blueprints would be directly editable in Playground and perhaps
saved as a new Playground template
* #696 – the new
interaction model creates space for additional integrations.
* #707 – you
could create a "GitHub–synchronized" Playground
* #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
* #768 – the new
UI has space for a "new in Playground" section, similar to what Chrome
Devtools do
* #629  
* #32
* #104
* #497
* #562
* #580 

### Remaining work

- [ ] Write a release note for https://make.wordpress.org/playground/
- [x] Make sure GitHub integration is working. Looks like OAuth
connection leads to 404.
- [x] Fix temp site "Edit Settings" functionality to actually edit
settings (forking a temp site can come in a follow-up PR)
- [x] Fix style issue with overlapping site name label with narrow site
info views
- [x] Fix style issue with bottom "Open Site" and "WP Admin" buttons
missing for mobile viewports
- [x] Make sure there is a path for existing OPFS sites to continue to
load
- [x] Adjust E2E tests.
- [x] Reflect OPFS write error in UI when saving temp site fails
- [x] Find a path forward for
[try-wordpress](https://github.com/WordPress/try-wordpress) to continue
working after this PR
- [x] Figure out why does the browser get so choppy during OPFS save. It
looks as if there was a lot of synchronous work going on. Shouldn't all
the effort be done by a worker a non-blocking way?
- [x] Test with Safari and Firefox. Might require a local production
setup as FF won't work with the Playground dev server.
- [x] Fix Safari error: `Unhandled Promise Rejection: UnknownError:
Invalid platform file handle` when saving a temporary Playground to
OPFS.
- [x] Fix to allow deleting site that fails to boot. This is possible
when saving a temp site fails partway through.
- [x] Fix this crash:

```ts
		/**
		 * @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)));
```
- [x] Test different scenarios manually, in particular those involving
Blueprints passed via hash
- [x] Ensure we have all the aria, `name=""` etc. accessibility
attributes we need, see AXE tools for Chrome.
- [x] Update developer documentation on the `storage` query arg (it's
removed in this PR)
- [x] Go through all the `TODOs` added in this PR and decide whether to
solve or punt them
- [x] Handle errors like "site not found in OPFS", "files missing from a
local directory"
- [x] Disable any `Local Filesystem` UI in browsers that don't support
them. Don't just hide them, though. Provide a help text to explain why
are they disabled.
- [x] Reduce the naming confusion, e.g. `updateSite` in redux-store.ts
vs `updateSite` in `site-storage.ts`. What would an unambiguous code
pattern look like?
- [x] Find a reliable and intuitive way of updating these deeply nested
redux state properties. Right now we do an ad-hoc recursive merge that's
slightly different for sites and clients. Which patterns used in other
apps would make it intuitive?
- [x] Have a single entrypoint for each logical action such as "Create a
new site", "Update site", "Select site" etc. that will take care of
updating the redux store, updating OPFS, and updating the URL. My ideal
scenario is calling something like `updateSite(slug, newConfig)` in a
React Component and being done without thinking "ughh I still need to
update OPFS" or "I also have to adjust that .json file over there"
- [x] Fix all the tiny design imperfections, e.g. cut-off labels in the
site settings form.

### Follow up work

- [ ] Mark all the related blocked issues as unblocked on the project
board, e.g.
#1703,
#1731, and more –
[see the All Tasks
view](https://github.com/orgs/WordPress/projects/180/views/2?query=sort%3Aupdated-desc+is%3Aopen&filterQuery=status%3A%22Up+next%22%2C%22In+progress%22%2C%22Needs+review%22%2C%22Reviewed%22%2C%22Done%22%2CBlocked)
- [ ] Update WordPress/Learn#1583 with info
that the redesign is now in and we're good to record a video tutorial.
- [ ] #1746
- [ ] Write a note in [What's new for developers? (October
2024)](WordPress/developer-blog-content#309)
- [ ] Document the new site saving flow in
`packages/docs/site/docs/main/about/build.md` cc @juanmaguitar
- [ ] Update all the screenshots in the documentation cc @juanmaguitar 
- [ ] When the site fails to load via `.list()`, still return that
site's info but make note of the error. Not showing that site on a list
could greatly confuse the user ("Hey, where did my site go?"). Let's be
explicit about problems.
- [ ] Introduce notifications system to provide feedback about outcomes
of various user actions.
- [ ] Add non-minified WordPress versions to the "New site" modal.
- [ ] Fix `console.js:288 TypeError: Cannot read properties of undefined
(reading 'apply') at comlink.ts:314:51 at Array.reduce (<anonymous>) at
callback (comlink.ts:314:29)` – it seems to happen at trunk, too.
- [ ] Attribute log messages to the site that triggered them.
- [ ] Take note of any interactions that we find frustrating or
confusing. We can perhaps adjust them in a follow-up PR, but let's make
sure we notice and document them here.
- [ ] Solidify the functional tooling for transforming between `URL`,
`runtimeConfiguration`, `Blueprint`, and `site settings form state` for
both OPFS sites and in-memory sites. Let's see if we can make it
reusable in Playground CLI.
- [ ] Speed up OPFS interactions, saving a site can take quite a while.
- [ ] A mobile-friendly modal architecture that doesn't stack modals,
allows dismissing, and understands some modals (e.g. fatal error report)
might have priority over other modals (e.g. connect to GitHub). Discuss
whether modals should be declared at the top level, like here, or
contextual to where the "Show modal" button is rendered.
- [ ] Discuss the need to support strong, masked passwords over a simple
password that's just `"password"`.
- [ ] Duplicate site feature implemented as "Export site + import site"
with the new core-first PHP tools from
adamziel/wxr-normalize#1 and
https://github.com/adamziel/site-transfer-protocol
- [x] Retain temporary sites between site changes. Don't just trash
their iframe and state when the user switches to another site.

Closes #1719

cc @brandonpayton

---------

Co-authored-by: Brandon Payton <[email protected]>
Co-authored-by: Bero <[email protected]>
Co-authored-by: Bart Kalisz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

5 participants