Implement the /publish slash command to push local sites to WP.com

[katinthehatsite]

Related issues

Fixes STU-1552

How AI was used in this PR

Proposed Changes

This PR adds a /publish command for publishing local sites to WP.com.

Testing Instructions

• Pull the changes from this branch
• Build CLI with npm run cli:build
• Launch Studio code with node apps/cli/dist/cli/main.mjs code
• Ensure that you have no sites selected first
• Type publish
• Confirm that you are encouraged to select a site

• Once the site is selected, type /publish again
• Select a remote site to publish to
• Start push process
• Confirm that it goes through
• Then, test with /publish command for an account that does not have any remote sites (you can use this diff and will need to rebuild CLI):

index e56a72b16..ebf34e5de 100644
--- a/apps/cli/ai/slash-commands.ts
+++ b/apps/cli/ai/slash-commands.ts
@@ -515,7 +515,7 @@ export const AI_CHAT_SLASH_COMMANDS: SlashCommandDef[] = [
                                ctx.ui.showProgress( __( 'Fetching your WordPress.com sites…' ) );
                                ctx.ui.setBusy( true );
 
-                               const remoteSites = await fetchSyncableSites( token.accessToken );
+                               const remoteSites: Awaited< ReturnType< typeof fetchSyncableSites > > = []; // TODO: remove mock
                                const syncable = remoteSites.filter( ( s ) => s.syncSupport === 'syncable' );
 
                                if ( syncable.length === 0 ) {

• Confirm it opens a link in the browser if you have no WP.com sites:

* Try using the `/publish` command when you are logged out and confirm that you are asked to login first

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 336fee9 vs trunk

app-size

Metric	trunk	336fee9	Diff	Change
App Size (Mac)	1316.83 MB	1316.83 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	336fee9	Diff	Change
load	744 ms	1099 ms	+355 ms	🔴 47.7%

site-startup

Metric	trunk	336fee9	Diff	Change
siteCreation	6496 ms	6516 ms	+20 ms	⚪ 0.0%
siteStartup	1864 ms	1856 ms	8 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[nightnei]

Hm, I always get this error. @katinthehatsite coudl you please double test to ensure that it's my local issue?

UPDATE: push via Studio app works well

UPDATE 2: it was my local issue with sqlite-database-integration

[katinthehatsite]

Did it end up working at the end @nightnei ? The flow is reusing the existing mechanism so it should work the same across this command, Studio app UI etc.

[nightnei]

Works great and LGTM

[nightnei]

Did it end up working at the end @nightnei ? The flow is reusing the existing mechanism so it should work the same across this command, Studio app UI etc.

Yep, I was using incorrect sqlite-database-integration

[youknowriad]

Hey folks thanks for working on this, I have a couple of questions/suggestions.

• This command seems to do the exact same thing as the "push" tool we have in Studio Code already. The main difference seems to be that it shows a list of sites to pick from instead of relying on the user prompt. Am I correct? Should we unify these under the same push tool. In other words, maybe the push tool should be smart enough to show the selector if it can't guess the destination from the user prompt.

• It would be very interesting to support creating a new site in all of these (push/publish agent tools and the CLI push command).

[nightnei]

• This command seems to do the exact same thing as the "push" tool we have in Studio Code already. The main difference seems to be that it shows a list of sites to pick from instead of relying on the user prompt. Am I correct? Should we unify these under the same push tool. In other words, maybe the push tool should be smart enough to show the selector if it can't guess the destination from the user prompt.

Yes, you are right.
And regarding unification, I agree, I think it's the right direction.
Also, I think it's better to discuss it more in STU-1581, as this PR is part of that conversation, and it seems that we didn't end up with some specific dirrection there yet.