[Web] Ship additional .wasm bundles with more PHP extensions

[Mte90]

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

[BenSibley]

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.

[adamziel]

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:

1. Vanilla PHP as it is now
2. PHP + iconv, mbstring
3. 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.

[Mte90]

Why not ship just a single playground version with all the php modules?

[adamziel]

@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.

[Mte90]

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.

[adamziel]

@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.