A4A: Create a site from the licenses page without leaving it - #113355
A4A: Create a site from the licenses page without leaving it#113355jkguidaven wants to merge 3 commits into
Conversation
The Create site buttons on an unassigned WordPress.com license sent the agency to the Needs setup page, where they had to find the same license again before they could configure it. Open the site configuration modal in place instead, so creating a site is one step from the licenses list. Completing it lands on the sites dashboard, as it does from Needs setup. While a site is provisioning, the button now shows a spinner and is disabled, matching how the Needs setup page treats provisioning as an account-wide state. A license with no pending site to configure still falls back to the Needs setup page — the modal creates a development site when given no site ID. The modal is wrapped so its random-site-name lookup runs when it opens rather than once per license row.
|
WordPress.com
Automattic for Agencies
|
yashwin
left a comment
There was a problem hiding this comment.
Nice improvement — creating a site without leaving the licenses page removes a real detour. Left a few comments below.
The two bot comments above are worth addressing too — the return URL one especially, since landing back on the Needs setup page after adding a payment method goes against the point of this PR. The missing tracks event on the fallback is a nice-to-have.
- Reviewed with the help of my Claude agent and manually verified by me.
|
|
||
| return { | ||
| onCreateSite, | ||
| isProvisioning: hasProvisioningSite( pendingSites ), |
There was a problem hiding this comment.
While one site is provisioning, every unassigned WordPress.com license shows the spinner and “Creating site…”, not just the one being created. hasProvisioningSite is account-wide and the button uses the same flag for both the disabled state and the label.
Disabling all buttons is fine (matches the Needs setup page), but the label should only change on the license that’s actually provisioning. Suggest splitting the two signals:
// lib/pending-sites.ts
export function isLicenseProvisioning(
pendingSites: PendingSite[] | undefined,
licenseKey: string
): boolean {
return !! pendingSites?.some(
( { features } ) =>
features?.wpcom_atomic?.license_key === licenseKey &&
features?.wpcom_atomic?.state === 'provisioning'
);
}Then return both from the hook — isProvisioning: isLicenseProvisioning( pendingSites, licenseKey ) for the spinner/label, and a separate isDisabled: hasProvisioningSite( pendingSites ) for the account-wide lock.
There was a problem hiding this comment.
This is intentional. We need to disable this on both the Needs Setup and Licenses pages while provisioning is in progress.
This follows the same reasoning as our current implementation: we only allow one site to be provisioned at a time to avoid confusion and prevent conflicting provisioning requests.
| { isWPCOMHostingLicense ? translate( 'Create site' ) : translate( 'Assign license' ) } | ||
| licenseType === LicenseType.Partner && | ||
| ( isWPCOMHostingLicense ? ( | ||
| <CreateSiteButton |
There was a problem hiding this comment.
This button skips the payment-method check that createSite does in license-preview/index.tsx. So a user with no payment method gets blocked on the row button but can still open the modal from the expanded details. Same behavior as before the PR, but now that both paths share one hook it’s easy to align — worth applying the same gate here.
There was a problem hiding this comment.
Good catch. Moved the payment method check into the shared hook, so both the row button and the expanded details are gated the same way now.
| @@ -0,0 +1,38 @@ | |||
| export type PendingSite = { | |||
There was a problem hiding this comment.
Nit: the type declares features.wpcom_atomic as required, but the helpers use features?.wpcom_atomic?. optional chaining. Either mark them optional in the type or drop the chaining — as is, the type and the code disagree.
There was a problem hiding this comment.
Made both fields optional in the type. The endpoint is untyped and non-WordPress.com pending sites do not carry that block, so the optional chaining was the correct half.
| * Lets an unassigned WordPress.com license be turned into a site without | ||
| * leaving the licenses page, using the same configuration modal the Needs | ||
| * setup page opens. Falls back to that page when the license has no pending | ||
| * site to configure — the modal creates a development site when given no ID. |
There was a problem hiding this comment.
Nit: “the modal creates a development site when given no ID” — this wrapper always passes a siteId (it’s required by LicenseSiteConfigurationsModal), so that path can’t happen here. Suggest trimming the sentence.
There was a problem hiding this comment.
Good catch! This is indeed not needed. The createSite button will never show up anyway on a Development site.
There was a problem hiding this comment.
Trimmed that sentence.
Related to https://linear.app/a8c/issue/A4A-3165/a4a-wpcom-flow-efficiency-improvements
Proposed Changes
Why are these changes being made?
Testing Instructions
Pre-merge Checklist