Add an endpoint for fetching block patterns from WordPress.org, and load the block patterns from this new API. Remove the block patterns that have already been moved to WordPress.org/patterns.
Props ryelle, iandunn, youknowriad, timothyblynjacobs.
Fixes#53246.
Built from https://develop.svn.wordpress.org/trunk@51021
git-svn-id: http://core.svn.wordpress.org/trunk@50630 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When validating `enum` values as `integer` or `number`, consider a number with a zero fractional part to be equivalent to an integer of the same value.
In `rest_are_values_equal()`, when comparing two values of type `int` or `float` (in any combination), first cast both of them to `float` and then compare.
This matches some test cases from the official JSON Schema test suite.
Follow-up to [50010].
Props yakimun, stefanjoebstl, TimothyBlynJacobs, rachelbaker.
Fixes#52932.
Built from https://develop.svn.wordpress.org/trunk@50653
git-svn-id: http://core.svn.wordpress.org/trunk@50265 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, only the first error message for each parameter was made available. Now, all error messages for a parameter are concatenated. Additionally, the detailed error for each parameter is made available in a new `details` section of the validation error. Each error is formatted following the standard REST API error formatting.
The `WP_REST_Server::error_to_response` method has been abstracted out into a standalone function `rest_convert_error_to_response` to allow for reuse by `WP_REST_Request`. The formatted errors now also contain an `additional_data` property which contains the additional error data provided by `WP_Error::get_all_error_data`.
Props dlh, xkon, TimothyBlynJacobs.
Fixes#46191.
Built from https://develop.svn.wordpress.org/trunk@50150
git-svn-id: http://core.svn.wordpress.org/trunk@49829 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces a new endpoint, `wp/v2/users/me/application-passwords/introspect`, that will return details about the App Password being used to authenticate the current request. This allows for an application to disambiguate between multiple installations of their application which would all share the same `app_id`.
Props xkon, peterwilsoncc, TimothyBlynJacobs.
Fixes#52275.
Built from https://develop.svn.wordpress.org/trunk@50065
git-svn-id: http://core.svn.wordpress.org/trunk@49766 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the `enum` keyword was validated by perform a strict equality check. For `string` types this is generally ok, but it prevented using alternative types like `number` when rich type support isn't available.
Now the same level of type coercion/sanitization is applied when validating `enum` as all other validation checks. This means that a value of `"1"` will be accepted for an `enum` of `[ 0, 1 ]`. Additionally, `object` types now properly ignore key order when checking for equality.
Props yakimun.
Fixes#51911.
Built from https://develop.svn.wordpress.org/trunk@50010
git-svn-id: http://core.svn.wordpress.org/trunk@49711 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the majority of JSON Schema validation errors returned a generic `rest_invalid_param` error code. In preparation for #46191, where the underlying validation error code will be exposed, this commit adds specific error codes for each failure scenario.
Fixes#52317.
Built from https://develop.svn.wordpress.org/trunk@50007
git-svn-id: http://core.svn.wordpress.org/trunk@49708 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows for REST API routes to define more complex validation requirements as JSON Schema instead of procedural validation.
The error code returned from `rest_validate_value_from_schema` for invalid parameter types has been changed from the generic `rest_invalid_param` to the more specific `rest_invalid_type`.
Props yakimun, johnbillion, TimothyBlynJacobs.
Fixes#51025.
Built from https://develop.svn.wordpress.org/trunk@49246
git-svn-id: http://core.svn.wordpress.org/trunk@49008 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This provides more flexibility when writing tests and benefits from running in a front-end context which is necessary for some tests like checking that updates are supported. Additionally, this provides a more robust interface for developers who want to integrate with Site Health tests.
Because the `wp/v2` endpoint is reserved for modeling core entities, site health is registered in its own `wp-site-health/v1` namespace.
The existing ajax actions have been maintained for backward compatibility.
Props Clorith, chrisvanpatten, afragen, pokhriyal, TimothyBlynJacobs.
Fixes#48105.
Built from https://develop.svn.wordpress.org/trunk@49154
git-svn-id: http://core.svn.wordpress.org/trunk@48916 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In WordPress 4.4 the REST API was first introduced. A few releases later in WordPress 4.7, the Content API endpoints were added, paving the way for Gutenberg and countless in-site experiences. In the intervening years, numerous plugins have built on top of the REST API. Many developers shared a common frustration, the lack of external authentication to the REST API.
This commit introduces Application Passwords to allow users to connect to external applications to their WordPress website. Users can generate individual passwords for each application, allowing for easy revocation and activity monitoring. An authorization flow is introduced to make the connection flow simple for users and application developers.
Application Passwords uses Basic Authentication, and by default is only available over an SSL connection.
Props georgestephanis, kasparsd, timothyblynjacobs, afercia, akkspro, andraganescu, arippberger, aristath, austyfrosty, ayesh, batmoo, bradyvercher, brianhenryie, helen, ipstenu, jeffmatson, jeffpaul, joostdevalk, joshlevinson, kadamwhite, kjbenk, koke, michael-arestad, Otto42, pekz0r, salzano, spacedmonkey, valendesigns.
Fixes#42790.
Built from https://develop.svn.wordpress.org/trunk@49109
git-svn-id: http://core.svn.wordpress.org/trunk@48871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This method is useful whenever a JSON Schema needs to be converted to a format suitable for argument validation with `WP_REST_Request`. Moving the logic into a standalone function allows developers to use it outside of the `WP_REST_Controller` context.
Props pentatonicfunk.
Fixes#50876.
Built from https://develop.svn.wordpress.org/trunk@48951
git-svn-id: http://core.svn.wordpress.org/trunk@48713 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [48306] support for multi-typed schemas was improved to first detect the data type of the value before applying further validation. The `integer` data type was detected using the new `rest_is_integer` function. This function used logic, however, that assumed that the value had already passed an `is_numeric` check. This meant that if `integer` and `string` were both acceptable types, the value would always be considered an `integer` causing the later accurate type validation to fail.
This commit fixes the `rest_is_integer` logic to include an `is_numeric` check.
Props rtagliento.
Fixes#51146.
Built from https://develop.svn.wordpress.org/trunk@48881
git-svn-id: http://core.svn.wordpress.org/trunk@48643 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [47758] a new function `rest_filter_response_by_context` was introduced to expand the JSON schema features supported by the context filtering mechanism.
This commit improves the performance of that function by eliminating repetitive comparisons and loops. Additionally, it improves multi-type support for object + array types.
Fixes#50700.
Props dlh.
Built from https://develop.svn.wordpress.org/trunk@48555
git-svn-id: http://core.svn.wordpress.org/trunk@48317 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The REST API treats routes without a permission_callback as public. Because this happens without any warning to the user, if the permission callback is unintentionally omitted or misspelled, the endpoint can end up being available to the public. Such a scenario has happened multiple times in the wild, and the results can be catostrophic when it occurs.
For REST API routes that are intended to be public, it is recommended to set the permission callback to the `__return_true` built in function.
Fixes#50075.
Props rmccue, sorenbronsted, whyisjake, SergeyBiryukov, TimothyBlynJacobs.
Built from https://develop.svn.wordpress.org/trunk@48526
git-svn-id: http://core.svn.wordpress.org/trunk@48288 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A multi-type schema is a schema where the `type` keyword is an array of possible types instead of a single type. For instance, `[ 'object', 'string' ]` would allow objects or string values.
In [46249] basic support for these schemas was introduced. The validator would loop over each schema type trying to find a version that matched. This worked for valid values, but for invalid values it provided unhelpful error messages. The sanitizer also had its utility restricted.
In this commit, the validators and sanitizers will first determine the best type of the passed value and then apply the schema with that set type. In the case that a value could match multiple types, the schema of the first matching type will be used.
To maintain backward compatibility, if unsupported schema types are used, the value will always pass validation. A doing it wrong notice is issued in this case.
Fixes#50300.
Props pentatonicfunk, dlh, TimothyBlynJacobs.
Built from https://develop.svn.wordpress.org/trunk@48306
git-svn-id: http://core.svn.wordpress.org/trunk@48075 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows for using multi-type support with a string that has a format. For backwards compatibility support, the format validation will still apply if the type is not specified, or it is invalid.
Two new doing it wrong notices are issued when omitting a type, or using an invalid type.
Props ryotsun.
Fixes#50189.
Built from https://develop.svn.wordpress.org/trunk@48300
git-svn-id: http://core.svn.wordpress.org/trunk@48069 1a063a9b-81f0-0310-95a4-ce76da25c4cd
