Networking access: Fix wp_http_supports() to work without the kitchen-sink extension bundle.

[dd32]

Fixes #1494

In #1048 I introduced a regression of #819, in that wp_http_supports( [ 'ssl' ] ) no longer returned truthful without the kitchen-sink extension bundle loaded.

This partially reverts #1048 by keeping the filters for Requests, but reinstating the deprecated WP_HTTP filters.

It's worth noting, that this is not a direct revert, as it forces the Fetch/Dummy handlers instead of simply adding them as an option. This is to match the Requests filter behaviour.

To test this, the following blueprint should land you on a plugin install page without any errors visible:
https://playground.wordpress.net/#{%22phpExtensionBundles%22:[%22light%22],%22features%22:{%22networking%22:true},%22landingPage%22:%22/wp-admin/plugin-install.php%22,%22steps%22:[{%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22}]}

{
  "phpExtensionBundles": [
    "light"
  ],
  "features": {
    "networking": true
  },
  "landingPage": "/wp-admin/plugin-install.php",
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    }
  ]
}

[bgrgicak]

Thank you! Let's just check in with @adamziel to make sure this won't have any unwanted consequences.

[adamziel]

These filters are tricky! Lovely fix, thank you @dd32!

Would you mind also adding an E2E test around here to make sure this regression won't come back in the future?

wordpress-playground/packages/playground/website/cypress/e2e/query-api.cy.ts

Line 89 in 172d78f

it('should enable networking when requested AND the kitchen sink extension bundle is enabled', () => {

(The existing one is a duplicate of the one above it and the label is confusing. Kitchen sink is the default now so that test can be rewritten to use ?php-extension-bundle=light)

[dd32]

I've tried to e2e it, and the test change looks correct to me, but should enable networking when requested AND the kitchen sink extension bundle is NOT enabled still passed when I expected it to fail, and should return true from wp_http_supports(array( "ssl" )) (which I switched to run without the bundle) timed out twice in a row.

I wasn't able to get the tests to run locally, I've only guessed what I'm supposed to do for that (npm test, also tried using npx nx e2e playground-website) as I can't find any related documentation.

[brandonpayton]

the test change looks correct to me, but should enable networking when requested AND the kitchen sink extension bundle is NOT enabled still passed when I expected it to fail

@dd32 Why were you expecting it to fail?

I wasn't able to get the tests to run locally, I've only guessed what I'm supposed to do for that (npm test, also tried using npx nx e2e playground-website) as I can't find any related documentation.

I struggled with this too and ended up running the following CI e2e testing commands locally:

wordpress-playground/.github/workflows/ci.yml

Lines 38 to 39 in cd34e50

	- run: sudo ./node_modules/.bin/cypress install --force
	- run: sudo CYPRESS_CI=1 npx nx e2e playground-website --configuration=ci --verbose

(probably shouldn't prefix with sudo locally though :)

Then I discovered local e2e instructions in the website README:

wordpress-playground/packages/playground/website/README.md

Lines 7 to 11 in cd34e50

	To run the end to end tests locally, use the following command:
	```bash
	npx nx run playground-website:e2e:dev:cypress
	```

[dd32]

the test change looks correct to me, but should enable networking when requested AND the kitchen sink extension bundle is NOT enabled still passed when I expected it to fail

@dd32 Why were you expecting it to fail?

Good question; and that might have been the misunderstanding :)
The test run was without this change, which I thought would mean it would use fetch() which would be a CORS request which would then hit a HTTP remote, which CORS would block as it would be cross-origin cross-protocol; but now I realise that the tests are probably not running with a SSL viewport, which means that whether it supported SSL requests or not is mostly irrelevant, the API endpoint would return via HTTP or HTTPS.

What this means, is that the test is likely working as expected, even though it's now without OpenSSL, it probably still passes just fine (Just requests via HTTP rather than HTTPS, both of which are totally acceptable).

[dd32]

Then I discovered local e2e instructions in the website README:

Ah! Thank you! Developer instructions being in nested readme's gets me all the time when I have no idea which things are distinct components :)

[brandonpayton]

Then I discovered local e2e instructions in the website README:

Ah! Thank you! Developer instructions being in nested readme's gets me all the time when I have no idea which things are distinct components :)

Same here. :) I logged an issue to add better instructions here since documenting e2e isn't as quick as mentioning a couple of commands at the top level.