Playground could not serve the request.

[threadi]

Hi,

I am currently testing whether my plugin https://wordpress.org/plugins/easy-language/ can be used for the preview. The plugin establishes an HTTP connection for a translation of texts in the website to a PHP script I developed for this purpose, which serves as a proxy for the actual API-interface. The request is sent thanks to the activated network feature, but I always get an error message back.

The request arrives at my PHP script like this:

[30/Apr/2024:17:04:11 +0200] “OPTIONS /directory/index.php HTTP/2.0” 404 1 “https://playground.wordpress.net/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0”

which is strange, as I am actually sending a POST request.

As an error message I get this message in the plugin: “Playground could not serve the request.” with HTTP status 400.

Where does this message come from? And why is an OPTIONS request being sent here instead of the actual POST?

Thanks for any feedback :-)

[bgrgicak]

Where does this message come from?

The message comes from this catch code.

How can I recreate this error using your plugin?
Would you be able to share your blueprint with us?

[bgrgicak]

And why is an OPTIONS request being sent here instead of the actual POST?

I assume that these are CORS preflight requests.

The plugin establishes an HTTP connection for a translation of texts in the website to a PHP script I developed for this purpose, which serves as a proxy for the actual API-interface.

Do you see any CORS errors in the browser console when this request is made?

If I understood correctly your plugin is making requests to a server. Does this server have CORS enabled?

[threadi]

Would you be able to share your blueprint with us?

Sure, look here: https://plugins.svn.wordpress.org/easy-language/assets/blueprints/blueprint.json

Do you see any CORS errors in the browser console when this request is made?

Yes, I see an error message there relating to CORS. But only in the Playground - it doesn't occur in a normal WordPress installation.

[bgrgicak]

But only in the Playground - it doesn't occur in a normal WordPress installation.

That's expected. If a server requests files from an endpoint, CORS permissions don't apply to it.
If a browser does it, it checks for CORS permissions first and stops the requests if the permissions are set to deny.

I edited the blueprint you shared to include your plugin:

{
  "landingPage": "/wp-admin/admin.php?page=easy_language_settings",

  "preferredVersions": {
    "php": "8.2",

    "wp": "latest"
  },

  "features": {
    "networking": true
  },

  "steps": [
	{
		"step": "installPlugin",
		"pluginZipFile": {
			"resource": "wordpress.org/plugins",
			"slug": "easy-language"
		},
		"options": {
			"activate": true
		}
	},
    {
      "step": "login",

      "username": "admin",

      "password": "password"
    },

    {
      "step": "mkdir",

      "path": "/wordpress/wp-content/languages/plugins"
    },

    {
      "step": "mkdir",

      "path": "/wordpress/wp-content/languages/themes"
    },

    {
      "step": "writeFile",

      "path": "/wordpress/wp-content/languages/de_DE.mo",

      "data": {
        "resource": "url",

        "caption": "Downloading de_DE.mo",

        "url": "https://translate.wordpress.org/projects/wp/dev/de/default/export-translations?format=mo"
      }
    },

    {
      "step": "writeFile",

      "path": "/wordpress/wp-content/languages/admin-de_DE.mo",

      "data": {
        "resource": "url",

        "caption": "Downloading admin-de_DE.mo",

        "url": "https://translate.wordpress.org/projects/wp/dev/admin/de/default/export-translations?format=mo"
      }
    },

    {
      "step": "setSiteOptions",

      "options": {
        "WPLANG": "de_DE"
      }
    }
  ]
}

When I run it on Playground
there is a CORS error for this endpoint https://api.wordpress.org/themes/update-check/1.1/.
Is this the CORS error you are referring to? If not, what is the is the request URL and how can I trigger this request using this Playground link?

[threadi]

First of all, thank you for your support and for your questions.

The CORS messages that you see immediately after setup are actually not my problem. Once the Playground is loaded, go to "Seiten" (ala Pages) and click on one of the "+" icons in the table. In the dialog that opens, click on the blue "Simplify now with..." button. At that moment, a request is triggered via AJAX and sent to my proxy (external URL starting with https://api.laolaweb.com). This is exactly what arrives at my server with the HTTP method OPTIONS - unlike when I do this with a WordPress installation outside the Playground (the post-request arrives directly, which is also expected from me). You can't see it in the console, sorry for the confusion at first.

EDIT: Incidentally, the request is sent via wp_safe_remote_post().

[bgrgicak]

This looks like a CORS issue to me.
Because Playground runs in a browser it can only send requests to servers that allow CORS requests. A typical PHP server doesn't have this restriction.

I verified your domain api.laolaweb.com and it doesn't allow CORS requests. Here is a link to a CORS tester that confirms it.

You can also test this by executing a fetch request in your browser console await fetch('https://api.laolaweb.com'); .
This is similar to what Playground does in the background.

To resolve this you will need to add CORS support to your server, or create a proxy server that supports CORS and route your requests through it if you can't modify CORS headers on your API server.

I'm closing this issue as it doesn't seem like there is anything we can do in Playground, but please feel free to keep commenting here, I'm happy to help.

[threadi]

Thank you for your support. I think this issue will also help others who are facing exactly the same challenge. By the way, I only had to add the following on my server before every other issue to solve this:

if( 'OPTIONS' === $_SERVER['REQUEST_METHOD'] ) {
    header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE');
    header("Access-Control-Allow-Headers: $_SERVER[HTTP_ACCESS_CONTROL_REQUEST_HEADERS]");
    header("Content-Length: 0");
    header("Content-Type: text/plain");
    exit;
}

[adamziel]

Linking to #772 as variations of this issue come up frequently. We should find a way of telling the developer what went wrong, it could even be an mu-plugin that overrides window.fetch with a version that logs an extra error message discussing CORS. Ideally, every popular gotcha would log a clear message providing a clear way forward without going through GitHub issues. @bgrgicak would you please start a new high-priority issue to track that? FYI @brandonpayton