[Web] Ship additional .wasm bundles with more PHP extensions
Closed this issue · 13 comments
In case of our plugin Glossary we need the mbstring and iconv available.
You can see the plugin warning on https://playground.wordpress.net/?plugin=glossary-by-codeat&login=1&url=/wp-admin/plugins.php
- https://www.php.net/manual/en/mbstring.installation.php
- https://www.php.net/manual/en/function.iconv.php
Also a list in the doc of the PHP modules used by the tool can be useful for this things
We have the same issue with our plugin. It needs both the iconv and mbstring extensions. The playground should include widely used modules like these.
Thank you for reporting @Mte90! mbstring is already supported, just not shipped with the web version of Playground. @akirk suggested shipping additional wasm bundles with more PHP extensions for the plugins that need that. Let's make this issue all about that.
There could be 3 bundles:
- Vanilla PHP as it is now
- PHP + iconv, mbstring
- PHP + all supported extensions (openssl, libxml, libcurl in the future)
Then, Playground would need to accept a list of PHP extensions and choose an appropriate bundle. This would affect the following APIs:
- Query string (
&extension=iconv&extension=mbstring - Blueprints (
"extensions": ["iconv", "mbstring]) - JavaScript API (
PHP.load("8.0", {"extensions": ["iconv", "mbstring]});
iconv is not supported yet and would need some explorations. I just created issue #666 to track it.
Why not ship just a single playground version with all the php modules?
@Mte90 I'd love to do that! The problem is with the bundle size – the minimal playground build for the web is 6MB at the time, while the Node.js build that has more extensions is about ~11MB. With more extensions, that figure is only going to grow, but modularity would allow us to only download what's needed. I'm currently exploring modular extension loading in #314.
It make sense but we are talking about a playground that is used by desktop and not mobile so downloading is not a big problem (compared to mobile).
Also because for the plugin repository is not something easy as plugins not define anyway what are the php module that use it, everyone has custom code for that.
@Mte90 I didn't mean that as a blocker. Shipping an additional "all included" bundle for the plugin directory sounds reasonable to me until there is a modular solution. The preview in the plugin repository will be an opt-in feature and offer a convenient way for plugin authors to define the required PHP extensions. Whether the default option should be a "minimal" PHP build or an "all included" build is a separate conversation and would be a good fit for https://meta.trac.wordpress.org/ticket/7251.
Lack of OpenSSL support is currently a blocker for our plugin in WordPress Playground; looking forward to more PHP extensions being supported!
@tbradsha Thank you for letting us know! Solving this issue is slowly becoming possible, especially after the recent merge of #838. Is your plugin publicly available? How are you using OpenSSL in it? I'm asking because the current level of network support doesn't enable use-cases like e.g. downloading SSL certificates, see #85
Indeed, you can search the WP.org repo for Jetpack CRM. We primarily use OpenSSL to encrypt/decrypt sensitive data.
Playground now supports an "all available PHP extensions" bundle via the kitchen-sink extensions bundle:
{
"phpExtensionBundles": ["kitchen-sink"]
}
?php-extension-bundle=kitchen-sink
There is a way to load them without the modal itself? like with a URL or something in the readme?
Yeah, see the Query API and Blueprints API in my reply. Here's how you'd use them:
Query API:
https://playground.wordpress.net/?php-extension-bundle=kitchen-sink
Blueprints API:
https://playground.wordpress.net/#{"phpExtensionBundles":["kitchen-sink"]}
Ah ok sorry I didn't understood that kitchen-sink is just a placeholder for a php module.