Run examples with php wasm

[soyuka]

Adds a PHP Wasm binary to run documentation examples in the browser. We discussed this with @pronskiy (
fixes php/doc-en#3259).

php-doc-2.mp4

I've builtin PHP wasm 8.4.0-dev and I'm not sure what would be preferred to keep this up to date. If you want to reproduce the build see:

soyuka/php-wasm#7

Clone that branch and execute:

docker buildx bake
cp build/* ../phpdoc/web-php/js

Work sponsored by Les-Tilleuls.coop inline with what we built at the API Platform Playground more informations on a blog post

[github-actions]

🚀 Regression report for commit 08cc46b is at https://web-php-regression-report-pr-1097.preview.thephp.foundation

[github-actions]

🚀 Preview for commit 08cc46b can be found at https://web-php-pr-1097.preview.thephp.foundation

[dunglas]

Suggested change

	const {ccall} = await phpBinary({
	const {ccall} = await phpBinary({

(mixed tabs and spaces)

[dunglas]

Suggested change

	document.querySelectorAll('.example').forEach((example) => {
	const button = document.createElement('button');
	const phpcode = example.querySelector('.phpcode');
	document.querySelectorAll('.example').forEach((example) => {
	const button = document.createElement('button');
	const phpcode = example.querySelector('.phpcode');

[dunglas]

Suggested change

	button.innerText = 'Run code';
	button.onclick = function() {
	button.innerText = 'Run code';
	button.onclick = function() {

[dunglas]

Suggested change

	};
	phpcode.parentNode.insertBefore(button, phpcode);
	});
	};
	phpcode.parentNode.insertBefore(button, phpcode);
	});

[dunglas]

Suggested change

	const container = document.createElement('div');
	container.classList.add('screen', 'example-contents');
	const title = document.createElement('p');
	title.innerText = 'Output: ';
	container.appendChild(title)
	const div = document.createElement('div');
	div.classList.add('examplescode');
	container.appendChild(div);
	const pre = document.createElement('pre');
	pre.classList.add('examplescode');
	pre.innerText = output;
	div.appendChild(pre)
	return container;
	const container = document.createElement('div');
	container.classList.add('screen', 'example-contents');
	const title = document.createElement('p');
	title.innerText = 'Output: ';
	container.appendChild(title);
	const div = document.createElement('div');
	div.classList.add('examplescode');
	container.appendChild(div);
	const pre = document.createElement('pre');
	pre.classList.add('examplescode');
	pre.innerText = output;
	div.appendChild(pre);
	return container;

CS

[stof]

much simpler: lastOutput.remove() (there is no reason to care about unmaintained browsers not supporting the remove method when you are adding a feature requiring WebAssembly to work)

[stof]

the created button should use the button type instead of the default submit type, to avoid issues in case this ends up being used in a place being inside a form.

[stof]

should this use .innerText or .textContent here ? innerText is impacted by the styles of the page

[soyuka]

no idea 🤷

[stof]

use phpcode.before() instead

[stof]

Disabling many extensions as you did in soyuka/php-wasm#7 is likely to make many examples non working though (in your build, even JSON functions are not available)

[soyuka]

Disabling many extensions as you did in soyuka/php-wasm#7 is likely to make many examples non working though (in your build, even JSON functions are not available)

Definitely, there are a few things to discuss, I can enable most extensions, some will require additional libraries (for example dom or xml require libxml) and it'll add weight to the build (now it's "only" 3.6 MB).

[soyuka]

maybe that this deserves only one line?

[pronskiy]

As I understand, php binary is always loaded now, right? If yes, does it make sense to load it only when the user clicks "Run" for the first time?

[soyuka]

done

[soyuka]

Note that we should use brotli or gzip though, I'm unfamiliar with the server architecture behind the php docs website, should I add this directly to the cached.php file?

[Girgias]

@derickr is likely the person that would know this.

[jimwins]

It looks like php.net isn't particularly well set-up for encoding content. You can see how CSS/JS/etc is served up by the cached.php file, and testing with curl --compressed -I shows that it doesn't get encoded. HTML content does get gzip-encoded, at least.

I'm not sure how much of the encoding happens on our server vs. what Myra does on the edge, but there's probably room for improvement there even outside of encoding the WASM bundle appropriately. The current web configuration isn't in the systems repo yet, though.

[lwlwilliam]

If the modified code can still be highlighted, that would be even better.

[stof]

@lwlwilliam this would require bringing an actual code editor (Codemirror or Monaco) instead of just using contenteditable

[pronskiy]

@lwlwilliam, @stof, it makes sense for sure, but perhaps as step two in a separate PR? Just to keep this one smaller and delivered sooner. I'm pretty sure some unforeseen bugs will be discovered when this is deployed, and it'll be easier to fix them with smaller steps.

[pronskiy]

@soyuka, what do you think about adding the PHP version in the output label?

[derickr]

Myra already caches cached.php with a 2 minute TTL (and 1 minute in case of a 404), but there are no settings for specific compressions:

prefix	/cached.php	2 minutes	1 minute

I can ask whether they can do on the fly-compression, but I am not sure whether they do.

To answer @jimwins, the config isn't in the systems repo, as nothing on php-web4 has been "php-ified" yet. I think Sascha set it up with nginx in his own way. There is no /local/systems either. The nginx configuration does not have any compression options set either.

I believe adding it to cached.php with the right headers (content-type and compression-type), with storing the compressed file should work. You should be able to test that yourself on your local development environment too.

[soyuka]

I believe adding it to cached.php with the right headers (content-type and compression-type), with storing the compressed file should work. You should be able to test that yourself on your local development environment too.

I gave a try

diff --git a/cached.php b/cached.php
index 766afb2e..c8055ef7 100644
--- a/cached.php
+++ b/cached.php
@@ -46,6 +46,14 @@
     header("Content-Type: application/javascript");
 } elseif (substr($abs, -4) == ".css") {
     header("Content-Type: text/css");
+} elseif (substr($abs, -4) == ".wasm") {
+	header("Content-Type: application/wasm");
+}
+
+$gzipped = $abs . '.gz';
+if (file_exists($gzipped) && isset($_SERVER['HTTP_ACCEPT_ENCODING']) && false !== strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) {
+    $abs = $gzipped;
+	header("Content-Encoding: gzip");
 }
 
 readfile($abs);

But as the Javascript is requiring the php-web.wasm file it's not ideal and should be left to the HTTP server in my opinion. For example, I'm running the docs using FrankenPHP:

@pronskiy added version:

[derickr]

I don't quite understand whether your "try" was succesful or not. I can only see an image.

The javascript should surely be calling /cached.php?.... and not the .wasm file directly...?

And we deploy on nginx, so you should test with that, and not with something else. I have just added the nginx configuration to the systems repository: https://github.com/php/systems/tree/master/php-web4/nginx

[shaedrich]

@pronskiy added version:

Should there be only one version or all of the supported in a dropdown/select?

[pronskiy]

@shaedrich, for the sake of simplicity of this first step, it's better to stick to just one version. The dropdown sounds like a good idea for the next step.

[cookieguru]

Probably want to add

js/php-web.wasm filter=lfs diff=lfs merge=lfs binary

to .gitattributes