Consider supporting trunk/nightly WordPress version #1072

bcotrim · 2025-03-14T19:12:19Z

Related issues

Fixes STU-78

Proposed Changes

Updated getWordPressVersionUrl to return nightly build URL for development versions
Enhanced WordPress versions fetching to include both stable and development versions
Added test coverage

Add Site	Site Settings	Edit Site

Testing Instructions

Using the "Add site" or "Onboarding" workflows, confirm that the wordpress version dropdown includes a nightly build.
Start a new site with a nightly version and confirm it was installed successfully
Go to the Settings tab and confirm the version is shown correctly (here it should display the full version, instead of nightly)
.- Open "Edit site"
Confirm the nightly version is selected
Try changing the version and confirm the installation is successful
Add a new site with a non nightly version
Go to the Settings tab and "Edit Site"
Confirm nightly version option is available in the WordPress version dropdown
Change the version to the nightly and save to confirm the update is successful

Pre-merge Checklist

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

sejas

Good first approach. I see the new nightly option in the dropdown.

I see two possible options here. The premise is that users might want to update their sites to nightly version every day:

We could hardcode the nightly option in the dropdown, and display the user the numeric option. That way they could select nightly again.
We can fetch the development versions and match only the exact number version returned by the backend. That way users will see nightly the same they the site was created/updated , and they'll be able to update the following days.

sejas · 2025-03-18T01:29:39Z

src/stores/wordpress-versions-slice.ts

 				return {
 					isBeta,
-					label: occurrences > 1 || isBeta ? version : shortName,
+					isNightly: isDevelopment,


Why do we need this isNightly boolean?

We probably don't, thanks for catching that.

bcotrim · 2025-03-18T09:19:11Z

I see two possible options here. The premise is that users might want to update their sites to nightly version every day:
We could hardcode the nightly option in the dropdown, and display the user the numeric option. That way they could select nightly again.
We can fetch the development versions and match only the exact number version returned by the backend. That way users will see nightly the same they the site was created/updated , and they'll be able to update the following days.

Thanks for the feedback @sejas
I believe my approach is in line with your concern.
This is implementation I was going for:

We fetch the developments versions and display nightly on the dropdown since it's easier to read and understand.
Whenever a user installs a nightly version they will see the "real" version in the site settings
If they edit the site details they will see nightly if their version is the latest nightly version and the "real" version number if there's a newer nightly build

Is this what you had in mind or did I misunderstood your initial approach?

sejas · 2025-03-19T11:37:03Z

If they edit the site details they will see nightly if their version is the latest nightly version and the "real" version number if there's a newer nightly build
Is this what you had in mind or did I misunderstood your initial approach?

Yep, that's what I had in mind. 👍
In the future we could consider enabling autoupdate to don't bother of changing the nightly version every day.

sejas

It works as expected. I tested the scenarios where we created a new site and update it using the nightly version.

Creating nightly version

Screen.Recording.2025-03-19.at.18.43.45.mov

Creating beta and updating to nightly version

Screen.Recording.2025-03-19.at.18.41.32.mov

The nightly versions are saved in server files:

sejas · 2025-03-19T16:08:50Z

src/lib/version-utils.ts

+
+/**
+ * Checks if a version string represents a WordPress development version
+ * Matches patterns like "6.8-beta2-59979"


Are we sure the nightly version follows this pattern even when there are no betas?
I think we shouldn't mix functions that check Studio versions and WordPress versions.

Nice one!
I updated the check to allow for more scenarios, let me know what you think.
Also moved all WordPress version functions to a new lib file.

@bcotrim , I don't see this change. Did you already push the commit?
BTW, the image of Edit Site in the description doesn't belong to the modal.

Sorry I sent the comment before I wanted to.
It should be good to review now.

sejas · 2025-03-19T17:40:59Z

src/stores/wordpress-versions-slice.ts

+			const allOffers = [ ...developmentOffers, ...stableOffers ];
+
+			return allOffers.map( ( { version, shortName } ) => ( {
+				isBeta: version.includes( 'beta' ) || version.includes( 'RC' ),


We can consider re-using this boolean that is also used in generateVersionLabel.

sejas · 2025-03-19T18:24:15Z

src/stores/wordpress-versions-slice.ts

+	if ( version ) {
+		params.append( 'version', version );
+	}


The answer of the development API doesn't change even if we pass the version.

sejas · 2025-03-19T18:48:21Z

src/stores/wordpress-versions-slice.ts

+				shortNameOccurrences
+			).slice( 0, 1 );
+
+			const allOffers = [ ...developmentOffers, ...stableOffers ];


...developmentOffers will be the nightly version or undefined in case the backend doesn't return a response development. If undefined, it won't appear in the array.

sejas · 2025-03-19T19:01:51Z

src/lib/get-wordpress-version-url.ts

+	if ( isWordPressDevVersion( version ) ) {
+		return 'https://wordpress.org/nightly-builds/wordpress-latest.zip';
+	}


I'm a bit worried that when selecting a beta version we actually download a nightly version. This is not the case right now, but it could happen if the API returns a 6.8-beta3-600046.

It would be better if we identify a nightly with that version name.

sejas

Works as described 👍
I tested it again for new and existing sites.

sejas reviewed Mar 18, 2025

View reviewed changes

bcotrim force-pushed the add/wp_versions_nightly_support branch from 5c592f8 to 7508fed Compare March 18, 2025 08:54

bcotrim added 3 commits March 19, 2025 13:42

test nightly versions

39013c2

remove isNightly prop

cc3508a

add support for nighthly versions

14a18d5

bcotrim force-pushed the add/wp_versions_nightly_support branch from a6dbb69 to 14a18d5 Compare March 19, 2025 13:43

bcotrim marked this pull request as ready for review March 19, 2025 13:58

bcotrim requested a review from sejas March 19, 2025 13:58

sejas approved these changes Mar 19, 2025

View reviewed changes

sejas reviewed Mar 19, 2025

View reviewed changes

bcotrim added 3 commits March 20, 2025 15:01

pr feedback adjustments

3212878

remove un-used test file

c79504e

add missing files

c181aa8

sejas approved these changes Mar 20, 2025

View reviewed changes

bcotrim merged commit 9da8b96 into trunk Mar 20, 2025
7 checks passed

bcotrim deleted the add/wp_versions_nightly_support branch March 20, 2025 16:46

bcotrim self-assigned this Apr 23, 2025

Consider supporting trunk/nightly WordPress version #1072

Consider supporting trunk/nightly WordPress version #1072

Uh oh!

Conversation

bcotrim commented Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bcotrim commented Mar 18, 2025

Uh oh!

sejas commented Mar 19, 2025

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bcotrim commented Mar 14, 2025 •

edited

Loading

sejas Mar 20, 2025 •

edited

Loading

sejas left a comment •

edited

Loading