Installing WooCommerce as a plugin leads to empty body

[dennisnissle]

Hi there,

did anyone try to install WooCommerce as a plugin? Seems to break something in WP-Admin (maybe the HTML structure) which leads to returning an empty body for the php response. The HTML gets outputted just fine to the console though.

To reproduce:

1. Navigate to https://wasm.wordpress.net/wordpress.html?plugin=woocommerce
2. Go to WP-Admin - the first request will lead to a redirect to the Woo setup wizard
3. Navigate to /wp-admin

Any help/debugging advice is appreciated.

Best,
Dennis

[adamziel]

My hypothesis is that Woo relies on an API request while WordPress Playground doesn't support networking yet. There could be other reasons, too – the rawError property on the first screen you posted should contain some useful debugging information.

[dennisnissle]

But isn't it kind of strange that the whole HTML output is logged to the console? Seems like there is some content available to be delivered but that seems to fail. I've already checked the rawError and locally patched a sqlite error which lead to a fatal error being thrown but still the issue persisted. After my patches the rawError returned the same as for normal requests (some debug output regarding missing array key ssl).

[adamziel]

It is kind of strange! Perhaps there's another explanation then.

phpResponse.body is sourced from /tmp/stdout – on your screenshot it is an empty ArrayBuffer. PHP is not supposed to write anything to stdout. Emscripten's default behavior is to console.log the entire stdout – maybe that's what's going on here? PHP outputs the HTML to stdout instead of /tmp/stdout?

This would mean something is off with redirect_stream_to_file here:

wordpress-playground/src/php-wasm/wasm/build-assets/php_wasm.c

Lines 88 to 105 in 24c400e

	int EMSCRIPTEN_KEEPALIVE phpwasm_run(char *code)
	{
	int retVal = 255; // Unknown error.
	// Write to files instead of stdout and stderr because Emscripten truncates null
	// bytes from stdout and stderr, and null bytes are a valid output when streaming
	// binary data.
	int stdout_replacement = redirect_stream_to_file(stdout, "/tmp/stdout");
	int stderr_replacement = redirect_stream_to_file(stderr, "/tmp/stderr");
	if (stdout_replacement == -1 || stderr_replacement == -1)
	{
	return retVal;
	}
	zend_try
	{
	retVal = zend_eval_string(code, NULL, "php-wasm run script");

[dennisnissle]

Hi there,

I did some further debugging. The issue seems to be related to using custom output buffering. Woo uses ob_start() in WC_Admin::buffer(). Seems to be part of this commit. I really can't find a good reason why one should do that but anyway - could this be catched by the worker?

The same is happening for the checkout here. I've patched the files (removed the ob_start() call) and now it works both in frontend and in backend. There is another issue in the action-scheduler package which needs to be patched as the data store uses the reserved group keyword from sqlite:

SELECT a.*, g.slug AS `group` FROM...

[adamziel]

Great find @dennisnissle! This PHP function must be somehow flushing the buffer to stdout despite the redirect set up in php_wasm.c:

https://github.com/php/php-src/blob/b505562a455ceee4f75a9cc7486e351fcfbb5c6c/main/output.c#L251-L270

As for the group keyword, is there any way this could be solved by using another set of quotes? If so, then maybe it could be patched in the WordPress sqlite plugin that WordPress Playground already downloads and patches?

[adamziel]

Perhaps the buffer gets flushed in php_embed_shutdown – if so, then adding the stream redirection code to phpwasm_destroy_context would fix it.

[adamziel]

That was it – I pushed a fix in 9d3ad83:

I'll deploy the fix to wasm.wordpress.net in a week-two, for now a commit must do. Thanks for the report!

[adamziel]

Fix deployed: http://127.0.0.1:8777/wordpress.html?plugin=woocommerce&url=/wp-admin/

If it loads a blank page, click the address bar and press enter to reload. Static assets sometimes error out with 403 – that's a separate issue somehow related to service workers. It mostly happens when devtools are open.

[adamziel]

Here's another related issue that will have to be solved to make the WooCommerce installation wizard work: #103

[adamziel]

That issue was solved by #107. I got to Woo dashboard in wp-admin! Network access aside, there's also some problem with creating one of the woocommerce database tables, presumably due to syntax differences between mysql and sqlite.