REST API: Attempting to create or update a non-existent setting doesn't return an error response

[johnbillion]

Attempting to create a new setting via a POST request to /wp/v2/settings returns a 200 response, despite the request having been invalid. The same goes for attempting to update a non-existent setting with a PUT request.

I would have expected maybe a 400 from such requests.

The internal logic in WP_REST_Settings_Controller routes the request through the update_item() method, treats it as a setting update, and silently ignores the problem.

[johnbillion]

The test in 41604.test.patch​ demonstrates the issue.

Trac: https://core.trac.wordpress.org/ticket/41604

Problem
The /wp/v2/settings endpoint currently accepts POST requests with empty bodies or invalid parameters and incorrectly returns the site settings instead of proper error responses.
Current behavior (incorrect):
POST /wp/v2/settings with empty body → Returns settings (should be 400)
POST /wp/v2/settings with {"invalid_param": "value"} → Returns settings (should be 400)
POST /wp/v2/settings with {"title": "New", "invalid_param": "value"} → Returns settings (should be 400)

Root Cause
The WordPress REST API args validation system only validates known parameters defined in the schema. When no settings are registered with show_in_rest => true, or when unknown parameters are provided, the validation framework doesn't reject the request, allowing the update_item() callback to execute and return settings data.

Solution
Added parameter validation in the update_item() method of WP_REST_Settings_Controller to:
Reject empty request bodies - POST/PUT/PATCH requests must contain parameters
Reject invalid parameters - Only allow parameters that correspond to registered settings
Return appropriate HTTP 400 errors with descriptive messages

Expected Behavior After Fix

• Proper error responses:

1. POST /wp/v2/settings with {} → 400: "Request body cannot be empty."
2. POST /wp/v2/settings with {"invalid_param": "value"} → 400: "Invalid parameter(s) provided."
3. POST /wp/v2/settings with {"title": "New", "invalid_param": "value"} → 400: "Invalid parameter(s) provided."

• Valid requests still work:

1. POST /wp/v2/settings with {"title": "New Title"} → Updates setting and returns updated settings

[sheldorofazeroth]

Replying to johnbillion:

Attempting to create a new setting via a POST request to /wp/v2/settings returns a 200 response, despite the request having been invalid. The same goes for attempting to update a non-existent setting with a PUT request.

I would have expected maybe a 400 from such requests.

The internal logic in WP_REST_Settings_Controller routes the request through the update_item() method, treats it as a setting update, and silently ignores the problem.

This same issue persists when an empty body is sent in the update request. The PR I raised addresses all the cases in which the settings API doesn't return the expected response. For more details on the issue and the steps to reproduce it, please go through the description of the pull request.

[johnbillion]

This is looking good, but we'll need tests for this change too. Is that something you can look at @sheldorofazeroth? A good starting point would be the existing tests in tests/phpunit/tests/rest-api.

[johnbillion]

In 60301:

REST API: Return a more appropriate HTTP 400 response code when attempting to create or update a non-existent setting.

This switches the response from a 200, which is not appropriate for invalid requests.

Props sheldorofazeroth, johnbillion

Fixes #41604

[Mamaduka]

The Gutenberg e2e tests discovered a regression after r60301.

The requests can contain global query parameters, such as _locale, which fail to pass ! empty( array_diff_key( $params, $options ) ) check:

An actual request made by the block editor to update settings: http://trunk.test/wp-json/wp/v2/settings?_locale=user.

[johnbillion]

Failing workflow run: ​https://github.com/WordPress/gutenberg/actions/runs/15599732038

Trac ticket: Core-41604

[johnbillion]

PR here that adds a failing test: ​https://github.com/WordPress/wordpress-develop/pull/8967

[johnbillion]

@Mamaduka @sheldorofazeroth The _locale URL query parameter appears to be a special case handled by determine_locale(). Are there other parameters or cases you think could break with this change?

[sheldorofazeroth]

@johnbillion @Mamaduka I think it would be best if there is a small change to the code. Instead of using
$request->get_params(); I can use $request->get_body_params(). This will only consider the POST request body and not the URL parameters. Let me know your thoughts on this. I'll make the change once I hear back from you.

[johnbillion]

I think that makes sense. Let's give it a try. You can use my tests from ​https://github.com/WordPress/wordpress-develop/pull/8967 and add any more that you see fit.

Trac ticket: https://core.trac.wordpress.org/ticket/41604

This PR fixes the issue pointed out by @Mamaduka i.e., the API can contain global query parameters, such as _locale, which fail to pass. This is fixed by replacing the $request->get_params(); by $request->get_body_params()

[sheldorofazeroth]

@johnbillion I've raised the PR. Can you please have a look at it ?

[wildworks]

I think $request->get_body_params() only works if the request is sent in form format. If the request is sent in JSON format (application/json), the parameters cannot be retrieved correctly.

I think the endpoint needs to guarantee that it will work no matter which format the request is sent in.

Theoretically, the following approach is possible, but it might not be suitable:

$params = array_merge(
    $request->get_body_params(),
    $request->get_json_params()
);

[sheldorofazeroth]

