wp-now with blueprint not working (setSiteOptions step)

[gaambo]

I wanted to use wp-now to test my blueprint.json for enabling the preview in the plugin repository. The blueprint file works and is valid, as can be tested by going to https://playground.wordpress.net/?blueprint-url=https://raw.githubusercontent.com/goodwp/good-slider/main/.wordpress-org/blueprints/blueprint.json But when I run wp-now start --blueprint=dev/goodwp/plugins/slider/.wordpress-org/blueprints/blueprint.json it fails when running the setSiteOptions step:

'PHP Warning:  include(wordpress/wp-load.php): Failed to open stream: No such file or directory in php-wasm run script on line 2\n' +
    "PHP Warning:  include(): Failed opening 'wordpress/wp-load.php' for inclusion (include_path='.:') in php-wasm run script on line 2\n" +
    'PHP Fatal error:  Uncaught Error: Call to undefined function update_option() in php-wasm run script:5\n' +
    'Stack trace:\n' +
    '#0 {main}\n' +
    '  thrown in php-wasm run script on line 5\n'

If I remove the setSiteOptions step, the next step is the installPlugin I get an error about DOMParser is not defined which seems like #113. That issue seems fixed, but maybe it's just not released yet.

System/versions:

• node v20.11.0
• wp-now 0.1.65 (happens with installed binary as well as npx)
• system: WSL with Ubuntu 22.04
• I ran it in a temporary empty directory and an existing WordPress install - no difference.

[adamziel]

@gaambo I see you're using the importFile step which is, at the moment, browser-only unfortunately. It uses the DOMParser class that's only available in the browser. I'm not sure if that already works in wp-now, but you could try importing that file via the wpCLI step and the import command. Perhaps that step should do just that internally when ran in Node.js.

The PHP Warning: include(wordpress/wp-load.php): issue related to setSiteOptions is surprising and shouldn't be happening. It seems like a wp-now bug – CCing @sejas

[gaambo]

I see you're using the importFile step which is, at the moment, browser-only unfortunately. It uses the DOMParser class that's only available in the browser.

I guess that's what #113 was about? Would it make sense to put a table in the documentation which steps are supported by wp-now or is the goal to support all and should I open issues if I find missing steps?

[adamziel]

@gaambo The goal is to support it in wp-now, but documenting the limitation would still be useful. I think all the other steps work as expected.

[sejas]

We could add blueprint tests to wp-now to all the steps that are compatible, and catch if they break in some release. Then documenting the compatible steps would be much easier.

[adamziel]

+1000 @sejas

[carstingaxion]

I ran into the same problem: Using the import step works fine, until used in CI/CD. But will try just using the cli step.

Would love to read any news on this .

[carstingaxion]

We could add blueprint tests to wp-now to all the steps that are compatible

@sejas @adamziel why not create a json schema for wp-now compatible blueprints?

[adamziel]

This one should work once wp-now is updated to the latest Playground dependencies via https://github.com/WordPress/playground-tools/pull/345 – https://github.com/WordPress/wordpress-playground/pull/1629 released in Playground v0.9.28 solved it in Playground core. Meanwhile, I think it would already work as expected in the latest Playground CLI.