Consider supporting trunk/nightly WordPress version - #1072
Conversation
sejas
left a comment
There was a problem hiding this comment.
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.
| return { | ||
| isBeta, | ||
| label: occurrences > 1 || isBeta ? version : shortName, | ||
| isNightly: isDevelopment, |
There was a problem hiding this comment.
Why do we need this isNightly boolean?
There was a problem hiding this comment.
We probably don't, thanks for catching that.
5c592f8 to
7508fed
Compare
Thanks for the feedback @sejas
Is this what you had in mind or did I misunderstood your initial approach? |
Yep, that's what I had in mind. 👍 |
a6dbb69 to
14a18d5
Compare
sejas
left a comment
There was a problem hiding this comment.
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:
|
|
||
| /** | ||
| * Checks if a version string represents a WordPress development version | ||
| * Matches patterns like "6.8-beta2-59979" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
Sorry I sent the comment before I wanted to.
It should be good to review now.
| const allOffers = [ ...developmentOffers, ...stableOffers ]; | ||
|
|
||
| return allOffers.map( ( { version, shortName } ) => ( { | ||
| isBeta: version.includes( 'beta' ) || version.includes( 'RC' ), |
There was a problem hiding this comment.
We can consider re-using this boolean that is also used in generateVersionLabel.
| if ( version ) { | ||
| params.append( 'version', version ); | ||
| } |
There was a problem hiding this comment.
The answer of the development API doesn't change even if we pass the version.
| shortNameOccurrences | ||
| ).slice( 0, 1 ); | ||
|
|
||
| const allOffers = [ ...developmentOffers, ...stableOffers ]; |
There was a problem hiding this comment.
...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.
| if ( isWordPressDevVersion( version ) ) { | ||
| return 'https://wordpress.org/nightly-builds/wordpress-latest.zip'; | ||
| } |
There was a problem hiding this comment.
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.

Related issues
Proposed Changes
nightlybuild URL for development versionsTesting Instructions
nightlybuild.nightlyversion and confirm it was installed successfullynightly).- Open "Edit site"
nightlyversion is selectednightlyversionnightlyversion option is available in the WordPress version dropdownnightlyand save to confirm the update is successfulPre-merge Checklist