@wildworks Due to this issue, I used $request->get_params(); but as it also picked the URL parameters, therefore I changed it to $request->get_body_params().

I agree with your point. I think the below code can fix this:

$params = $request->get_params();
$url_params = $request->get_url_params();
$query_params = $request->get_query_params();
$params = array_diff_key( $params, $url_params, $query_params );

@wildworks @johnbillion let me know what you think? I'll update my PR accordingly.

[johnbillion]

@sheldorofazeroth Feel free to try things out in your PR, you don't need to ask each time :)

Don't forget there's also the tests from ​https://github.com/WordPress/wordpress-develop/pull/8967 that should go in, plus any others you think are appropriate to add.

[sheldorofazeroth]

I've updated the PR to accept the request in all formats.

[wildworks]

@sheldorofazeroth could you check the following points?

• The Settings API doesn't accept URL parameters, so I believe $request->get_url_params() can be removed.
• Let's add unit tests. See https://core.trac.wordpress.org/ticket/41604?replyto=20#comment:19

[sheldorofazeroth]

@wildworks if $request->get_url_params() then the case about gutenberg pointed out by @Mamaduka will not be covered. Here is the issue @Mamaduka pointed out https://core.trac.wordpress.org/ticket/41604?#comment:7. @wildworks Let me know what you think.

[wildworks]

Replying to sheldorofazeroth:

Let's review the definitions of words and the roles of methods. For example, suppose we receive the following request:

/wp/v2/posts/123/?param=value

This is my understanding, but please correct me if I'm wrong.

• URL Parameter: The 123 in the URL corresponds to this. This can be obtained using the get_url_params method.
• Query Parameter: The param=value in the URL corresponds to this. This can be obtained using the get_query_params method.

Since the Settings endpoint does not accept the URL parameter, the get_url_params() method should not be necessary.

[sheldorofazeroth]

@wildworks got your point. I've updated the PR now.

[wildworks]

@sheldorofazeroth Can you add unit tests?

[sheldorofazeroth]

@wildworks I've added the unit tests and updated the PR. Please have a look.

[wildworks]

I tested the latest patch (​PR 8975) and it works fine.

• Create a new post.
• Insert a Site logo, Site Tagline, and Site Logo block.
• Make changes to the blocks.
• Save the post.
  • Before: 400 error occurred.
  • After: The post is saved successfully and the settings are updated correctly.

@johnbillion @Mamaduka I think this patch can be shipped, what are your thoughts on this? Or is there a different approach?

[Mamaduka]

Can't think of a different approach at the moment. If the unit tests and e2e tests are passing, then the latest patch appears to be a good option to land.

P.S. I assumed that the schema handled the individual parameter validation, but that doesn't seem to be the case here. cc @TimothyBlynJacobs

[johnbillion]

In 60357:

Options, Meta APIs: Account for URL query parameters when checking the validity of requests to the /wp/v2/settings REST API route.

Follow-up to [60301].

Props sheldorofazeroth, Mamaduka, wildworks, johnbillion

Fixes #41604

[swissspidy]

This looks like a breaking change to me.

I was just testing 6.9 RC 3 with the Web Stories plugin and noticed that I can no longer update settings. The plugin updates settings with a POST request to wp-json/wp//settings/?some_setting_field=<newvalue> and an empty body.

This works fine in 6.8 and below. But with 6.9 I now get the Request body cannot be empty. HTTP 400 error.

Not saying that updating settings via GET instead of POST is correct, but I'm sure it's not the only plugin doing this.

Reopening for visibility.

[johnbillion]

@swissspidy This is being treated as an "empty" request because the new logic checks for validity by fetching all parameters that are not present in the URL (array_diff_key( $request->get_params(), $request->get_query_params() )).

Can we handle this as a valid request while also detecting an empty body?

[johnbillion]

I'm going to revert this for 6.9 as we don't have a patch for handling settings value updates via URL query parameters instead of body data.

This appears to be an oddity of the WP REST API that wasn't considered. WP_REST_Request::get_params() reads parameter values from both body data and URL query parameters, meaning the latter can be used in place of the former. So while updating data via a POST but passing data in via URL query parameters does seem strange, it's fully supported. This change needs to account for that usage.

[johnbillion]

In 61324:

Options, Meta APIs: Revert additional request validity handling that was added to the /wp/v2/settings REST API route. This change needs more work to account for URL query parameters used in place of body data.

This reverts [60357] and [60301].

See #41604

[johnbillion]

Requesting approval for backport to the 6.9 branch.

[ellatrix]

A revert sounds good to me. Would love more opinions.

[wildworks]

Requesting approval for backport to the 6.9 branch.

This seems like the best option for now.

Let's leave this ticket open, change the milestone to 7.0, and revisit the ideal approach after we commit to the 6.9 branch.

[SergeyBiryukov]

In 61335:

Options, Meta APIs: Revert additional request validity handling that was added to the /wp/v2/settings REST API route. This change needs more work to account for URL query parameters used in place of body data.

This reverts [60357] and [60301].

Reviewed by johnbillion, SergeyBiryukov.
Merges [61324] to the 6.9 branch.

See #41604.