You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Lazy load PHP extensions (like dom and libxml) #89
I do agree it can be useful, though! That's the problem of different use-cases – you don't need it for embeddable code snippets in a JavaScript-oriented WordPress course, but you do need it to use the Playground with certain WordPress plugins.
An obvious solution would be hosting two PHP builds, with and without libxml, and having a configuration switch with some smart defaults. It would work as long as that's only about a single extension. For two, three, or five PHP extensions there would need to be something smarter. Perhaps pre-packaged "environments" for specific purposes? As in:
Bare-minimum PHP for optimal bundle size
All-in-one PHP with all the supported extensions
A few targeted middle-ground environments with opinionated sets of extensions
Another idea: Emscripten supports dynamic libraries that are loaded lazily – Playground could use them to provide a lean initial bundle while also offering all the additional features.
Reacted by Weston Ruter, Greg Ziółkowski and Pascal Birchler
Here’s v8.dev article about an unrelated topic with an example implementation of lazy-loading wasm libraries. They use the experimental JSPI api, but it should also work with the existing stable Asyncify api:
Actually – lazy loading may not be needed at all. Building PHP extensions to .so files and loading them using zend_extension= in PHP.ini would already do the trick. Blueprints would then support declaring a list of extensions to load and voila.
I just explored that today and managed to build XDebug. The next challenge is actually loading it in PHP, dlopen seems to be disabled at the moment.
Activity
westonruter commentedon Dec 15, 2022
I suppose that means the
WITH_LIBXMLbuild option should rather beyeshere:wordpress-playground/src/php-wasm/wasm/gulpfile.js
Lines 37 to 38 in ddebea5
adamziel commentedon Dec 16, 2022
@westonruter It's been enabled by default, I disabled it to remove 1.21M from the bundle size (see #2).
I do agree it can be useful, though! That's the problem of different use-cases – you don't need it for embeddable code snippets in a JavaScript-oriented WordPress course, but you do need it to use the Playground with certain WordPress plugins.
An obvious solution would be hosting two PHP builds, with and without libxml, and having a configuration switch with some smart defaults. It would work as long as that's only about a single extension. For two, three, or five PHP extensions there would need to be something smarter. Perhaps pre-packaged "environments" for specific purposes? As in:
swissspidy commentedon Dec 21, 2022
This list of recommended extensions might be helpful: https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions
adamziel commentedon Jan 31, 2023
Another idea: Emscripten supports dynamic libraries that are loaded lazily – Playground could use them to provide a lean initial bundle while also offering all the additional features.
[-]Enable dom and libxml extensions by default[/-][+]Lazy load extensions like dom and libxml[/+]adamziel commentedon Apr 11, 2023
Here’s v8.dev article about an unrelated topic with an example implementation of lazy-loading wasm libraries. They use the experimental JSPI api, but it should also work with the existing stable Asyncify api:
https://v8.dev/blog/jspi
adamziel commentedon Apr 22, 2023
Related: https://emscripten.org/docs/optimizing/Module-Splitting.html#module-splitting
[-]Lazy load extensions like dom and libxml[/-][+]Lazy load PHP extensions (like dom and libxml)[/+]adamziel commentedon Oct 9, 2023
Actually – lazy loading may not be needed at all. Building PHP extensions to
.sofiles and loading them usingzend_extension=in PHP.ini would already do the trick. Blueprints would then support declaring a list of extensions to load and voila.I just explored that today and managed to build XDebug. The next challenge is actually loading it in PHP,
dlopenseems to be disabled at the moment.adamziel commentedon Oct 9, 2024
JSPI support just got merged and lazy loading is now technically possible – as described in https://v8.dev/blog/jspi.
Update Playground Node version to 20.9.0 (#89)
[ php-wasm ] Add `xdebug` shared extension to @php-wasm/node ASYNCIFY (…
Bump vulnerable dependencies: ws, express, fast-xml-parser, ajv (#3745)
fellyph commentedon Sep 30, 2026
Current build flags enable libxml by default; the issue comments discuss lazy loading and the size increase.