Upgrade @php-wasm and related dependencies to 0.7.20

[derekblank]

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?

[derekblank]

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:

• [Breaking] Refactor PHP.ini management, remove php.setPhpIniPath() and php.setPhpIniEntry() WordPress/wordpress-playground#1423

@sejas I can't quite tell if the "Remaining Work" section in WordPress/wordpress-playground#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. 🙇

[sejas]

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]

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.

[wojtekn]

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?

[derekblank]

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?

[wojtekn]

@derekblank we decided to fork wp-now, here is more context: https://github.com/Automattic/local-environment/pull/46

[sejas]

Closing in favor of #392