studio
studio copied to clipboard
Automattic
Upgrade @php-wasm and related dependencies to 0.7.20
Related to #119
Proposed Changes
Support for WebP images was added to WordPress-Playground in 0.7.20 packages. Upgrading @php-wasm and related dependencies should allow users to upload WebP files.
Upgrades the following related dependencies to 0.7.20:
@php-wasm/node@php-wasm/universal@wp-playground/blueprints
Testing Instructions
(TBD)
TODO
- [ ] Check 0.7.20 breaking changes
- [ ] Update @php-wasm+node+0.6.16.patch to match 0.7.20 compatibility
Pre-merge Checklist
- [ ] Have you checked for TypeScript, React or other console errors?
When running these updated dependency changes locally, I encounter the following error when starting or creating a site:
Starting new session
Error occurred in handler for 'startServer': TypeError: php.setPhpIniEntry is not a function
at ~/studio/.webpack/main/siteServerProcess.js:54038:13
at Generator.next (<anonymous>)
at fulfilled (~/studio/.webpack/main/siteServerProcess.js:53994:58)
Sentry Logger [error]: Transport disabled
Indeed in the WordPress-Playground CHANGELOG I note this breaking change related to setPhpIniEntry:
- https://github.com/WordPress/wordpress-playground/pull/1423
@sejas I can't quite tell if the "Remaining Work" section in https://github.com/WordPress/wordpress-playground/pull/1423 means there is still work needed in WordPress-Playground to resolve the breaking change related to setPhpIniEntry.
If that's the case, we can hit pause on this PR until those changes have been completed. If not, do you note if there's any further dependency updates needed in Studio to resolve this breaking change? Perhaps we would need to update vendor/wp-now as well? Any further thoughts on the approach are welcome. 🙇
It seems we will need to refactor vendor/wp-now to avoid using setPhpIniEntry. I can try to setup a PR in wp-now repository that will be easier to migrate here 👍
I can try to setup a PR in wp-now repository that will be easier to migrate here 👍
That sounds great. Let me know if I can help review.
It seems we will need to refactor vendor/wp-now to avoid using setPhpIniEntry. I can try to setup a PR in wp-now repository that will be easier to migrate here 👍
@derekblank @sejas I checked it, and it seems that wp-now doesn't use the setPhpIniEntry method. It was something we added in forked wp-now in the Studio repository.
Should we continue with this PR and plan to switch from using setPhpIniEntry to setPhpIniEntries?
Should we continue with this PR and plan to switch from using setPhpIniEntry to setPhpIniEntries?
I agree. I don't have much context for why wp-now is included as a separate vendored copy, but I imagine it was either to introduce custom code changes to the library, or perhaps to fence the library off from receiving updates to keep Studio development stable.
(Lacking this context) It seems like it'd be more efficient to use wp-now directly, either as a node dependency or a git submodule, and keep Studio up-to-date with wp-now changes. Is there anything preventing this?
@derekblank we decided to fork wp-now, here is more context: https://github.com/Automattic/local-environment/pull/46