Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installing WooCommerce as a plugin leads to empty body #96

Closed
dennisnissle opened this issue Dec 22, 2022 · 10 comments
Closed

Installing WooCommerce as a plugin leads to empty body #96

dennisnissle opened this issue Dec 22, 2022 · 10 comments

Comments

@dennisnissle
Copy link

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

Bildschirmfoto 2022-12-22 um 16 06 11

Bildschirmfoto 2022-12-22 um 16 09 56

Any help/debugging advice is appreciated.

Best,
Dennis

@adamziel
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

adamziel commented Dec 22, 2022

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:

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
Copy link
Author

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
Copy link
Collaborator

adamziel commented Dec 23, 2022

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
Copy link
Collaborator

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
Copy link
Collaborator

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

CleanShot 2022-12-28 at 23 24 18@2x

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

@adamziel
Copy link
Collaborator

adamziel commented Jan 4, 2023

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
Copy link
Collaborator

adamziel commented Jan 4, 2023

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

@adamziel
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants