Agentic UI: Site Creation - #3941
Conversation
…tion # Conflicts: # apps/studio/src/modules/sync/lib/ipc-handlers.ts
📊 Performance Test ResultsComparing 6ef4ab7 vs trunk app-size
site-editor
site-startup
Results are median values from multiple test runs. Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff) |
bcotrim
left a comment
There was a problem hiding this comment.
On this branch my Pressable site no longer shows up in the sync sites list — on
trunk it does. I traced it to the filter → filters rename on /me/sites
(756ed7c): the singular filter isn't a real API param so it's silently ignored
(all sites come back), while the corrected filters=atomic,wpcom actually filters
and drops Pressable (Jetpack-hosted, not Atomic/WPcom). Confirmed locally —
reverting just the rename brings the site back.
This is a regression, not just a behavior change: The filters filter is the right idea (it correctly drops a8c/non-syncable sites), it just shouldn't drop Pressable too.
Since this filtering + environment-label work (756ed7c + 12c975a) is unrelated
to the site-creation scope here, could we pull it into its own PR? That clears the
regression from this PR and lets us land the filtering properly with focused testing and discussion.
…uping in connect picker
…tion # Conflicts: # apps/ui/src/data/core/connectors/hosted/index.ts
…aged list client-side
## Related issues <!-- Link a related issue to this PR. If the PR does not immediately resolve the issue, for example, it requires a separate deployment to production, avoid using the "Fixes" keyword and use "Related to" instead. --> - First product increment from #3941 ## How AI was used in this PR <!-- Help reviewers understand what to look for and verify that you have reviewed the code yourself. --> Codex helped compare the original umbrella PR with current trunk, implement the scoped first increment, and add focused coverage. The resulting behavior, cleanup paths, and tests were manually reviewed. The updated visual design still needs human review in both color schemes. ## Proposed Changes <!-- Explain the intent of this PR: - What problem does it solve, or what need does it address? - How does it affect the user (new capability, fix, performance, accessibility, etc.)? - Note any user-visible behavior changes or trade-offs. Focus on the why and the user impact. Avoid listing modified files or describing implementation mechanics — the diff already shows that. --> - Give users one Create flow for blank sites and uploaded JSON or ZIP Blueprints, including full-window drop, replacement, removal, reset of prior untouched suggestions, and Blueprint deep-link handoff. - Preserve user-entered values while applying Blueprint suggestions only to pristine fields, and retain the existing path and WordPress-version reliability behavior. - Keep temporary uploads safe across selection, replacement, cancellation, creation, and failure recovery. - Make creation progress accessible, prevent route interaction and closing while creation is active, restore the flow after failure, and manage focus between onboarding routes. - Simplify onboarding around the currently working Create and Import jobs, redirect the legacy Blueprint route into Create, and remove the unused gallery surface. - Bring the updated onboarding design into the reduced flow with the animated dot-grid backdrop, illustrated job cards, frosted panels, responsive layouts, persistent footer actions, and compact Blueprint picker. ## Testing Instructions <!-- Add as many details as possible to help others reproduce the issue and test the fix. "Before / After" screenshots can also be very helpful when the change is visual. --> 1. Open onboarding and confirm the home screen shows the dot-grid backdrop, illustrated Create and Import cards, and persistent Back action when existing sites are present. Start Create and create a blank site. 2. Select JSON and ZIP Blueprints using the inline picker and full-window drop target. Confirm the selected file can be replaced or removed and that ZIP-relative assets still resolve during creation. 3. Edit the site name or path before selecting a Blueprint. Confirm suggestions fill pristine fields without overwriting dirty fields. 4. Open a Blueprint deep link and confirm it hands the uploaded Blueprint to `/onboarding/create`. 5. During creation, confirm the visible status is announced, route content is inert, Close is disabled, and route headings receive focus. Force a failure and confirm the form recovers. 6. Confirm uploaded and extracted temporary files are cleaned after invalid uploads, stale selections, replacement, removal, success, and failure. 7. Check the Create flow, selected Blueprint state, drop overlay, advanced settings, and progress state in both light and dark color schemes. ## Pre-merge Checklist <!-- Complete applicable items on this checklist **before** merging into trunk. Inapplicable items can be left unchecked. Both the PR author and reviewer are responsible for ensuring the checklist is completed. --> - [x] Have you checked for TypeScript, React or other console errors?
## Related issues <!-- Link a related issue to this PR. If the PR does not immediately resolve the issue, for example, it requires a separate deployment to production, avoid using the "Fixes" keyword and use "Related to" instead. --> - Split from #3941 - Follow-up work required in STU-1956 ## How AI was used in this PR <!-- Help reviewers understand what to look for and verify that you've reviewed the code yourself. --> Codex assisted with repository exploration, implementation, focused regression tests, and interactive UI verification. The lifecycle and rollback boundaries, connector contracts, and light/dark presentation were reviewed and iterated during development. ## Proposed Changes <!-- Explain the intent of this PR: - What problem does it solve, or what need does it address? - How does it affect the user (new capability, fix, performance, accessibility, etc.)? - Note any user-visible behavior changes or trade-offs. Focus on the "why" and the user impact. Avoid listing modified files or describing implementation mechanics — the diff already shows that. --> - Add Connect as an Add Site path where signed-out users can log in or sign up, then find and search all relevant WordPress.com and Pressable sites with clear environment, availability, and existing-connection information. - Create a local shell, persist its live-site relationship, and pull content into Studio with the correct rollback boundary: failures before persistence remove the shell, while later failures retain the connection for recovery. - Focus the new local site as soon as pulling begins, open its live progress, and let the user navigate elsewhere while detailed CLI progress continues in the site status and sidebar. Start the site automatically when the pull completes. - Remove every WordPress.com connection when a local site is deleted in Electron or local-web, with regression coverage for both paths. | Light | Dark | |--------|--------| | <img width="3248" height="2122" alt="image" src="https://github.com/user-attachments/assets/38eb267f-fc9a-4f86-8b3e-748d0945ed3a" /> | <img width="3248" height="2122" alt="image" src="https://github.com/user-attachments/assets/80bebd69-fea7-4a15-91fa-fedc7f5d3d90" /> | ## Testing Instructions <!-- Add as many details as possible to help others reproduce the issue and test the fix. "Before / After" screenshots can also be very helpful when the change is visual. --> 1. Launch the agentic UI and choose **Add site → Connect** while signed out. Verify both login and signup return to the Connect flow. 2. Test WordPress.com and Pressable sites. Search by name and URL, and verify available, unavailable, upgrade/transfer-required, and already-connected groups and explanations. 3. Connect an available site. Verify the shell is created without starting, the connection is saved, and Studio immediately focuses the local site with the pull status open. 4. Navigate to another site while pulling. Verify the sidebar continues to show activity and the detailed CLI pull message remains available on the connecting site. 5. Verify the site starts automatically after a successful pull and opens as a usable local copy. 6. Simulate a failure before connection persistence and verify the local shell and files are removed. 7. Simulate a pull/start failure after connection persistence and verify the local site and live relationship remain, with the failure shown in site status. 8. Delete a connected local site in Electron and local-web and verify every WordPress.com connection for that local site is removed. 9. Exercise offline, loading, empty, request-error, and retry states in light and dark color schemes. ## Pre-merge Checklist <!-- Complete applicable items on this checklist **before** merging into trunk. Inapplicable items can be left unchecked. Both the PR author and reviewer are responsible for ensuring the checklist is completed. --> - [x] Have you checked for TypeScript, React or other console errors?
|
Closing this one as it has been addressed in smaller PRs: |
Related issues
How AI was used in this PR
This PR is AI-assisted and intentionally large. AI was used to draft the initial agentic UI onboarding implementation, iterate on UI states, identify duplicated/default UI behavior, and review cross-app risk. The implementation has been manually reviewed and adjusted, especially around shared sync behavior, default UI impact, and WordPress.com site filtering.
Because of the PR size, reviewers should not treat the raw diff as the primary review artifact. Please use the review guide below to focus on the product and architecture decisions this code implies.
Executive summary
This PR adds an Add Site onboarding flow to the agentic UI (
apps/ui,ui-classic) so users can build a new site, start from a blueprint, import a backup, or connect a WordPress.com/Pressable site. The main intent is to bring the core Add Site flows into the agentic UI while the default Studio UI still exists.Some shared helpers were moved into
tools/commonso the default UI and agentic UI display the same blueprint curation, site thumbnails, and environment labels. The connect flow creates a local site shell, persists the WordPress.com connection, and starts a first pull from the live site. That lifecycle is intentionally not fully solved in this PR; durable first-pull lifecycle/error state is tracked separately in STU-1956.The most important review is not line-by-line CSS. Please focus on whether the flow boundaries, shared sync/API changes, and agentic-vs-default UI architecture are acceptable.
Proposed Changes
tools/commonso the default UI and agentic UI do not drift./me/sitesv1.3 API and the documentedfiltersparam.Review guide
Please focus review here
Overall Add Site flow shape
apps/ui/src/ui-classic/router/route-onboarding-home/index.tsxConnect remote site architecture
apps/ui/src/ui-classic/router/route-onboarding-connect/index.tsxapps/ui/src/data/queries/use-wpcom-sites.tsapps/studio/src/modules/sync/lib/ipc-handlers.tsShared sync/API behavior
tools/common/lib/sync/sync-api.tstools/common/lib/sync/transform-sites.tsapps/studio/src/stores/sync/wpcom-sites.tsapps/cli/lib/api.ts/me/sitesv1.3 pagination,filters=atomic,wpcom, staging/environment handling, and CLI/default UI impacts acceptable?Shared helpers extracted from default UI
tools/common/lib/blueprint-curation.tstools/common/lib/sync/environment-utils.tstools/common/lib/sync/mshots.tsState handoff patterns
apps/ui/src/lib/pending-slot.tsapps/ui/src/lib/pending-backup.tsapps/ui/src/lib/pending-blueprint.tsapps/ui/src/hooks/use-add-site-listener.tsOkay to skim
apps/ui.Diff breakdown
/me/sitesfetch now affects CLI sync site resolution; default UI staging/environment handling was aligned.Screenshots
Known tradeoffs / follow-ups
/me/sitesfetch now uses v1.3 pagination. This should improve large-account behavior, but it is shared with CLI/default UI and deserves review.Safety checklist
/me/sitesmoved to v1.3 for shared syncable-site fetching; uses documentedfiltersparam.Testing Instructions
Automated checks used during this PR:
npx eslint --fixon modified TypeScript/TSX filesnpm run typechecknpm test -- apps/ui/src/data/queries/use-wpcom-sites.test.tsx apps/ui/src/hooks/use-add-site-listener.test.tsxnpm -w @studio/ui run dev:web -- --host 127.0.0.1 --port 5300, then browser smoke checks for/onboarding,/onboarding/blueprint,/onboarding/create, and/onboarding/connectin light and dark color schemes. The standalone web target renders these routes; its expected backend-connection failures were filtered out of the console check.Suggested reviewer checks:
/me/sitesbehavior changed.Pre-merge Checklist