Lazy load PHP extensions (like dom and libxml)

[westonruter]

I tried uploading the Web Stories plugin, but the plugin gave an error notice:

The dom and libxml extensions should be enabled, as they are almost always available on WordPress sites.

[westonruter]

I suppose that means the WITH_LIBXML build option should rather be yes here:

wordpress-playground/src/php-wasm/wasm/gulpfile.js

Lines 37 to 38 in ddebea5

	'--build-arg',
	`WITH_LIBXML=no`,

[adamziel]

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

• 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

[swissspidy]

This list of recommended extensions might be helpful: https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions

[adamziel]

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.

[adamziel]

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]

Related: https://emscripten.org/docs/optimizing/Module-Splitting.html#module-splitting

[adamziel]

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.

[adamziel]

JSPI support just got merged and lazy loading is now technically possible – as described in https://v8.dev/blog/jspi.