Enable networking for WordPress PR viewer
ironprogrammer opened this issue · 4 comments
While #1225 is being deliberated on for Playground as a whole, I think that having network enabled in the WordPress PR viewer would be beneficial for developers and testers.
I've run into situations where using Playground for a PR wasn't an option to test the changes with different themes or plugins that aren't included by default (e.g. block vs classic themes). The additional load time for this feature is a good trade off for the convenience of not needing to fall back on local testing with a typical PR checkout workflow.
What do you think?
@ironprogrammer This makes sense and would be easy to implement. WordPress would be slower because of the added network roundtrips, but that sounds okay for testing PRs. Would you be interested in contributing a PR? You'd need to add the networking feature to this Blueprint:
And perhaps also this one for Gutenberg PR previewer:
@adamziel In testing the changed default for networking (#1715), I noticed that subsequent updates to PHP and WP versions through the "Customize Playground" modal (which update the Query API params) are respected, but the network setting is not.
I've submitted the PR for review, but the fact that the networking=yes|no Query API setting isn't respected alongside a Blueprint, this seems like a bug. I'm wondering if another way of resolving this would be to change how that's handled, allowing that Query API setting to override/augment the Blueprint? This would also mitigate the issue as reported, since the underlying problem was being able to test a PR alongside specific plugins/themes from the directory. Thoughts?
I've submitted the PR for review, but the fact that the networking=yes|no Query API setting isn't respected alongside a Blueprint, this seems like a bug.
This taps into a larger question of resolving conflicts between the Query API and Blueprints.
At the moment, a Blueprint has a precedence over the query parameters. This includes Blueprint defaults, such as "networking": false. Now, imagine a Blueprint that explicitly says "networking": false while the Query API explicitly says networking=yes – what should happen then?
Perhaps we can provide a more developer friendly parameter merging semantics. This seems very similar to the problem of merging multiple Blueprints. Would you like to open a new issue to track that separately?