-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow PHP version to be changed from Site Settings #225
Conversation
Not correctly saving/applying the PHP version quite yet. My intent is to have the PHP version saved in Also need to handle invalid or outdated PHP version stored in Happy to take suggestions on the tests to add. |
The PHP version is being saved correctly to
Potentially, we could just fallback to using |
* Add phpVersion to updateSiteDetails * Update tests for changing the PHP version
Thanks @danielbachhuber! We had originally planned to add the PHP version picker to the add/edit site form under a new "Advanced settings" section. (Moving the local path field there too.) Clicking the edit link on the site settings screen would launch the full edit site modal. Was that plan changed? (I may have missed any discussion there.) I prefer the dedicated modal when editing the PHP version for an existing site. Assuming we're okay with maintaining the additional UI in the app. I think users should be able to set the PHP version when creating a new site too though. |
@matt-west I decided to add this implementation for now because I saw there was a lot of demand for a PHP version switcher and didn't want to go down the rabbit hole adding an overly complex form. |
I have not looked at the PR yet but I think it would be good to have PHP version shipped before / around WC EU so that the app could be showcased with this feature. It has been requested and mentioned in multiple demo calls, P2s and conversations and was generally marked as one of the main blockers for not using Studio compared to Local. |
@danielbachhuber Sounds good. We can add the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested the PR and works as expected 🎊 . The only limitation I found is that demo sites don't use the PHP version set. As far as I've tested, they are always created with version 8.1.29
. I wouldn't consider it a blocker but I presume users will expect that the PHP version matches between the local and demo site.
src/site-server.ts
Outdated
@@ -99,6 +101,7 @@ export class SiteServer { | |||
...this.details, | |||
url: this.server.url, | |||
port: this.server.options.port, | |||
phpVersion: this.server.options.phpVersion || DEFAULT_PHP_VERSION, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: The phpVersion
can be a supported value or undefined
.
phpVersion: this.server.options.phpVersion || DEFAULT_PHP_VERSION, | |
phpVersion: this.server.options.phpVersion ?? DEFAULT_PHP_VERSION, |
* Use `DEFAULT_PHP_VERSION` constant from `wp-now` * Use available PHP versions of Playground * Add `web-streams-polyfill` package for unit tests * Polyfill `ReadableStream` in unit tests Web streams are used by `php-wasm`, so we need to polyfull them if we import the library in unit tests.
@Automattic/yolo I think this is ready for a review. |
* Mock `matchMedia` * Expose label in `SettingsRow` component * Add test to cover the case of changing PHP version * Revert "Expose label in `SettingsRow` component" This reverts commit bc37161. * Update change PHP version test case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works as expected 🎊, nice work @danielbachhuber @derekblank 🏅 !
I added some comments that shouldn't block the PR but that I plan to address in a separate PR.
Additionally, I noticed a minor issue regarding the window size after we added this new element. As you can see in the screenshot, the settings tab's content now overflows and causes the content to scroll. If I'm not wrong, we've avoided in the past that this tab have a scroll, so we could consider increasing the minimum window height to do so.
cc @matt-west
@@ -30,6 +32,7 @@ export function ContentTabSettings( { selectedSite }: ContentTabSettingsProps ) | |||
// Empty strings account for legacy sites lacking a stored password. | |||
const storedPassword = decodePassword( selectedSite.adminPassword ?? '' ); | |||
const password = storedPassword === '' ? 'password' : storedPassword; | |||
const phpVersion = useGetPhpVersion( selectedSite ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the hook useGetPhpVersion
is not necessary because the PHP version is already coming from the site details in selectedSite
.
const phpVersion = selectedSite.phpVersion ?? DEFAULT_PHP_VERSION;
Not sure if this approach has been followed based on the other hook useGetWpVersion
. If so, the WordPress version needs to be retrieved from the WordPress files as it's not referenced in the site details. That's the main reason for needing that hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add these changes in a separate PR to avoid blocking this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add these changes in a separate PR to avoid blocking this one.
While we've tried to avoid scrolling on the settings screen in the past, we were always going to reach the point that it was needed. I’m happy with letting that screen scroll now. |
I wonder if we should warn the user about site restarting when changing the PHP version on a running site. This is not a destructive action but it might be unexpected by the user. WDYT? |
@fluiddot I'm not sure that's necessary. I feel there's an expectation that changing the PHP version in that modal would apply the change right away. |
* Remove `getPhpVersion` hook and IPC handler * Use `??` operator instead of `||` when setting the php version * Add inline comment in Jest setup The comment clarifies why we need the polyfill. Related to: #231 (comment) * Update `ContentTabSettings` unit tests
* Bump default PHP version to `8.1` This change is driven by the fact that version `8.0` already reached its end-of-life by 2024. https://www.php.net/supported-versions.php * Address failure in `createSite` unit test
@matt-west it's okay, but it seems we need to make the scrollbar visible all the time, similarly to the sidebar. Now, the main content sidebar scrollbar appears only if the user starts scrolling. |
FYI I've applied this fix in #255. |
Hey there guys! I don't know if this is related to the new implementation regarding the PHP selector, but as soon as I tried to use it I found permission issues. I tried to chown the permissions but it was having the same issue anyway. To replicate:
This is the complete log that I got.
I hope this is the right place to add this if not I can move it somewhere else. Best regards. |
@lajennylove Can you open a new GitHub issue for the issue? Thanks! |
Thanks @lajennylove for reporting the issue. As Daniel mentioned, it would be great if you could open a GitHub issue with this information. Thanks 🙇 ! |
Hey @danielbachhuber and @fluiddot I already sent the report about the issue I hope it helps. Thank you! |
Great, thank you @lajennylove for reporting the issue. |
Anytime! |
Related #32
Proposed Changes
Allows the PHP version to be changed from Site Settings:
CleanShot.2024-06-10.at.07.34.42.mp4
Also restarts the server after the PHP version is changed.
Testing Instructions
Pre-merge Checklist