Query this endpoint to retrieve a collection of {{ plural }}. The response you receive can be controlled and filtered using the URL query parameters below.
36 | {% endif %}
37 |
--------------------------------------------------------------------------------
/bin/generate-manifest.php:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env php
2 | $slug,
33 | 'parent' => $parent,
34 | 'markdown_source' => sprintf( 'https://github.com/%s/blob/master/%s.md', $repo, $key ),
35 | );
36 | }
37 | }
38 |
39 | file_put_contents( $root . '/bin/manifest.json', json_encode( (object) $manifest, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES ) );
40 |
41 | $count = count( $manifest );
42 | echo "Generated manifest.json of {$count} pages\n";
43 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # API Docs
2 |
3 | This repo contains the source for [documentation for the API](https://developer.wordpress.org/rest-api/) on developer.wordpress.org (DevHub).
4 |
5 | ## Adding/Removing Files
6 |
7 | When creating new files, these must be added to the manifest. Run `bin/generate-manifest.php` to update this.
8 |
9 | Removing files also requires regenerating the manifest. After deletion and sync with DevHub, the page also needs to be manually deleted from DevHub.
10 |
11 | ## Refreshing the Templated API Reference
12 |
13 | The reference section is created by parsing the output of a site's schema as retrieved from that site's REST API index route. The current method used to generate this approach is as follows:
14 |
15 | - Create a local WordPress environment (always use the current or Release Candidate version of WordPress) using the local environment tool of your choice.
16 | - Edit `/etc/hosts` to map the domain `example.com` to the IP of that WordPress instance, and ensure the site is configured to run at `example.com`.
17 | - Run `composer install` in this project's root directory to install dependencies.
18 | - Run `composer run-script regenerate` in this project's root directory to run the asset regeneration script.
19 | - Use `git status` and `git diff` to validate that the files were updated as expected.
20 |
--------------------------------------------------------------------------------
/bin/templates/reference-parts/schema.html:
--------------------------------------------------------------------------------
1 |
Schema
2 |
The schema defines all the fields that exist within a {{ name }} record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
3 |
4 | {% for key, property in schema.properties %}
5 |
The schema defines all the fields that exist within a navigation fallback record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
The unique identifier for the Navigation Menu.
17 |
18 | JSON data type: integer
19 |
Read only
20 |
Context: view, edit, embed
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
Retrieve a Navigation Fallback
31 |
32 |
Definition & Example Request
33 |
34 | GET /wp-block-editor/v1/navigation-fallback
35 |
36 |
Query this endpoint to retrieve a specific navigation fallback record.
46 |
--------------------------------------------------------------------------------
/extending-the-rest-api.md:
--------------------------------------------------------------------------------
1 | # Extending the REST API
2 |
3 | ## Guides
4 |
5 | [Modifying responses](https://developer.wordpress.org/rest-api/extending-the-rest-api/modifying-responses/): add fields to REST API response objects using `register_meta` or `register_rest_field`
6 |
7 | [Adding Endpoints](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/): create custom REST API endpoints for your plugin or application
8 |
9 | [Working with Custom Content Types](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/): learn how to interact with your [custom post types](https://developer.wordpress.org/plugins/post-types/) and [custom taxonomies](https://developer.wordpress.org/plugins/post-types/) through the REST API
10 |
11 |
12 | ## Resources
13 |
14 | [Defining your API Schema](https://developer.wordpress.org/rest-api/extending-the-rest-api/schema/): define the schema for your REST API resources and their arguments
15 |
16 | [Glossary](https://developer.wordpress.org/rest-api/glossary/): get up to speed with phrases used throughout our documentation
17 |
18 | [Routes & Endpoints](https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/): dive deeper into the nuances of REST API routes and the endpoints they provide
19 |
20 | [Controller Classes](https://developer.wordpress.org/rest-api/extending-the-rest-api/controller-classes/): discover how to structure and extend REST API endpoint controller classes
21 |
22 |
23 | [Frequently Asked Questions](https://developer.wordpress.org/rest-api/frequently-asked-questions/): see some of the most frequent inquiries about the REST API and learn how to solve common problems
24 |
--------------------------------------------------------------------------------
/using-the-rest-api.md:
--------------------------------------------------------------------------------
1 | # Using the REST API
2 |
3 | These articles explore the basic structure of the WordPress REST API.
4 |
5 | [Global Parameters](https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/): learn about the global REST API query parameters that apply to every endpoint
6 |
7 | [Pagination](https://developer.wordpress.org/rest-api/using-the-rest-api/pagination/): work with large collections of resources & control how many records you receive from the REST API
8 |
9 | [Linking & Embedding](https://developer.wordpress.org/rest-api/using-the-rest-api/linking-and-embedding/): understand how to read and modify connections between different objects, and embed related resources such as author and media data in the REST API's responses
10 |
11 | [Discovery](https://developer.wordpress.org/rest-api/using-the-rest-api/discovery/): determine what REST API resources a site supports, and where they are located
12 |
13 | [Authentication](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/): authorize your REST API requests so that you can create, update and delete your data
14 |
15 | [Frequently Asked Questions](https://developer.wordpress.org/rest-api/frequently-asked-questions/): see some of the most frequent inquiries about the REST API and learn how to solve common problems
16 |
17 |
18 | ## Resources & Utilities
19 |
20 | [Backbone.js Client](https://developer.wordpress.org/rest-api/using-the-rest-api/backbone-javascript-client/): interact with the API from within WP-Admin using Backbone models & collections
21 |
22 | [Client Libraries](https://developer.wordpress.org/rest-api/using-the-rest-api/client-libraries/): utilities in a variety of programming languages that simplify interacting with the API
23 |
--------------------------------------------------------------------------------
/bin/parse-wxr.php:
--------------------------------------------------------------------------------
1 | ' => '## ',
9 | '' => '',
10 | '
The schema defines all the fields that exist within a block pattern category record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | name
14 |
15 |
16 |
The category name.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: view, edit, embed
21 |
22 |
23 |
24 |
25 | label
26 |
27 |
28 |
The category label, in human readable format.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: view, edit, embed
33 |
34 |
35 |
36 |
37 | description
38 |
39 |
40 |
The category description, in human readable format.
41 |
42 | JSON data type: string
43 |
Read only
44 |
Context: view, edit, embed
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
Retrieve a Block Pattern Category
55 |
56 |
Definition & Example Request
57 |
58 | GET /wp/v2/block-patterns/categories
59 |
60 |
Query this endpoint to retrieve a specific block pattern category record.
The schema defines all the fields that exist within a Rendered Block record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
78 |
--------------------------------------------------------------------------------
/using-the-rest-api/client-libraries.md:
--------------------------------------------------------------------------------
1 | # Client Libraries
2 |
3 | The API can be used from any application by sending basic HTTP requests; however, client libraries simplify the process of querying or creating specific resources. These libraries make it easy to connect an external application to the WordPress REST API using a variety of programming languages.
4 |
5 | [alert]Aside from the Backbone.js client, these libraries are not part of WordPress core, and are not necessarily maintained or endorsed by the WordPress REST API team.[/alert]
6 |
7 | [info]To perform authenticated requests from outside of the WordPress admin, themes, or plugins, a separate authentication plugin is required.[/info]
8 |
9 | ## PHP
10 |
11 | [Requests](https://github.com/WordPress/Requests) for PHP is a general purpose HTTP request library. While not specifically designed for the WordPress REST API, it is a great tool for interacting with any HTTP API.
12 |
13 | [WordPress-PHP-SDK](https://github.com/madeITBelgium/WordPress-PHP-SDK) is a PHP SDK for the WordPress REST API, which can be installed using [composer](https://getcomposer.org/).
14 |
15 | [WordPress-SDK](https://github.com/storipress/wordpress-sdk) is a Laravel package for the WordPress REST API, which can be installed using [composer](https://getcomposer.org).
16 |
17 | ## JavaScript
18 |
19 | The [Backbone.js client](https://developer.wordpress.org/rest-api/backbone-javascript-client/) is built in to WordPress core and provides Backbone.js models & collections for working with REST API resources.
20 |
21 | [node-wpapi](http://wp-api.org/node-wpapi) is an isomorphic JavaScript client library for querying or writing to the REST API using an intuitive chaining syntax. It can be used with Node.js or with client-side JavaScript applications.
22 |
23 | [ember-wordpress](https://github.com/oskarrough/ember-wordpress) provides a connection between Ember Data and the REST API
24 |
25 |
26 | ## Ruby
27 |
28 | [wp-api-client](https://github.com/duncanjbrown/wp-api-client): a read-only REST API client written in Ruby.
29 |
30 | ## C# / .NET
31 | [WordPressPCL](https://github.com/wp-net/WordPressPCL): a full REST API client written in C#.
32 |
33 | ## Dart / Flutter
34 | [wordpress_client](https://pub.dev/packages/wordpress_client): A library exposing a fluent api to interact with the WordPress REST API.
35 |
--------------------------------------------------------------------------------
/using-the-rest-api/pagination.md:
--------------------------------------------------------------------------------
1 | # Pagination
2 |
3 | WordPress sites can have a lot of content—far more than you'd want to pull down in a single request. The API endpoints default to providing a limited number of items per request, the same way that a WordPress site will default to 10 posts per page in archive views.
4 |
5 |
6 | ## Pagination Parameters
7 |
8 | Any API response which contains multiple resources supports several common query parameters to handle paging through the response data:
9 |
10 | * `?page=`: specify the page of results to return.
11 | * For example, `/wp/v2/posts?page=2` is the second page of posts results
12 | * By retrieving `/wp/v2/posts`, then `/wp/v2/posts?page=2`, and so on, you may access every available post through the API, one page at a time.
13 |
14 | * `?per_page=`: specify the number of records to return in one request, specified as an integer from 1 to 100.
15 | * For example, `/wp/v2/posts?per_page=1` will return only the first post in the collection
16 |
17 | * `?offset=`: specify an arbitrary offset at which to start retrieving posts
18 | * For example, `/wp/v2/posts?offset=6` will use the default number of posts per page, but start at the 6th post in the collection
19 | * `?per_page=5&page=4` is equivalent to `?per_page=5&offset=15`
20 |
21 | [tip]
22 | Large queries can hurt site performance, so per_page is capped at 100 records. If you wish to retrieve more than 100 records, for example to build a client-side list of all available categories, you may make multiple API requests and combine the results within your application.
23 | [/tip]
24 |
25 | To determine how many pages of data are available, the API returns two header fields with every paginated response:
26 |
27 | * `X-WP-Total`: the total number of records in the collection
28 | * `X-WP-TotalPages`: the total number of pages encompassing all available records
29 |
30 | By inspecting these header fields you can determine how much more data is available within the API.
31 |
32 |
33 | ## Ordering Results
34 |
35 | In addition to the pagination query parameters detailed above, several other parameters control the order of the returned results:
36 |
37 | * `?order=`: control whether results are returned in ascending or descending order
38 | * Valid values are `?order=asc` (for ascending order) and `?order=desc` (for descending order).
39 | * All native collections are returned in descending order by default.
40 | * `?orderby=`: control the field by which the collection is sorted
41 | * The valid values for `orderby` will vary depending on the queried resource; for the `/wp/v2/posts` collection, the valid values are "date," "relevance," "id," "include," "title," and "slug"
42 | * See the [REST API reference](https://developer.wordpress.org/rest-api/reference) for the values supported by other collections
43 | * All collections with dated resources default to `orderby=date`
44 |
--------------------------------------------------------------------------------
/reference/wp_global_styles.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Global_Styles
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a global_styles record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
ID of global styles config.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: embed, view, edit
21 |
22 |
23 |
24 |
25 | styles
26 |
27 |
28 |
Global styles.
29 |
30 | JSON data type: object
31 |
Context: view, edit
32 |
33 |
34 |
35 |
36 | settings
37 |
38 |
39 |
Global settings.
40 |
41 | JSON data type: object
42 |
Context: view, edit
43 |
44 |
45 |
46 |
47 | title
48 |
49 |
50 |
Title of the global styles variation.
51 |
52 | JSON data type: object or string
53 |
Context: embed, view, edit
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
Retrieve a Global_Styles
64 |
65 |
Definition & Example Request
66 |
67 | GET /wp/v2/global-styles/<id>
68 |
69 |
Query this endpoint to retrieve a specific global_styles record.
The schema defines all the fields that exist within a menu location record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | name
14 |
15 |
16 |
The name of the menu location.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: embed, view, edit
21 |
22 |
23 |
24 |
25 | description
26 |
27 |
28 |
The description of the menu location.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: embed, view, edit
33 |
34 |
35 |
36 |
37 | menu
38 |
39 |
40 |
The ID of the assigned menu.
41 |
42 | JSON data type: integer
43 |
Read only
44 |
Context: embed, view, edit
45 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
Retrieve a Menu Location
55 |
56 |
Definition & Example Request
57 |
58 | GET /wp/v2/menu-locations
59 |
60 |
Query this endpoint to retrieve a specific menu location record.
Scope under which the request is made; determines fields present in response.
112 |
113 | Default: view
114 |
115 |
One of: view, embed, edit
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 |
--------------------------------------------------------------------------------
/key-concepts.md:
--------------------------------------------------------------------------------
1 | # Key Concepts
2 |
3 | In this page we'll break down some of the key concepts and terms associated with the REST API: **Routes & Endpoints,** **Requests**, **Responses**, **Schema**, and **Controller Classes**. Each of these concepts play a crucial role in understanding, using, and extending the WordPress REST API, and each is explored in greater depth within this handbook.
4 |
5 | ## Routes & Endpoints
6 |
7 | In the context of the WordPress REST API a **route** is a URI which can be mapped to different HTTP methods. The mapping of an individual HTTP method to a route is known as an **endpoint**.
8 |
9 | As an example, if we make a `GET` request to the URI http://oursite.com/wp-json/ we are returned a JSON response showing what routes are available, and what endpoints are available within each route.
10 |
11 | `/wp-json/` is a route, and when that route receives a `GET` request then that request is handled by the endpoint which displays what is known as the index for the WordPress REST API.
12 |
13 | The route `wp-json/wp/v2/posts` by contrast has a `GET` endpoint which returns a list of posts, but also a `POST` endpoint which accepts authenticated requests to create new posts.
14 |
15 | We will learn how to register our own routes and endpoints in the following sections.
16 |
17 | [info]If you are using [non-pretty permalinks](https://wordpress.org/support/article/using-permalinks/), you should pass the REST API route as a query string parameter. The route http://oursite.com/wp-json/ in the example above would hence be http://oursite.com/?rest_route=/.[/info]
18 |
19 | If you get a `404` error when trying to access http://oursite.com/wp-json/, consider enabling pretty permalinks or try using the `rest_route` parameter instead.
20 |
21 | ## Requests
22 |
23 | A REST API request is represented within WordPress by an instance of the `WP_REST_Request` class, which is used to store and retrieve information for the current request. A `WP_REST_Request` object is automatically generated when you make an HTTP request to a registered API route.
24 |
25 | The data specified in this object (derived from the route URI or the JSON payload sent as a part of the request) determines what response you will get back out of the API.
26 |
27 | Requests are usually submitted remotely via HTTP but may also be made internally from PHP within WordPress plugin or theme code. There are a lot of neat things you can do using this class, detailed further elsewhere in the handbook.
28 |
29 | ## Responses
30 |
31 | Responses are the data you get back from the API. The `WP_REST_Response` class provides a way to interact with the response data returned by endpoints. Responses return the requested data, or can also be used to return errors if something goes wrong while fulfilling the request.
32 |
33 | ## Schema
34 |
35 | Each endpoint requires a particular structure of input data, and returns data using a defined and predictable structure. Those data structures are defined in the API Schema.
36 |
37 | The schema structures API data and provides a comprehensive list of all of the properties the API can return and which input parameters it can accept.
38 |
39 | Well-defined schema also provides one layer of security within the API, as it enables us to validate and sanitize the requests being made to the API. The [Schema section](https://developer.wordpress.org/rest-api/extending-the-rest-api/schema/) explores this large topic further.
40 |
41 |
42 | ## Controller Classes
43 |
44 | Controller classes unify and coordinate all these various moving parts within a REST API response cycle. With a controller class you can manage the registration of routes & endpoints, handle requests, utilize schema, and generate API responses.
45 |
46 | A single class usually contains all of the logic for a given route, and a given route usually represents a specific type of data object within your WordPress site (like a custom post type or taxonomy).
--------------------------------------------------------------------------------
/using-the-rest-api/linking-and-embedding.md:
--------------------------------------------------------------------------------
1 | # Linking and Embedding
2 |
3 | The WP REST API incorporates hyperlinking throughout the API to allow discoverability and browsability, as well as embedding related resources together in one response. While the REST API does not completely conform to the entire [HAL standard](https://en.wikipedia.org/wiki/Hypertext_Application_Language), it implements the `._links` and `._embedded` properties from that standard as described below.
4 |
5 |
6 | ## Links
7 |
8 | The `_links` property of the response object contains a map of links to other API resources, grouped by "relation." The relation specifies how the linked resource relates to the primary resource.
9 |
10 | Examples include:
11 | - `author` - describing a relationship between a resource and its author
12 | - `wp:term` - describing the relationship between a post and its tags or categories
13 |
14 | The relation is either a
15 | - [standardized relation](http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1)
16 | - a `URI relation` - like https://api.w.org/term
17 | - or a `Compact URI relation` - like `wp:term`
18 |
19 | Compact URI relations can be normalized to full URI relations to ensure full compatibility if required. This is similar to HTML `` tags, or `` links.
20 |
21 | The links are an object containing a `href` property with an absolute URL to the resource, as well as other optional properties. These include content types, disambiguation information, and data on actions that can be taken with the link.
22 |
23 | For collection responses (those that return a list of objects rather than a top-level object), each item contains links, and the top-level response includes links via the `Link` header instead.
24 |
25 | [info]
26 | If your client library does not allow accessing headers, you can use the _envelope parameter to include the headers as body data instead.
27 | [/info]
28 |
29 |
30 | ### Example Response
31 |
32 | A typical single post request (`/wp/v2/posts/42`):
33 |
34 | ```js
35 | {
36 | "id": 42,
37 | "_links": {
38 | "collection": [
39 | {
40 | "href": "https://example.com/wp-json/wp/v2/posts"
41 | }
42 | ],
43 | "author": [
44 | {
45 | "href": "https://example.com/wp-json/wp/v2/users/1",
46 | "embeddable": true
47 | }
48 | ]
49 | }
50 | }
51 | ```
52 |
53 |
54 | ## Embedding
55 |
56 | Optionally, some linked resources may be included in the response to reduce the number of HTTP requests required. These resources are "embedded" into the main response.
57 |
58 | Embedding is triggered by setting the [`_embed` query parameter](https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_embed) on the request. This will then include embedded resources under the `_embedded` key adjacent to the `_links` key. The layout of this object mirrors the `_links` object, but includes the embedded resource in place of the link properties.
59 |
60 | Only links with the `embeddable` flag set to `true` can be embedded, and `_embed` will cause all embeddable links to be embedded. Only relations containing embedded responses are included in `_embedded`, however relations with mixed embeddable and unembeddable links will contain dummy responses for the unembeddable links to ensure numeric indexes match those in `_links`.
61 |
62 | When embedding a collection response, for instance `/wp/v2/posts?author=1`, the embedded collection will have the default pagination limits applied.
63 |
64 | ### Example Response
65 |
66 | ```js
67 | {
68 | "id": 42,
69 | "_links": {
70 | "collection": [
71 | {
72 | "href": "https://example.com/wp-json/wp/v2/posts"
73 | }
74 | ],
75 | "author": [
76 | {
77 | "href": "https://example.com/wp-json/wp/v2/users/1",
78 | "embeddable": true
79 | }
80 | ]
81 | },
82 | "_embedded": {
83 | "author": {
84 | "id": 1,
85 | "name": "admin",
86 | "description": "Site administrator"
87 | }
88 | }
89 | }
90 | ```
--------------------------------------------------------------------------------
/glossary.md:
--------------------------------------------------------------------------------
1 | # Glossary
2 |
3 | New to REST APIs? Get up to speed with phrases used throughout our documentation.
4 |
5 |
6 |
Controller
7 |
8 | [Model-View-Controller](http://en.wikipedia.org/wiki/Model-view-controller) is a standard pattern in software development. If you aren't already familiar with it, you should do a bit of reading to get up to speed.
9 |
10 | Within WP-API, we've adopted the controller concept to have a standard pattern for the classes representing our resource endpoints. All resource endpoints extend `WP_REST_Controller` to ensure they implement common methods.
11 |
12 |
13 |
HEAD, GET, POST, PUT, and DELETE Requests
14 |
15 | These "HTTP verbs" represent the *type* of action a HTTP client might perform against a resource. For instance, `GET` requests are used to fetch a Post's data, whereas `DELETE` requests are used to delete a Post. They're collectively called "HTTP verbs" because they're standardized across the web.
16 |
17 | If you're familiar with WordPress functions, a `GET` request is the equivalent of `wp_remote_get()`, and a `POST` request is the same as `wp_remote_post()`.
18 |
19 |
20 |
HTTP Client
21 |
22 | The phrase "HTTP Client" refers to the tool you use to interact with WP-API. You might use [Postman](https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en) (Chrome) or [REST Easy](https://github.com/nathan-osman/REST-Easy) (Firefox) to test requests in your browser, or [httpie](https://github.com/jakubroztocil/httpie) to test requests at the commandline.
23 |
24 | WordPress itself provides a HTTP Client in the [`WP_HTTP` class](https://developer.wordpress.org/plugins/http-api/) and related functions (e.g. `wp_remote_get()`). This can be used to access one WordPress site from another.
25 |
26 |
27 |
Resource
28 |
29 | A "Resource" is a *discrete entity* within WordPress. You may know these resources already as Posts, Pages, Comments, Users, Terms, and so on. WP-API permits HTTP clients to perform CRUD operations against resources (CRUD stands for Create, Read, Update, and Delete).
30 |
31 | Pragmatically, here's how you'd typically interact with WP-API resources:
32 |
33 | * `GET /wp-json/wp/v2/posts` to get a collection of Posts. This is roughly equivalent to using `WP_Query`.
34 | * `GET /wp-json/wp/v2/posts/123` to get a single Post with ID 123. This is roughly equivalent to using `get_post()`.
35 | * `POST /wp-json/wp/v2/posts` to create a new Post. This is roughly equivalent to using `wp_insert_post()`.
36 | * `DELETE /wp-json/wp/v2/posts/123` to delete Post with ID 123. This is roughly equivalent to `wp_delete_post()`.
37 |
38 |
39 |
Routes / Endpoints
40 |
41 | Endpoints are functions available through the API. This can be things like retrieving the API index, updating a post, or deleting a comment. Endpoints perform a specific function, taking some number of parameters and return data to the client.
42 |
43 | A route is the "name" you use to access endpoints, used in the URL. A route can have multiple endpoints associated with it, and which is used depends on the HTTP verb.
44 |
45 | For example, with the URL `http://example.com/wp-json/wp/v2/posts/123`:
46 |
47 | * The "route" is `wp/v2/posts/123` - The route doesn't include `wp-json` because `wp-json` is the base path for the API itself.
48 | * This route has 3 endpoints:
49 | * `GET` triggers a `get_item` method, returning the post data to the client.
50 | * `PUT` triggers an `update_item` method, taking the data to update, and returning the updated post data.
51 | * `DELETE` triggers a `delete_item` method, returning the now-deleted post data to the client.
52 |
53 | **Note:** On sites without pretty permalinks, the route is instead added to the URL as the `rest_route` parameter. For the above example, the full URL would then be `http://example.com/?rest_route=wp/v2/posts/123`
54 |
55 |
56 |
Schema
57 |
58 | A "schema" is a representation of the format for WP-API's response data. For instance, the Post schema communicates that a request to get a Post will return `id`, `title`, `content`, `author`, and other fields. Our schemas also indicate the type each field is, provide a human-readable description, and show which contexts the field will be returned in.
59 |
--------------------------------------------------------------------------------
/reference/widget-types.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Widget Types
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a widget type record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
Unique slug identifying the widget type.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: embed, view, edit
21 |
22 |
23 |
24 |
25 | name
26 |
27 |
28 |
Human-readable name identifying the widget type.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: embed, view, edit
33 |
34 |
35 |
36 |
37 | description
38 |
39 |
40 |
Description of the widget.
41 |
42 | JSON data type: string
43 |
Context: view, edit, embed
44 |
45 |
46 |
47 |
48 | is_multi
49 |
50 |
51 |
Whether the widget supports multiple instances
52 |
53 | JSON data type: boolean
54 |
Read only
55 |
Context: view, edit, embed
56 |
57 |
58 |
59 |
60 | classname
61 |
62 |
63 |
Class name
64 |
65 | JSON data type: string
66 |
Read only
67 |
Context: embed, view, edit
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 |
Retrieve a Widget Type
78 |
79 |
Definition & Example Request
80 |
81 | GET /wp/v2/widget-types
82 |
83 |
Query this endpoint to retrieve a specific widget type record.
Scope under which the request is made; determines fields present in response.
135 |
136 | Default: view
137 |
138 |
One of: view, embed, edit
139 |
140 |
141 |
142 |
143 |
144 |
145 |
146 |
--------------------------------------------------------------------------------
/using-the-rest-api/authentication.md:
--------------------------------------------------------------------------------
1 | # Authentication
2 |
3 | ## Cookie Authentication
4 |
5 | Cookie authentication is the standard authentication method included with WordPress. When you log in to your dashboard, this sets up the cookies correctly for you, so plugin and theme developers need only to have a logged-in user.
6 |
7 | However, the REST API includes a technique called [nonces](https://developer.wordpress.org/apis/security/nonces/) to avoid [CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) issues. This prevents other sites from forcing you to perform actions without explicitly intending to do so. This requires slightly special handling for the API.
8 |
9 | For developers using the built-in Javascript API, this is handled automatically for you. This is the recommended way to use the API for plugins and themes. Custom data models can extend `wp.api.models.Base` to ensure this is sent correctly for any custom requests.
10 |
11 | For developers making manual Ajax requests, the nonce will need to be passed with each request. The API uses nonces with the action set to `wp_rest`. These can then be passed to the API via the `_wpnonce` data parameter (either POST data or in the query for GET requests), or via the `X-WP-Nonce` header. If no nonce is provided the API will set the current user to 0, turning the request into an **unauthenticated request**, even if you're logged into WordPress.
12 |
13 | Note: Until recently, most software had spotty support for `DELETE` requests. For instance, PHP doesn't transform the request body of a `DELETE` request into a super global. As such, supplying the nonce as a header is the most reliable approach.
14 |
15 | It is important to keep in mind that this authentication method relies on WordPress cookies. As a result this method is only applicable when the REST API is used inside of WordPress and the current user is logged in. In addition, the current user must have the appropriate capability to perform the action being performed.
16 |
17 | As an example, this is how the built-in Javascript client creates the nonce:
18 |
19 | ```php
20 | esc_url_raw( rest_url() ),
23 | 'nonce' => wp_create_nonce( 'wp_rest' )
24 | ) );
25 | ```
26 |
27 | This is then used in the base model:
28 |
29 | ```js
30 | options.beforeSend = function(xhr) {
31 | xhr.setRequestHeader('X-WP-Nonce', wpApiSettings.nonce);
32 |
33 | if (beforeSend) {
34 | return beforeSend.apply(this, arguments);
35 | }
36 | };
37 | ```
38 |
39 | Here is an example of editing the title of a post, using jQuery AJAX:
40 |
41 | ```js
42 | $.ajax( {
43 | url: wpApiSettings.root + 'wp/v2/posts/1',
44 | method: 'POST',
45 | beforeSend: function ( xhr ) {
46 | xhr.setRequestHeader( 'X-WP-Nonce', wpApiSettings.nonce );
47 | },
48 | data:{
49 | 'title' : 'Hello Moon'
50 | }
51 | } ).done( function ( response ) {
52 | console.log( response );
53 | } );
54 | ```
55 |
56 | Note that you do not need to verify that the nonce is valid inside your custom end point. This is automatically done for you in `rest_cookie_check_errors()`.
57 |
58 | ## Basic Authentication with Application Passwords
59 |
60 | As of 5.6, WordPress has shipped with [Application Passwords](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/), which can be generated from an Edit User page (wp-admin -> Users -> Edit User).
61 |
62 | The credentials can be passed along to REST API requests served over https:// using [Basic Auth](https://ec.haxx.se/libcurl-http/auth.html#basic) / [RFC 7617](https://tools.ietf.org/html/rfc7617) — [here’s the documentation for how to use it with cURL](https://ec.haxx.se/http/auth.html).
63 |
64 | For a simple command-line script example, just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values:
65 |
66 | ```
67 | curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit
68 | ```
69 |
70 | ## Authentication Plugins
71 |
72 | Plugins may be added to support alternative modes of authentication that will work from remote applications. Some example plugins are [OAuth 1.0a Server](https://wordpress.org/plugins/rest-api-oauth1/) and [JSON Web Tokens](https://wordpress.org/plugins/jwt-authentication-for-wp-rest-api/).
73 |
74 | [info]
75 |
76 | There's also a [Basic Authentication](https://github.com/WP-API/Basic-Auth) plugin.
77 |
78 | Note that this plugin requires sending your username and password with every request, and should only be used for development and testing i.e. not in a production environment. Using Application Passwords (see above) is preferred.
79 |
80 | [/info]
81 |
--------------------------------------------------------------------------------
/index.md:
--------------------------------------------------------------------------------
1 | # REST API Handbook
2 |
3 | The WordPress REST API provides an interface for applications to interact with your WordPress site by sending and receiving data as [JSON](https://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) objects. It is the foundation of the [WordPress Block Editor](https://developer.wordpress.org/block-editor/), and can likewise enable your theme, plugin or custom application to present new, powerful interfaces for managing and publishing your site content.
4 |
5 | Using the WordPress REST API you can create a plugin to provide an entirely new admin experience for WordPress, build a brand new interactive front-end experience, or bring your WordPress content into completely separate applications.
6 |
7 | The REST API is a developer-oriented feature of WordPress. It provides data access to the content of your site, and implements the same authentication restrictions -- content that is public on your site is generally publicly accessible via the REST API, while private content, password-protected content, internal users, custom post types, and metadata is only available with authentication or if you specifically set it to be so. If you are not a developer, the most important thing to understand about the API is that it enables the block editor and modern plugin interfaces without compromising the security or privacy of your site.
8 |
9 | ## What Is A REST API?
10 |
11 | An API is an Application Programming Interface. REST, standing for "REpresentational State Transfer," is a set of concepts for modeling and accessing your application's data as interrelated objects and collections. The WordPress REST API provides REST endpoints (URLs) representing the posts, pages, taxonomies, and other built-in WordPress data types. Your application can send and receive JSON data to these endpoints to query, modify and create content on your site. JSON is an open standard data format that is lightweight and human-readable, and looks like Objects do in JavaScript. When you request content from or send content to the API, the response will also be returned in JSON. Because JSON is widely supported in many programming languages, developers can build WordPress applications in client-side JavaScript (like the block editor), as mobile apps, or as desktop or command line tools.
12 |
13 | [info]The REST API is just one of many APIs provided by WordPress. You can find the [documentation on these additional APIs here](https://codex.wordpress.org/WordPress_APIs).[/info]
14 |
15 | ## Using the WordPress REST API
16 |
17 | WordPress already provides a rich set of tools and interfaces for building sites, and you should not feel pressured to use the REST API if your site is already working the way you expect. You do not need to use the REST API to build a WordPress theme or plugin.
18 |
19 | However, if you do wish to write your theme, plugin, or external application as a client-side JavaScript application, or a standalone program in a language other than PHP, then your application will need a structured way to access content within your WordPress site. Any programming language which can make HTTP requests and interpret JSON can use the REST API to interact with WordPress, from PHP, Node.js, Go, and Java, to Swift, Kotlin, and beyond.
20 |
21 | Even if you're using vanilla JavaScript or jQuery within a theme or plugin the REST API provides a more predictable and structured way to interact with your site's content than [`admin-ajax`](https://codex.wordpress.org/AJAX_in_Plugins), enabling you to spend less time accessing the data you need and more time creating better user experiences.
22 |
23 | If you want a structured, extensible, and simple way to get data in and out of WordPress, you probably want to use the REST API.
24 |
25 | For all of its simplicity the REST API can feel quite complex at first, so in this handbook we will attempt to break it down into smaller components to explain each part of the full puzzle.
26 |
27 | ## Next Steps
28 |
29 | Familiarize yourself with the [key technical concepts](https://developer.wordpress.org/rest-api/key-concepts/) behind how the REST API functions.
30 |
31 | Learn more about how to interact with API resources and query for specific data in the [Using the REST API](https://developer.wordpress.org/rest-api/using-the-rest-api/) section.
32 |
33 | Once you're comfortable with the default workings of the default routes and methods, discover how to add new data to the API or enhance and manipulate existing response objects in the [Extending the REST API](https://developer.wordpress.org/rest-api/extending-the-rest-api/) section.
34 |
35 | For a comprehensive overview of the resources and routes available by default, review the [API reference](https://developer.wordpress.org/rest-api/reference/).
36 |
--------------------------------------------------------------------------------
/bin/regenerate.php:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env php
2 | body, true );
49 |
50 | foreach ( $parsed_data['routes'] as $key => $route ) {
51 | if ( ! isset( $route['schema'] ) ) {
52 | continue;
53 | }
54 |
55 | # make a readable route name from the route regex
56 | $route_nicename = preg_replace( '/\(\?P<(\w+?)>.*?\)/', '<\1>', $key );
57 | $route['nicename'] = $route_nicename;
58 |
59 | # group the objects by unique schema titles [ post => ..., term => ..., etc ]
60 | $title = $route['schema']['title'];
61 |
62 | # pluralise, super-dodgy.
63 | if ( substr( $title, -1 ) === 's' ) {
64 | $plural = $title;
65 | } else {
66 | $plural = substr( $title, -1 ) === 'y' ? substr( $title, 0, -1 ) . 'ies' : $title . 's';
67 | }
68 | $key = $plural;
69 |
70 | # overrides
71 | switch ( $title ) {
72 | case 'attachment':
73 | $key = 'media';
74 | $title = 'Media Item';
75 | $plural = 'media';
76 | break;
77 |
78 | case 'rendered-block':
79 | $key = 'rendered-blocks';
80 | $title = 'Rendered Block';
81 | $plural = 'Rendered Blocks';
82 | break;
83 |
84 | case 'settings':
85 | $key = 'settings';
86 | $title = 'Site Setting';
87 | $plural = 'Site Settings';
88 | break;
89 |
90 | case 'status':
91 | $plural = 'statuses';
92 | $key = 'post-statuses';
93 | break;
94 |
95 | case 'type':
96 | $key = 'post-types';
97 | break;
98 |
99 | case 'wp_block':
100 | $key = 'blocks';
101 | $title = 'Editor Block';
102 | $plural = 'Editor Blocks';
103 | break;
104 |
105 | case 'wp_block-revision':
106 | $key = 'block-revisions';
107 | $title = 'Block Revision';
108 | $plural = 'Block Revisions';
109 | break;
110 |
111 | default:
112 | // Fallback title cleaning logic, to remove kebab-casing, etcetera.
113 | $title = cleanup_name( $title );
114 | $plural = cleanup_name( $plural );
115 | }
116 |
117 | if ( ! isset( $objects[ $key ] ) ) {
118 | $objects[ $key ] = [
119 | 'name' => $title,
120 | 'plural' => $plural,
121 | 'routes' => [ $route_nicename => update_route( $route ) ],
122 | 'schema' => $route['schema'],
123 | ];
124 | } else {
125 | $objects[ $key ]['routes'][ $route_nicename ] = update_route( $route );
126 | }
127 | }
128 |
129 | return $objects;
130 | }
131 |
132 | function add_terms_schema() {
133 | $response = Requests::options( SITE_URL . '?rest_route=/wp/v2/terms/category' );
134 | $file = fopen( '_data/terms.json', 'w' );
135 | $parsed_data = json_decode( $response->body );
136 |
137 | # puts data
138 | fwrite( $file, json_encode( $parsed_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES ) );
139 | fclose( $file );
140 | }
141 |
142 | function twig() {
143 | static $twig;
144 | if ( ! empty( $twig ) ) {
145 | return $twig;
146 | }
147 |
148 | $loader = new Twig\Loader\FilesystemLoader( __DIR__ . '/templates' );
149 |
150 | $twig = new Twig\Environment( $loader, [
151 | 'cache' => false,
152 | ] );
153 | return $twig;
154 | }
155 |
156 | function generate_reference() {
157 | $template = twig()->load( 'endpoint.md' );
158 |
159 | $schemas = add_simple_schemas();
160 | $rendered = [];
161 | foreach ( $schemas as $key => $value ) {
162 | $rendered[ $key ] = $template->render( $value );
163 | file_put_contents( dirname( __DIR__ ) . '/reference/' . $key . '.md', $rendered[ $key ] );
164 | }
165 | }
166 |
167 | generate_reference();
168 |
--------------------------------------------------------------------------------
/reference/search-results.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Search Results
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a search result record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
Unique identifier for the object.
17 |
18 | JSON data type: integer or string
19 |
Read only
20 |
Context: view, embed
21 |
22 |
23 |
24 |
25 | title
26 |
27 |
28 |
The title for the object.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: view, embed
33 |
34 |
35 |
36 |
37 | url
38 |
39 |
40 |
URL to the object.
41 |
42 | JSON data type: string,
43 | Format: uri
44 |
45 |
Read only
46 |
Context: view, embed
47 |
48 |
49 |
50 |
51 | type
52 |
53 |
54 |
Object type.
55 |
56 | JSON data type: string
57 |
Read only
58 |
Context: view, embed
59 |
One of: post, term, post-format
60 |
61 |
62 |
63 |
64 | subtype
65 |
66 |
67 |
Object subtype.
68 |
69 | JSON data type: string
70 |
Read only
71 |
Context: view, embed
72 |
One of: post, page, category, post_tag
73 |
74 |
75 |
76 |
77 |
78 |
79 |
80 |
81 |
82 |
List Search Results
83 |
Query this endpoint to retrieve a collection of search results. The response you receive can be controlled and filtered using the URL query parameters below.
The schema defines all the fields that exist within a wp site health test record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | test
14 |
15 |
16 |
The name of the test being run.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context:
21 |
22 |
23 |
24 |
25 | label
26 |
27 |
28 |
A label describing the test.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context:
33 |
34 |
35 |
36 |
37 | status
38 |
39 |
40 |
The status of the test.
41 |
42 | JSON data type: string
43 |
Read only
44 |
Context:
45 |
One of: good, recommended, critical
46 |
47 |
48 |
49 |
50 | badge
51 |
52 |
53 |
The category this test is grouped in.
54 |
55 | JSON data type: object
56 |
Read only
57 |
Context:
58 |
59 |
60 |
61 |
62 | description
63 |
64 |
65 |
A more descriptive explanation of what the test looks for, and why it is important for the user.
66 |
67 | JSON data type: string
68 |
Read only
69 |
Context:
70 |
71 |
72 |
73 |
74 | actions
75 |
76 |
77 |
HTML containing an action to direct the user to where they can resolve the issue.
78 |
79 | JSON data type: string
80 |
Read only
81 |
Context:
82 |
83 |
84 |
85 |
86 |
87 |
88 |
89 |
90 |
91 |
Retrieve a Wp Site Health Test
92 |
93 |
Definition & Example Request
94 |
95 | GET /wp-site-health/v1/tests/background-updates
96 |
97 |
Query this endpoint to retrieve a specific wp site health test record.
The schema defines all the fields that exist within a status record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | name
14 |
15 |
16 |
The title for the status.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: embed, view, edit
21 |
22 |
23 |
24 |
25 | private
26 |
27 |
28 |
Whether posts with this status should be private.
29 |
30 | JSON data type: boolean
31 |
Read only
32 |
Context: edit
33 |
34 |
35 |
36 |
37 | protected
38 |
39 |
40 |
Whether posts with this status should be protected.
41 |
42 | JSON data type: boolean
43 |
Read only
44 |
Context: edit
45 |
46 |
47 |
48 |
49 | public
50 |
51 |
52 |
Whether posts of this status should be shown in the front end of the site.
53 |
54 | JSON data type: boolean
55 |
Read only
56 |
Context: view, edit
57 |
58 |
59 |
60 |
61 | queryable
62 |
63 |
64 |
Whether posts with this status should be publicly-queryable.
65 |
66 | JSON data type: boolean
67 |
Read only
68 |
Context: view, edit
69 |
70 |
71 |
72 |
73 | show_in_list
74 |
75 |
76 |
Whether to include posts in the edit listing for their post type.
77 |
78 | JSON data type: boolean
79 |
Read only
80 |
Context: edit
81 |
82 |
83 |
84 |
85 | slug
86 |
87 |
88 |
An alphanumeric identifier for the status.
89 |
90 | JSON data type: string
91 |
Read only
92 |
Context: embed, view, edit
93 |
94 |
95 |
96 |
97 | date_floating
98 |
99 |
100 |
Whether posts of this status may have floating published dates.
101 |
102 | JSON data type: boolean
103 |
Read only
104 |
Context: view, edit
105 |
106 |
107 |
108 |
109 |
110 |
111 |
112 |
113 |
114 |
Retrieve a Status
115 |
116 |
Definition & Example Request
117 |
118 | GET /wp/v2/statuses
119 |
120 |
Query this endpoint to retrieve a specific status record.
Scope under which the request is made; determines fields present in response.
172 |
173 | Default: view
174 |
175 |
One of: view, embed, edit
176 |
177 |
178 |
179 |
180 |
181 |
182 |
183 |
--------------------------------------------------------------------------------
/reference.md:
--------------------------------------------------------------------------------
1 | # Reference
2 |
3 | The WordPress REST API is organized around [REST](http://en.wikipedia.org/wiki/Representational_state_transfer), and is designed to have predictable, resource-oriented URLs and to use HTTP response codes to indicate API errors. The API uses built-in HTTP features, like HTTP authentication and HTTP verbs, which can be understood by off-the-shelf HTTP clients, and supports cross-origin resource sharing to allow you to interact securely with the API from a client-side web application.
4 |
5 | The REST API uses JSON exclusively as the request and response format, including error responses. While the REST API does not completely conform to the [HAL standard](http://stateless.co/hal_specification.html), it does implement HAL's `._links` and `._embedded` properties for linking API resources, and is fully discoverable via hyperlinks in the responses.
6 |
7 | The REST API provides public data accessible to any client anonymously, as well as private data only available after [authentication](https://developer.wordpress.org/rest-api/authentication/). Once authenticated the REST API supports most content management actions, allowing you to build alternative dashboards for a site, enhance your plugins with more responsive management tools, or build complex single-page applications.
8 |
9 | This API reference provides information on the specific endpoints available through the API, their parameters, and their response data format.
10 |
11 | ## REST API Developer Endpoint Reference
12 |
13 |
103 |
104 | ## A Distributed API
105 |
106 | Unlike many other REST APIs, the WordPress REST API is distributed and available individually on each site that supports it. This means there is no singular API root or base to contact; instead, we have [a discovery process](https://developer.wordpress.org/rest-api/discovery/) that allows interacting with sites without prior contact. The API also exposes self-documentation at the index endpoint, or via an `OPTIONS` request to any endpoint, allowing human- or machine-discovery of endpoint capabilities.
107 |
--------------------------------------------------------------------------------
/reference/block-patterns.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Block Patterns
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a block pattern record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | name
14 |
15 |
16 |
The pattern name.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: view, edit, embed
21 |
22 |
23 |
24 |
25 | title
26 |
27 |
28 |
The pattern title, in human readable format.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: view, edit, embed
33 |
34 |
35 |
36 |
37 | content
38 |
39 |
40 |
The pattern content.
41 |
42 | JSON data type: string
43 |
Read only
44 |
Context: view, edit, embed
45 |
46 |
47 |
48 |
49 | description
50 |
51 |
52 |
The pattern detailed description.
53 |
54 | JSON data type: string
55 |
Read only
56 |
Context: view, edit, embed
57 |
58 |
59 |
60 |
61 | viewport_width
62 |
63 |
64 |
The pattern viewport width for inserter preview.
65 |
66 | JSON data type: number
67 |
Read only
68 |
Context: view, edit, embed
69 |
70 |
71 |
72 |
73 | inserter
74 |
75 |
76 |
Determines whether the pattern is visible in inserter.
77 |
78 | JSON data type: boolean
79 |
Read only
80 |
Context: view, edit, embed
81 |
82 |
83 |
84 |
85 | categories
86 |
87 |
88 |
The pattern category slugs.
89 |
90 | JSON data type: array
91 |
Read only
92 |
Context: view, edit, embed
93 |
94 |
95 |
96 |
97 | keywords
98 |
99 |
100 |
The pattern keywords.
101 |
102 | JSON data type: array
103 |
Read only
104 |
Context: view, edit, embed
105 |
106 |
107 |
108 |
109 | block_types
110 |
111 |
112 |
Block types that the pattern is intended to be used with.
113 |
114 | JSON data type: array
115 |
Read only
116 |
Context: view, edit, embed
117 |
118 |
119 |
120 |
121 | post_types
122 |
123 |
124 |
An array of post types that the pattern is restricted to be used with.
125 |
126 | JSON data type: array
127 |
Read only
128 |
Context: view, edit, embed
129 |
130 |
131 |
132 |
133 | template_types
134 |
135 |
136 |
An array of template types where the pattern fits.
137 |
138 | JSON data type: array
139 |
Read only
140 |
Context: view, edit, embed
141 |
142 |
143 |
144 |
145 | source
146 |
147 |
148 |
Where the pattern comes from e.g. core
149 |
150 | JSON data type: string
151 |
Read only
152 |
Context: view, edit, embed
153 |
One of: core, plugin, theme, pattern-directory/core, pattern-directory/theme, pattern-directory/featured
154 |
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
Retrieve a Block Pattern
164 |
165 |
Definition & Example Request
166 |
167 | GET /wp/v2/block-patterns/patterns
168 |
169 |
Query this endpoint to retrieve a specific block pattern record.
The schema defines all the fields that exist within a global_styles revision record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | author
14 |
15 |
16 |
The ID for the author of the revision.
17 |
18 | JSON data type: integer
19 |
Context: view, edit, embed
20 |
21 |
22 |
23 |
24 | date
25 |
26 |
27 |
The date the revision was published, in the site's timezone.
Query this endpoint to retrieve a collection of global_styles revisions. The response you receive can be controlled and filtered using the URL query parameters below.
127 |
128 |
Definition
129 |
130 | GET /wp/v2/global-styles/<parent>/revisions
131 |
132 |
Scope under which the request is made; determines fields present in response.
153 |
154 | Default: view
155 |
156 |
One of: view, embed, edit
157 |
158 |
159 |
160 |
161 | page
162 |
163 |
164 |
Current page of the collection.
165 |
166 | Default: 1
167 |
168 |
169 |
170 |
171 |
172 | per_page
173 |
174 |
175 |
Maximum number of items to be returned in result set.
176 |
177 |
178 |
179 |
180 | offset
181 |
182 |
183 |
Offset the result set by a specific number of items.
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 |
--------------------------------------------------------------------------------
/frequently-asked-questions.md:
--------------------------------------------------------------------------------
1 | # Frequently Asked Questions
2 |
3 | This page provides solutions to some common questions and problems that may arise while using the API. If your question is not explained here it may have been answered in the [WordPress support forums](https://wordpress.org/support/topic-tag/rest-api).
4 |
5 |
6 | ## Can I disable the REST API?
7 |
8 | You should not disable the REST API; doing so will break WordPress Admin functionality that depends on the API being active. However, you may use a filter to require that API consumers be authenticated, which effectively prevents anonymous external access. See below for more information.
9 |
10 |
11 | ## Require Authentication for All Requests
12 |
13 | You can require authentication for all REST API requests by adding an `is_user_logged_in` check to the [`rest_authentication_errors`](https://developer.wordpress.org/reference/hooks/rest_authentication_errors/) filter.
14 |
15 | Note: The incoming callback parameter can be either `null`, a `WP_Error`, or a boolean. The type of the parameter indicates the state of authentication:
16 |
17 | * `null`: no authentication check has yet been performed, and the hook callback may apply custom authentication logic.
18 | * boolean: indicates a previous authentication method check was performed. Boolean `true` indicates the request was successfully authenticated, and boolean `false` indicates authentication failed.
19 | * `WP_Error`: Some kind of error was encountered.
20 |
21 | ```php
22 | add_filter( 'rest_authentication_errors', function( $result ) {
23 | // If a previous authentication check was applied,
24 | // pass that result along without modification.
25 | if ( true === $result || is_wp_error( $result ) ) {
26 | return $result;
27 | }
28 |
29 | // No authentication has been performed yet.
30 | // Return an error if user is not logged in.
31 | if ( ! is_user_logged_in() ) {
32 | return new WP_Error(
33 | 'rest_not_logged_in',
34 | __( 'You are not currently logged in.' ),
35 | array( 'status' => 401 )
36 | );
37 | }
38 |
39 | // Our custom authentication check should have no effect
40 | // on logged-in requests
41 | return $result;
42 | });
43 | ```
44 |
45 |
46 | ## Can I make API requests from PHP within a plugin?
47 |
48 | Yes, you can! Use [rest_do_request](https://developer.wordpress.org/reference/functions/rest_do_request/) to make API requests internally within other WordPress code:
49 |
50 | ```php
51 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
52 | // Set one or more request query parameters
53 | $request->set_param( 'per_page', 20 );
54 | $response = rest_do_request( $request );
55 | ```
56 |
57 | ## How do I use the _embed parameter on internal requests?
58 |
59 | Setting the `_embed` param on the request object won't work.
60 |
61 | ```php
62 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
63 | $request->set_param( '_embed', 1 );
64 | $response = rest_do_request( $request );
65 | ```
66 |
67 | Instead, manually call the [`WP_REST_Server::response_to_data`](https://developer.wordpress.org/reference/classes/wp_rest_server/) function.
68 |
69 | ```php
70 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' );
71 | $response = rest_do_request( $request );
72 | $data = rest_get_server()->response_to_data( $response, true );
73 | var_dump( $data['_embedded'] );
74 | ```
75 |
76 | ## What happened to the `?filter=` query parameter?
77 |
78 | When the REST API was merged into WordPress core the `?filter` query parameter was removed to prevent future compatibility and maintenance issues. The ability to pass arbitrary WP_Query arguments to the API using a `?filter` query parameter was necessary at the genesis of the REST API project, but most API response filtering functionality has been superseded by more robust query parameters like `?categories=`, `?slug=` and `?per_page=`.
79 |
80 | First-party query parameters should be used whenever possible. However, the [rest-filter](https://github.com/wp-api/rest-filter) plugin restores the ability to pass arbitrary `?filter` values in API request if needed.
81 |
82 |
83 | ## Query parameters are not working
84 |
85 | If you find that query parameters such as `?page=2` or `?_embed` are not having any effect, your server may not be properly configured to detect them. If you are using Nginx to serve your website, look for a `try_files` line in your site configuration. If it looks like this:
86 |
87 | ```
88 | try_files $uri $uri/ /index.php$args;
89 | ```
90 |
91 | change it to this:
92 |
93 | ```
94 | try_files $uri $uri/ /index.php$is_args$args;
95 | ```
96 |
97 | Adding `$is_args` (which will print a ? character if query arguments are found) will allow WordPress to properly receive and interpret the query parameters.
98 |
99 |
100 | ## Why is Authentication not working?
101 |
102 | If you're finding that you are sending Authentication headers but the request is not being accepted, and you are using a CGI environment, your webserver may be stripping the headers. Please try adding the appropriate configuration below to remedy this.
103 |
104 | ### Apache
105 | Add the following to a configuration file or .htaccess:
106 | ```
107 |
108 | SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
109 |
110 | ```
111 |
112 | ### Nginx
113 | Add the following to your server configurations fastcgi section:
114 | ```
115 | fastcgi_pass_header Authorization;
116 | ```
117 |
118 | ## Why is the REST API not verifying the incoming Origin header? Does this expose my site to CSRF attacks?
119 |
120 | Cross-Origin Resource Sharing (CORS) is a mechanism which allows a website to control which Origins (originating external sites) are allowed to access your site's data. CORS prevents against a particular type of attack known as Cross-Site Request Forgery, or CSRF. However, WordPress has an existing CSRF protection mechanism which uses [nonces](https://developer.wordpress.org/plugins/security/nonces/). Tightening CORS restrictions would prevent some authentication methods, so the WordPress REST API uses nonces for CSRF protection instead of CORS.
121 |
122 | Because the WordPress REST API does not verify the Origin header of incoming requests, public REST API endpoints may therefore be accessed from any site.
123 |
124 | This is an [intentional design decision](https://core.trac.wordpress.org/changeset/40600), but if you wish to prevent your site from being accessed from unknown origins you may unhook the default [`rest_send_cors_headers` function](https://developer.wordpress.org/reference/functions/rest_send_cors_headers/) from the [`rest_pre_serve_request` filter hook](https://developer.wordpress.org/reference/hooks/rest_pre_serve_request/), then hook in your own function to that same filter to specify stricter CORS headers.
125 |
--------------------------------------------------------------------------------
/reference/block-directory-items.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Block Directory Items
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a block directory item record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | name
14 |
15 |
16 |
The block name, in namespace/block-name format.
17 |
18 | JSON data type: string
19 |
Context: view
20 |
21 |
22 |
23 |
24 | title
25 |
26 |
27 |
The block title, in human readable format.
28 |
29 | JSON data type: string
30 |
Context: view
31 |
32 |
33 |
34 |
35 | description
36 |
37 |
38 |
A short description of the block, in human readable format.
39 |
40 | JSON data type: string
41 |
Context: view
42 |
43 |
44 |
45 |
46 | id
47 |
48 |
49 |
The block slug.
50 |
51 | JSON data type: string
52 |
Context: view
53 |
54 |
55 |
56 |
57 | rating
58 |
59 |
60 |
The star rating of the block.
61 |
62 | JSON data type: number
63 |
Context: view
64 |
65 |
66 |
67 |
68 | rating_count
69 |
70 |
71 |
The number of ratings.
72 |
73 | JSON data type: integer
74 |
Context: view
75 |
76 |
77 |
78 |
79 | active_installs
80 |
81 |
82 |
The number sites that have activated this block.
83 |
84 | JSON data type: integer
85 |
Context: view
86 |
87 |
88 |
89 |
90 | author_block_rating
91 |
92 |
93 |
The average rating of blocks published by the same author.
94 |
95 | JSON data type: number
96 |
Context: view
97 |
98 |
99 |
100 |
101 | author_block_count
102 |
103 |
104 |
The number of blocks published by the same author.
105 |
106 | JSON data type: integer
107 |
Context: view
108 |
109 |
110 |
111 |
112 | author
113 |
114 |
115 |
The WordPress.org username of the block author.
116 |
117 | JSON data type: string
118 |
Context: view
119 |
120 |
121 |
122 |
123 | icon
124 |
125 |
126 |
The block icon.
127 |
128 | JSON data type: string,
129 | Format: uri
130 |
The date when the block was last updated, in fuzzy human readable format.
153 |
154 | JSON data type: string
155 |
Context: view
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
List Block Directory Items
166 |
Query this endpoint to retrieve a collection of block directory items. The response you receive can be controlled and filtered using the URL query parameters below.
167 |
168 |
Definition
169 |
170 | GET /wp/v2/block-directory/search
171 |
172 |
The schema defines all the fields that exist within a pattern directory item record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
The pattern ID.
17 |
18 | JSON data type: integer
19 |
Context: view, edit, embed
20 |
21 |
22 |
23 |
24 | title
25 |
26 |
27 |
The pattern title, in human readable format.
28 |
29 | JSON data type: string
30 |
Context: view, edit, embed
31 |
32 |
33 |
34 |
35 | content
36 |
37 |
38 |
The pattern content.
39 |
40 | JSON data type: string
41 |
Context: view, edit, embed
42 |
43 |
44 |
45 |
46 | categories
47 |
48 |
49 |
The pattern's category slugs.
50 |
51 | JSON data type: array
52 |
Context: view, edit, embed
53 |
54 |
55 |
56 |
57 | keywords
58 |
59 |
60 |
The pattern's keywords.
61 |
62 | JSON data type: array
63 |
Context: view, edit, embed
64 |
65 |
66 |
67 |
68 | description
69 |
70 |
71 |
A description of the pattern.
72 |
73 | JSON data type: string
74 |
Context: view, edit, embed
75 |
76 |
77 |
78 |
79 | viewport_width
80 |
81 |
82 |
The preferred width of the viewport when previewing a pattern, in pixels.
83 |
84 | JSON data type: integer
85 |
Context: view, edit, embed
86 |
87 |
88 |
89 |
90 | block_types
91 |
92 |
93 |
The block types which can use this pattern.
94 |
95 | JSON data type: array
96 |
Context: view, embed
97 |
98 |
99 |
100 |
101 |
102 |
103 |
104 |
105 |
106 |
List Pattern Directory Items
107 |
Query this endpoint to retrieve a collection of pattern directory items. The response you receive can be controlled and filtered using the URL query parameters below.
108 |
109 |
Definition
110 |
111 | GET /wp/v2/pattern-directory/patterns
112 |
113 |
The schema defines all the fields that exist within a taxonomy record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | capabilities
14 |
15 |
16 |
All capabilities used by the taxonomy.
17 |
18 | JSON data type: object
19 |
Read only
20 |
Context: edit
21 |
22 |
23 |
24 |
25 | description
26 |
27 |
28 |
A human-readable description of the taxonomy.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: view, edit
33 |
34 |
35 |
36 |
37 | hierarchical
38 |
39 |
40 |
Whether or not the taxonomy should have children.
41 |
42 | JSON data type: boolean
43 |
Read only
44 |
Context: view, edit
45 |
46 |
47 |
48 |
49 | labels
50 |
51 |
52 |
Human-readable labels for the taxonomy for various contexts.
53 |
54 | JSON data type: object
55 |
Read only
56 |
Context: edit
57 |
58 |
59 |
60 |
61 | name
62 |
63 |
64 |
The title for the taxonomy.
65 |
66 | JSON data type: string
67 |
Read only
68 |
Context: view, edit, embed
69 |
70 |
71 |
72 |
73 | slug
74 |
75 |
76 |
An alphanumeric identifier for the taxonomy.
77 |
78 | JSON data type: string
79 |
Read only
80 |
Context: view, edit, embed
81 |
82 |
83 |
84 |
85 | show_cloud
86 |
87 |
88 |
Whether or not the term cloud should be displayed.
89 |
90 | JSON data type: boolean
91 |
Read only
92 |
Context: edit
93 |
94 |
95 |
96 |
97 | types
98 |
99 |
100 |
Types associated with the taxonomy.
101 |
102 | JSON data type: array
103 |
Read only
104 |
Context: view, edit
105 |
106 |
107 |
108 |
109 | rest_base
110 |
111 |
112 |
REST base route for the taxonomy.
113 |
114 | JSON data type: string
115 |
Read only
116 |
Context: view, edit, embed
117 |
118 |
119 |
120 |
121 | rest_namespace
122 |
123 |
124 |
REST namespace route for the taxonomy.
125 |
126 | JSON data type: string
127 |
Read only
128 |
Context: view, edit, embed
129 |
130 |
131 |
132 |
133 | visibility
134 |
135 |
136 |
The visibility settings for the taxonomy.
137 |
138 | JSON data type: object
139 |
Read only
140 |
Context: edit
141 |
142 |
143 |
144 |
145 |
146 |
147 |
148 |
149 |
150 |
Retrieve a Taxonomy
151 |
152 |
Definition & Example Request
153 |
154 | GET /wp/v2/taxonomies
155 |
156 |
Query this endpoint to retrieve a specific taxonomy record.
The schema defines all the fields that exist within a sidebar record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
ID of sidebar.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: embed, view, edit
21 |
22 |
23 |
24 |
25 | name
26 |
27 |
28 |
Unique name identifying the sidebar.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: embed, view, edit
33 |
34 |
35 |
36 |
37 | description
38 |
39 |
40 |
Description of sidebar.
41 |
42 | JSON data type: string
43 |
Read only
44 |
Context: embed, view, edit
45 |
46 |
47 |
48 |
49 | class
50 |
51 |
52 |
Extra CSS class to assign to the sidebar in the Widgets interface.
53 |
54 | JSON data type: string
55 |
Read only
56 |
Context: embed, view, edit
57 |
58 |
59 |
60 |
61 | before_widget
62 |
63 |
64 |
HTML content to prepend to each widget's HTML output when assigned to this sidebar. Default is an opening list item element.
65 |
66 | JSON data type: string
67 |
Read only
68 |
Context: embed, view, edit
69 |
70 |
71 |
72 |
73 | after_widget
74 |
75 |
76 |
HTML content to append to each widget's HTML output when assigned to this sidebar. Default is a closing list item element.
77 |
78 | JSON data type: string
79 |
Read only
80 |
Context: embed, view, edit
81 |
82 |
83 |
84 |
85 | before_title
86 |
87 |
88 |
HTML content to prepend to the sidebar title when displayed. Default is an opening h2 element.
89 |
90 | JSON data type: string
91 |
Read only
92 |
Context: embed, view, edit
93 |
94 |
95 |
96 |
97 | after_title
98 |
99 |
100 |
HTML content to append to the sidebar title when displayed. Default is a closing h2 element.
101 |
102 | JSON data type: string
103 |
Read only
104 |
Context: embed, view, edit
105 |
106 |
107 |
108 |
109 | status
110 |
111 |
112 |
Status of sidebar.
113 |
114 | JSON data type: string
115 |
Read only
116 |
Context: embed, view, edit
117 |
One of: active, inactive
118 |
119 |
120 |
121 |
122 | widgets
123 |
124 |
125 |
Nested widgets.
126 |
127 | JSON data type: array
128 |
Context: embed, view, edit
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
137 |
138 |
Retrieve a Sidebar
139 |
140 |
Definition & Example Request
141 |
142 | GET /wp/v2/sidebars
143 |
144 |
Query this endpoint to retrieve a specific sidebar record.
233 |
--------------------------------------------------------------------------------
/using-the-rest-api/global-parameters.md:
--------------------------------------------------------------------------------
1 | # Global Parameters
2 |
3 | The API includes a number of global parameters (also called "meta-parameters") which control how the API handles the request/response handling. These operate at a layer above the actual resources themselves, and are available on all resources.
4 |
5 | ## `_fields`
6 |
7 | A REST resource like a Post contains a large quantity of data: basic information such as content, title, and author ID, but also [registered metadata and fields](https://developer.wordpress.org/rest-api/extending-the-rest-api/modifying-responses/), media information, and links to other resources. Your application may not need all of this information on every request.
8 |
9 | To instruct WordPress to return only a subset of the fields in a response, you may use the `_fields` query parameter. If for example you are building an archive view and only need the ID, title, permalink, author and excerpt for a collection of posts, you can restrict the response to only those properties with this fields query:
10 |
11 | ```
12 | /wp/v2/posts?_fields=author,id,excerpt,title,link
13 | ```
14 |
15 | You may alternatively provide that same list using query parameter array syntax instead of a comma-separated list:
16 |
17 | ```
18 | /wp/v2/posts?_fields[]=author&_fields[]=id&_fields[]=excerpt&_fields[]=title&_fields[]=link
19 | ```
20 |
21 | When `_fields` is provided then WordPress will skip unneeded fields when generating your response object, avoiding potentially expensive internal computation or queries for data you don't need. This also means the JSON object returned from the REST API will be smaller, requiring less time to download and less time to parse on your client device.
22 |
23 | Carefully design your queries to pull in only the needed properties from each resource to make your application faster to use and more efficient to run.
24 |
25 | As of WordPress 5.3 the `_fields` parameter supports nested properties. This can be useful if you have registered many meta keys, permitting you to request the value for only one of the registered meta properties:
26 |
27 | ```
28 | ?_fields=meta.one-of-many-keys
29 | ```
30 |
31 | Only the meta value with the key `one-of-many-keys` will be returned, and others will be excluded.
32 |
33 | You can also request specific deeply-nested properties within a complex meta object:
34 |
35 | ```
36 | ?_fields=meta.key_name.nested_prop.deeply_nested_prop,meta.key_name.other_nested_prop
37 | ```
38 |
39 |
40 | ## `_embed`
41 |
42 | Most resources include links to related resources. For example, a post can link to the parent post, or to comments on the post. To reduce the number of HTTP requests required, clients may wish to fetch a resource as well as the linked resources. The `_embed` parameter indicates to the server that the response should include these embedded resources.
43 |
44 | Embed mode is enabled if the `_embed` parameter is passed in the query string (GET parameter). This parameter does not require a value (i.e. `?_embed` is valid), however can be passed "1" as a value if required by a client library.
45 |
46 | As of WordPress 5.4, the resources to embed can be limited by passing a list of link relation names to the `_embed` parameter. For example, `/wp/v2/posts?_embed=author,wp:term` will only embed the post's author and the lists of terms associated with the post.
47 |
48 | Resources in embed mode will contain an additional `_embedded` key next to the `_links` key containing the linked resources. Only links with the `embeddable` parameter set to `true` will be embedded.
49 |
50 | In order to use `_embed` together with `_fields`, add `_embedded` as well as `_links` to the fields, for instance, `/wp-json/wp/v2/posts/_embed=author,wp:term&_fields=title,author,_links,_embedded`.
51 |
52 | For more about linking and embedding, see the [Linking and Embedding](https://developer.wordpress.org/rest-api/linking-and-embedding/) page.
53 |
54 | ## `_method` (or `X-HTTP-Method-Override` header)
55 |
56 | Some servers and clients cannot correctly process some HTTP methods that the API makes use of. For example, all deletion requests on resources use the `DELETE` method, but some clients do not provide the ability to send this method.
57 |
58 | To ensure compatibility with these servers and clients, the API supports a method override. This can be passed either via a `_method` parameter or the `X-HTTP-Method-Override` header, with the value set to the HTTP method to use.
59 |
60 | [alert]
61 | Clients should only ever send a method override parameter or header with POST requests. Using the method override with GET requests may cause the request to be incorrectly cached.
62 | [/alert]
63 |
64 | A `POST` to `/wp-json/wp/v2/posts/42?_method=DELETE` would be translated to a `DELETE` to the `wp/v2/posts/42` route.
65 |
66 | Similarly, the following POST request would become a DELETE:
67 |
68 | ```
69 | POST /wp-json/wp/v2/posts/42 HTTP/1.1
70 | Host: example.com
71 | X-HTTP-Method-Override: DELETE
72 | ```
73 |
74 | ## `_envelope`
75 |
76 | Similarly to `_method`, some servers, clients, and proxies do not support accessing the full response data. The API supports passing an `_envelope` parameter, which sends all response data in the body, including headers and status code.
77 |
78 | Envelope mode is enabled if the `_envelope` parameter is passed in the query string (GET parameter). This parameter does not require a value (i.e. `?_envelope` is valid), but can be passed "1" as a value if required by a client library.
79 |
80 | [info]
81 | For future compatibility, other values should not be passed.
82 | [/info]
83 |
84 | Enveloped responses include a "fake" HTTP 200 response code with no additional headers (apart from Content-Type) that should ensure the response correctly passes through intermediaries.
85 |
86 | For example, given the following response to a `GET` to `wp/v2/users/me`:
87 |
88 | ```
89 | HTTP/1.1 302 Found
90 | Location: http://example.com/wp-json/wp/v2/users/42
91 |
92 | {
93 | "id": 42,
94 | ...
95 | }
96 | ```
97 |
98 | The equivalent enveloped response (with a `GET` to `wp/v2/users/me?_envelope`) would be:
99 |
100 | ```
101 | HTTP/1.1 200 OK
102 |
103 | {
104 | "status": 302,
105 | "headers": {
106 | "Location": "http://example.com/wp-json/wp/v2/users/42"
107 | },
108 | "body": {
109 | "id": 42
110 | }
111 | }
112 | ```
113 |
114 | ## `_jsonp`
115 |
116 | The API natively supports [JSONP](https://en.wikipedia.org/wiki/JSONP) responses to allow cross-domain requests for legacy browsers and clients. This parameter takes a JavaScript callback function which will be prepended to the data. This URL can then be loaded via a `
139 |
140 | ```
141 |
--------------------------------------------------------------------------------
/reference/themes.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Themes
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a theme record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | stylesheet
14 |
15 |
16 |
The theme's stylesheet. This uniquely identifies the theme.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context:
21 |
22 |
23 |
24 |
25 | template
26 |
27 |
28 |
The theme's template. If this is a child theme, this refers to the parent theme, otherwise this is the same as the theme's stylesheet.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context:
33 |
34 |
35 |
36 |
37 | author
38 |
39 |
40 |
The theme author.
41 |
42 | JSON data type: object
43 |
Read only
44 |
Context:
45 |
46 |
47 |
48 |
49 | author_uri
50 |
51 |
52 |
The website of the theme author.
53 |
54 | JSON data type: object
55 |
Read only
56 |
Context:
57 |
58 |
59 |
60 |
61 | description
62 |
63 |
64 |
A description of the theme.
65 |
66 | JSON data type: object
67 |
Read only
68 |
Context:
69 |
70 |
71 |
72 |
73 | is_block_theme
74 |
75 |
76 |
Whether the theme is a block-based theme.
77 |
78 | JSON data type: boolean
79 |
Read only
80 |
Context:
81 |
82 |
83 |
84 |
85 | name
86 |
87 |
88 |
The name of the theme.
89 |
90 | JSON data type: object
91 |
Read only
92 |
Context:
93 |
94 |
95 |
96 |
97 | requires_php
98 |
99 |
100 |
The minimum PHP version required for the theme to work.
101 |
102 | JSON data type: string
103 |
Read only
104 |
Context:
105 |
106 |
107 |
108 |
109 | requires_wp
110 |
111 |
112 |
The minimum WordPress version required for the theme to work.
113 |
114 | JSON data type: string
115 |
Read only
116 |
Context:
117 |
118 |
119 |
120 |
121 | screenshot
122 |
123 |
124 |
The theme's screenshot URL.
125 |
126 | JSON data type: string,
127 | Format: uri
128 |
129 |
Read only
130 |
Context:
131 |
132 |
133 |
134 |
135 | tags
136 |
137 |
138 |
Tags indicating styles and features of the theme.
139 |
140 | JSON data type: object
141 |
Read only
142 |
Context:
143 |
144 |
145 |
146 |
147 | textdomain
148 |
149 |
150 |
The theme's text domain.
151 |
152 | JSON data type: string
153 |
Read only
154 |
Context:
155 |
156 |
157 |
158 |
159 | theme_supports
160 |
161 |
162 |
Features supported by this theme.
163 |
164 | JSON data type: object
165 |
Read only
166 |
Context:
167 |
168 |
169 |
170 |
171 | theme_uri
172 |
173 |
174 |
The URI of the theme's webpage.
175 |
176 | JSON data type: object
177 |
Read only
178 |
Context:
179 |
180 |
181 |
182 |
183 | version
184 |
185 |
186 |
The theme's current version.
187 |
188 | JSON data type: string
189 |
Read only
190 |
Context:
191 |
192 |
193 |
194 |
195 | status
196 |
197 |
198 |
A named status for the theme.
199 |
200 | JSON data type: string
201 |
Context:
202 |
One of: inactive, active
203 |
204 |
205 |
206 |
207 |
208 |
209 |
210 |
211 |
212 |
Retrieve a Theme
213 |
214 |
Definition & Example Request
215 |
216 | GET /wp/v2/themes
217 |
218 |
Query this endpoint to retrieve a specific theme record.
The theme's stylesheet. This uniquely identifies the theme.
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
--------------------------------------------------------------------------------
/using-the-rest-api/discovery.md:
--------------------------------------------------------------------------------
1 | # Discovery
2 |
3 | When your client talks to an unknown site, you'll need to discover what the site is capable of and how the site is configured. There are a couple of steps for this, depending on what you need to discover.
4 |
5 |
6 | ## Discovering the API
7 |
8 | The first step of connecting to a site is finding out whether the site has the API enabled. Typically, you'll be working with URLs from user input, so the site you're accessing could be anything. The discovery step lets you verify the API is available, as well as indicating how to access it.
9 |
10 |
11 | ### Link Header
12 |
13 | The preferred way to handle discovery is to send a HEAD request to the supplied address. The REST API automatically adds a Link header to all front-end pages that looks like the following:
14 |
15 | Link: ; rel="https://api.w.org/"
16 |
17 | This URL points to the root route (`/`) of the API, which is then used for further discovery steps.
18 |
19 | For sites without "pretty permalinks" enabled, `/wp-json/` isn't automatically handled by WordPress. This means that normal/default WordPress permalinks will be used instead. These headers look more like this:
20 |
21 | Link: ; rel="https://api.w.org/"
22 |
23 | Clients should keep this variation in mind and ensure that both routes can be handled seamlessly.
24 |
25 | This auto-discovery can be applied to any URL served by a WordPress installation, so no pre-processing on user input needs to be added. Since this is a HEAD request, the request should be safe to send blindly to servers without worrying about causing side-effects.
26 |
27 |
28 | ### Element
29 |
30 | For clients with a HTML parser, or running in the browser, the equivalent of the Link header is included in the `` of front-end pages through a `` element:
31 |
32 |
33 |
34 | In-browser Javascript can access this via the DOM:
35 |
36 | ```js
37 | // jQuery method
38 | var $link = jQuery( 'link[rel="https://api.w.org/"]' );
39 | var api_root = $link.attr( 'href' );
40 |
41 | // Native method
42 | var links = document.getElementsByTagName( 'link' );
43 | var link = Array.prototype.filter.call( links, function ( item ) {
44 | return ( item.rel === 'https://api.w.org/' );
45 | } );
46 | var api_root = link[0].href;
47 | ```
48 |
49 | For in-browser clients, or clients without access to HTTP headers, this may be a more usable way of discovering the API. This is similar to Atom/RSS feed discovery, so existing code for that purpose may also be automatically adapted instead.
50 |
51 |
52 | ### RSD (Really Simple Discovery)
53 |
54 | For clients with support for XML-RPC discovery, the [RSD method](http://cyber.law.harvard.edu/blogs/gems/tech/rsd.html) may be more applicable. This is an XML-based discovery format typically used for XML-RPC. RSD has two steps. The first step is to find the RSD endpoint, supplied as a `` element:
55 |
56 |
57 |
58 | The second step is to fetch the RSD document and parse the available endpoints. This involves using an XML parser on a document like the following:
59 |
60 | ```xml
61 |
62 |
63 |
64 | WordPress
65 | http://wordpress.org/
66 | http://example.com/
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 | ```
75 |
76 | The REST API always has a `name` attribute with the value equal to `WP-API`.
77 |
78 | RSD is the least-preferred method of autodiscovery for a couple of reasons. The first step of RSD-based discovery involves parsing the HTML to first find the RSD document itself, which is equivalent to the `` Element autodiscovery. It then involves another step to parse the RSD document, which requires a full XML parser.
79 |
80 | Where possible, we suggest avoiding RSD-based discovery due to the complexity, but existing XML-RPC clients may prefer to use this method if they already have an RSD parser enabled. For XML-RPC clients which wish to use the REST API as a progressive enhancement to the codebase, this avoids needing to support different forms of discovery.
81 |
82 |
83 | ## Authentication Discovery
84 |
85 | Discovery is also available for authentication methods available via the API. The API root's response is an object describing the API, which includes an `authentication` key:
86 |
87 | ```
88 | {
89 | "name": "Example WordPress Site",
90 | "description": "YOLO",
91 | "routes": { ... },
92 | "authentication": {
93 | "oauth1": {
94 | "request": "http://example.com/oauth/request",
95 | "authorize": "http://example.com/oauth/authorize",
96 | "access": "http://example.com/oauth/access",
97 | "version": "0.1"
98 | }
99 | }
100 | }
101 | ```
102 |
103 | The `authentication` value is a map (associative array) of authentication method ID to authentication options. The options available here are specific to the authentication method itself. See the [authentication documentation](/rest-api/authentication/) for the options for specific authentication methods.
104 |
105 |
106 | ## Extension Discovery
107 |
108 | Once you've discovered the API, the next step is check what the API supports. The index of the API exposes the `namespaces` item, which contains the extensions to the API that are supported.
109 |
110 | For WordPress sites using versions 4.4 through 4.6, only the base API infrastructure is available, not the full API with endpoints. This also includes the oEmbed endpoints:
111 |
112 | ```
113 | {
114 | "name": "Example WordPress Site",
115 | "namespaces": [
116 | "oembed/1.0/"
117 | ]
118 | }
119 | ```
120 |
121 | Sites with the full API available (i.e. with WordPress 4.7+ or the REST API plugin installed) will have the `wp/v2` item in `namespaces` as well:
122 |
123 | ```
124 | {
125 | "name": "Example WordPress Site",
126 | "namespaces": [
127 | "wp/v2",
128 | "oembed/1.0/"
129 | ]
130 | }
131 | ```
132 |
133 | Before attempting to use any of the core endpoints, you should be sure to check that the API is supported by checking for `wp/v2` support. WordPress 4.4 enabled the API infrastructure for all sites, but did **not** include the core endpoints under `wp/v2`. Core endpoints were added in WordPress 4.7.
134 |
135 | This same mechanism can be used for detecting support for any plugins that support the REST API. For example, take a plugin which registers the following route:
136 |
137 | ```php
138 | ` element](#element).
158 |
159 | For instance, in the `` section of this page, the following `` appears.
160 |
161 | ```html
162 |
163 | ```
164 |
165 | Links are added for post, pages, and other custom post types, as well as terms and author pages. Links are not currently output for post archives or search results.
166 |
--------------------------------------------------------------------------------
/reference/post-types.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Types
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a type record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | capabilities
14 |
15 |
16 |
All capabilities used by the post type.
17 |
18 | JSON data type: object
19 |
Read only
20 |
Context: edit
21 |
22 |
23 |
24 |
25 | description
26 |
27 |
28 |
A human-readable description of the post type.
29 |
30 | JSON data type: string
31 |
Read only
32 |
Context: view, edit
33 |
34 |
35 |
36 |
37 | hierarchical
38 |
39 |
40 |
Whether or not the post type should have children.
41 |
42 | JSON data type: boolean
43 |
Read only
44 |
Context: view, edit
45 |
46 |
47 |
48 |
49 | viewable
50 |
51 |
52 |
Whether or not the post type can be viewed.
53 |
54 | JSON data type: boolean
55 |
Read only
56 |
Context: edit
57 |
58 |
59 |
60 |
61 | labels
62 |
63 |
64 |
Human-readable labels for the post type for various contexts.
65 |
66 | JSON data type: object
67 |
Read only
68 |
Context: edit
69 |
70 |
71 |
72 |
73 | name
74 |
75 |
76 |
The title for the post type.
77 |
78 | JSON data type: string
79 |
Read only
80 |
Context: view, edit, embed
81 |
82 |
83 |
84 |
85 | slug
86 |
87 |
88 |
An alphanumeric identifier for the post type.
89 |
90 | JSON data type: string
91 |
Read only
92 |
Context: view, edit, embed
93 |
94 |
95 |
96 |
97 | supports
98 |
99 |
100 |
All features, supported by the post type.
101 |
102 | JSON data type: object
103 |
Read only
104 |
Context: edit
105 |
106 |
107 |
108 |
109 | has_archive
110 |
111 |
112 |
If the value is a string, the value will be used as the archive slug. If the value is false the post type has no archive.
113 |
114 | JSON data type: string or boolean
115 |
Read only
116 |
Context: view, edit
117 |
118 |
119 |
120 |
121 | taxonomies
122 |
123 |
124 |
Taxonomies associated with post type.
125 |
126 | JSON data type: array
127 |
Read only
128 |
Context: view, edit
129 |
130 |
131 |
132 |
133 | rest_base
134 |
135 |
136 |
REST base route for the post type.
137 |
138 | JSON data type: string
139 |
Read only
140 |
Context: view, edit, embed
141 |
142 |
143 |
144 |
145 | rest_namespace
146 |
147 |
148 |
REST route's namespace for the post type.
149 |
150 | JSON data type: string
151 |
Read only
152 |
Context: view, edit, embed
153 |
154 |
155 |
156 |
157 | visibility
158 |
159 |
160 |
The visibility settings for the post type.
161 |
162 | JSON data type: object
163 |
Read only
164 |
Context: edit
165 |
166 |
167 |
168 |
169 | icon
170 |
171 |
172 |
The icon for the post type.
173 |
174 | JSON data type: string or null
175 |
Read only
176 |
Context: view, edit, embed
177 |
178 |
179 |
180 |
181 |
182 |
183 |
184 |
185 |
186 |
Retrieve a Type
187 |
188 |
Definition & Example Request
189 |
190 | GET /wp/v2/types
191 |
192 |
Query this endpoint to retrieve a specific type record.
Scope under which the request is made; determines fields present in response.
244 |
245 | Default: view
246 |
247 |
One of: view, embed, edit
248 |
249 |
250 |
251 |
252 |
253 |
254 |
255 |
--------------------------------------------------------------------------------
/using-the-rest-api/backbone-javascript-client.md:
--------------------------------------------------------------------------------
1 | # Backbone JavaScript Client
2 |
3 | The REST API includes a JavaScript/Backbone client library.
4 |
5 | The library provides an interface for the WP REST API by providing Backbone Models and Collections for all endpoints exposed through the API Schema.
6 |
7 |
8 | ## Using
9 |
10 | Activate the WP-API plugin. Enqueue the script directly:
11 |
12 | ```php
13 | wp_enqueue_script( 'wp-api' );
14 | ```
15 |
16 | or as a dependency for your script:
17 |
18 | ```php
19 | wp_enqueue_script( 'my_script', 'path/to/my/script', array( 'wp-api' ) );
20 | ```
21 |
22 | The library parses the root endpoint (the 'Schema') and creates matching Backbone models and collections. You will now have two root objects available to you: `wp.api.models` and `wp.api.collections`.
23 |
24 | The models and collections include:
25 |
26 | Models:
27 | * Category
28 | * Comment
29 | * Media
30 | * Page
31 | * PageMeta
32 | * PageRevision
33 | * Post
34 | * PostMeta
35 | * PostRevision
36 | * Schema
37 | * Status
38 | * Tag
39 | * Taxonomy
40 | * Type
41 | * User
42 |
43 | Collections:
44 | * Categories
45 | * Comments
46 | * Media
47 | * PageMeta
48 | * PageRevisions
49 | * Pages
50 | * Posts
51 | * Statuses
52 | * Tags
53 | * Taxonomies
54 | * Types
55 | * Users
56 |
57 | You can use these endpoints as-is to read, update, create and delete items using standard Backbone methods (fetch, sync, save & destroy for models, sync for collections). You can also extend these objects to make them your own, and build your views on top of them.
58 |
59 |
60 | ### Default values
61 |
62 | Each model and collection includes a reference to its default values, for example:
63 |
64 | `wp.api.models.Post.prototype.args`
65 |
66 | * author: null
67 | * comment_status: null
68 | * content: null
69 | * date: null
70 | * date_gmt: null
71 | * excerpt: null
72 | * featured_media: null
73 | * format: null
74 | * modified: null
75 | * modified_gmt: null
76 | * password: null
77 | * ping_status: null
78 | * slug: null
79 | * status: null
80 | * sticky: null
81 | * title: null
82 |
83 |
84 | ### Available methods
85 |
86 | Each model and collection contains a list of methods the corresponding endpoint supports. For example, models created from `wp.api.models.Post` have a methods array of:
87 |
88 | ```js
89 | ["GET", "POST", "PUT", "PATCH", "DELETE"]
90 | ```
91 |
92 |
93 | ### Accepted options
94 |
95 | Each model and collection contains a list of options the corresponding endpoint accepts (note that options are passed as the second parameter when creating models or collections), for example:
96 |
97 | `wp.api.collections.Posts.prototype.options`
98 |
99 | * author
100 | * context
101 | * filter
102 | * order
103 | * orderby
104 | * page
105 | * per_page
106 | * search
107 | * status
108 |
109 |
110 | ### Localizing the API Schema
111 |
112 | The client will accept and use a localized schema as part of the `wpApiSettings` object. The Schema is currently not passed by default; instead the client makes an ajax request to the API to load the Schema, then caches it in the browser's session storage (if available). Activating the client-js plugin with `SCRIPT_DEBUG` enabled uses a localized Schema. Check the [client-js example](https://github.com/WP-API/client-js/blob/master/client-js.php) or this branch which [attempts to only localize the schema once per client](https://github.com/WP-API/client-js/compare/features/only-localize-schma-once?expand=1).
113 |
114 |
115 | ### Waiting for the client to load
116 |
117 | Client startup is asynchronous. If the api schema is localized, the client can start immediately; if not the client makes an ajax request to load the schema. The client exposes a load promise for provide a reliable wait to wait for client to be ready:
118 |
119 | ```js
120 | wp.api.loadPromise.done( function() {
121 | //... use the client here
122 | } )
123 | ```
124 |
125 |
126 | ### Model examples:
127 |
128 | To create a post and edit its categories, make sure you are logged in, then:
129 |
130 | ```js
131 | // Create a new post
132 | var post = new wp.api.models.Post( { title: 'This is a test post' } );
133 | post.save();
134 |
135 | // Load an existing post
136 | var post = new wp.api.models.Post( { id: 1 } );
137 | post.fetch();
138 |
139 | // Get a collection of the post's categories (returns a promise)
140 | // Uses _embedded data if available, in which case promise resolves immediately.
141 | post.getCategories().done( function( postCategories ) {
142 | // ... do something with the categories.
143 | // The new post has an single Category: Uncategorized
144 | console.log( postCategories[0].name );
145 | // response -> "Uncategorized"
146 | } );
147 |
148 | // Get a posts author User model.
149 | post.getAuthorUser().done( function( user ){
150 | // ... do something with user
151 | console.log( user.get( "name" ) );
152 | } );
153 |
154 | // Get a posts featured image Media model.
155 | post.getFeaturedMedia().done( function( image ){
156 | // ... do something with image
157 | console.log( image );
158 | } );
159 |
160 | // Set the post categories.
161 | post.setCategories( [ "apples", "oranges" ] );
162 |
163 | // Get all the categories
164 | var allCategories = new wp.api.collections.Categories()
165 | allCategories.fetch();
166 |
167 | var appleCategory = allCategories.findWhere( { slug: "apples" } );
168 |
169 | // Add the category to the postCategories collection we previously fetched.
170 | appleCategory.set( "parent_post", post.get( "id" ) );
171 |
172 | // Use the POST method so Backbone will not PUT it even though it has an id.
173 | postCategories.create( appleCategory.toJSON(), { type: "POST" } );
174 |
175 | // Remove the Uncategorized category
176 | postCategories.at( 0 ).destroy();
177 |
178 | // Check the results - re-fetch
179 | postCategories = post.getCategories();
180 |
181 | postCategories.at( 0 ).get( "name" );
182 | // response -> "apples"
183 | ```
184 |
185 | ### Collection examples:
186 | To get the last 10 posts:
187 |
188 | ```js
189 | var postsCollection = new wp.api.collections.Posts();
190 | postsCollection.fetch();
191 | ```
192 |
193 | To get the last 25 posts:
194 |
195 | ```js
196 | postsCollection.fetch( { data: { per_page: 25 } } );
197 | ```
198 |
199 | Use filter to change the order & orderby options:
200 |
201 | ```js
202 | postsCollection.fetch( { data: { 'filter': { 'orderby': 'title', 'order': 'ASC' } } } );
203 | ```
204 |
205 | All collections support pagination automatically, and you can get the next page of results using `more`:
206 |
207 | ```js
208 | postsCollection.more();
209 | ```
210 |
211 | To get page 5 of a collection:
212 |
213 | ```js
214 | posts.fetch( { data: { page: 5 } } );
215 | ```
216 |
217 | Check if the collection has any more posts:
218 |
219 | ```js
220 | posts.hasMore();
221 | ```
222 |
223 |
224 | ### Working With Revisions
225 |
226 | You can access post or page revisions using the PostRevisions or PageRevisions collections or through the Post or Page collection.
227 |
228 | For example, to get a collection of all revisions of post ID 1:
229 |
230 | ```js
231 | var revisions = new wp.api.collections.PostRevisions({}, { parent: 1 });
232 | ```
233 |
234 | Revision collections can also be accessed via their parent's collection. This example makes 2 HTTP requests instead of one, but now the original post and its revisions are available:
235 |
236 | ```js
237 | var post = new wp.api.models.Post( { id: 1 } );
238 | post.fetch();
239 | post.getRevisions().done( function( revisions ){
240 | console.log( revisions );
241 | });
242 | ```
243 |
244 | If you add custom endpoints to the API they will also become available as models/collections. For example, you will get new models and collections when you [add REST API support to your custom post type](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/). To access custom endpoints created, use the item's JSON endpoint name as CamelCase; for example if the item is found at the JSON path of /wp-json/wp/v2/my-custom-post, it can be accessed via the api at wp.api.collections.MyCustomPost. Note: Because the schema is stored in the user's session cache to avoid re-fetching, you may need to open a new tab to get a new read of the Schema.
245 |
246 | ```js
247 | // Extend wp.api.models.Post and wp.api.collections.Posts to load a custom post type
248 | const CustomPost = wp.api.models.Post.extend( {
249 | urlRoot: wpApiSettings.root + 'wp/v2/custom_post_slug',
250 | defaults: {
251 | type: 'custom_post_slug',
252 | },
253 | } );
254 | const CustomPosts = wp.api.collections.Posts.extend( {
255 | url: wpApiSettings.root + 'wp/v2/custom_post_slug',
256 | model: BLProduct,
257 | } );
258 | const someCustomPosts = new CustomPosts();
259 | someCustomPosts.fetch().then( ( posts ) => {
260 | // do something with the custom posts
261 | } );
262 | ```
263 |
--------------------------------------------------------------------------------
/reference/widgets.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Widgets
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a widget record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | id
14 |
15 |
16 |
Unique identifier for the widget.
17 |
18 | JSON data type: string
19 |
Context: view, edit, embed
20 |
21 |
22 |
23 |
24 | id_base
25 |
26 |
27 |
The type of the widget. Corresponds to ID in widget-types endpoint.
28 |
29 | JSON data type: string
30 |
Context: view, edit, embed
31 |
32 |
33 |
34 |
35 | sidebar
36 |
37 |
38 |
The sidebar the widget belongs to.
39 |
40 | JSON data type: string
41 |
Context: view, edit, embed
42 |
43 |
44 |
45 |
46 | rendered
47 |
48 |
49 |
HTML representation of the widget.
50 |
51 | JSON data type: string
52 |
Read only
53 |
Context: view, edit, embed
54 |
55 |
56 |
57 |
58 | rendered_form
59 |
60 |
61 |
HTML representation of the widget admin form.
62 |
63 | JSON data type: string
64 |
Read only
65 |
Context: edit
66 |
67 |
68 |
69 |
70 | instance
71 |
72 |
73 |
Instance settings of the widget, if supported.
74 |
75 | JSON data type: object
76 |
Context: edit
77 |
78 |
79 |
80 |
81 | form_data
82 |
83 |
84 |
URL-encoded form data from the widget admin form. Used to update a widget that does not support instance. Write only.
85 |
86 | JSON data type: string
87 |
Context:
88 |
89 |
90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
Retrieve a Widget
98 |
99 |
Definition & Example Request
100 |
101 | GET /wp/v2/widgets
102 |
103 |
Query this endpoint to retrieve a specific widget record.
310 |
--------------------------------------------------------------------------------
/extending-the-rest-api/adding-rest-api-support-for-custom-content-types.md:
--------------------------------------------------------------------------------
1 | # Adding REST API Support For Custom Content Types
2 |
3 | The REST API can create routes for custom post types and custom taxonomies inside of the `wp/v2` namespace, using the same controllers as the default post type or taxonomy term controllers. Alternatively, you can use your own controllers and namespace. This document will cover using the default controllers for your custom content type's API routes. This is the easiest way and ensures the highest chance of compatibility with third parties.
4 |
5 |
6 | ## Registering A Custom Post Type With REST API Support
7 |
8 | When registering a custom post type, if you want it to be available via the REST API you should set `'show_in_rest' => true` in the arguments passed to `register_post_type`. Setting this argument to true will add a route in the `wp/v2` namespace.
9 |
10 | ```php
11 | /**
12 | * Register a book post type, with REST API support
13 | *
14 | * Based on example at: https://developer.wordpress.org/reference/functions/register_post_type
15 | */
16 | add_action( 'init', 'my_book_cpt' );
17 | function my_book_cpt() {
18 | $args = array(
19 | 'public' => true,
20 | 'show_in_rest' => true,
21 | 'label' => 'Books'
22 | );
23 | register_post_type( 'book', $args );
24 | }
25 | ```
26 |
27 | You can optionally set the `rest_base` argument to change the base url, which will otherwise default to the post type's name. In the example below, "books" is used as the value of `rest_base`. This will make the URL for the route `wp-json/wp/v2/books` instead of `wp-json/wp/v2/book/`, which would have been the default.
28 |
29 | In addition, you can pass an argument for `rest_controller_class`. This class must be a subclass of `WP_REST_Controller`. By default, `WP_REST_Posts_Controller` is used as the controller. If you are using a custom controller, then you likely will not be within the `wp/v2` namespace.
30 |
31 | Here is an example of registering a post type, with full labels, support for the REST API, a customized rest_base, and explicit registry of the default controller:
32 |
33 | ```php
34 | /**
35 | * Register a book post type, with REST API support
36 | *
37 | * Based on example at: https://developer.wordpress.org/reference/functions/register_post_type
38 | */
39 | add_action( 'init', 'my_book_cpt' );
40 | function my_book_cpt() {
41 | $labels = array(
42 | 'name' => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
43 | 'singular_name' => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
44 | 'menu_name' => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
45 | 'name_admin_bar' => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
46 | 'add_new' => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
47 | 'add_new_item' => __( 'Add New Book', 'your-plugin-textdomain' ),
48 | 'new_item' => __( 'New Book', 'your-plugin-textdomain' ),
49 | 'edit_item' => __( 'Edit Book', 'your-plugin-textdomain' ),
50 | 'view_item' => __( 'View Book', 'your-plugin-textdomain' ),
51 | 'all_items' => __( 'All Books', 'your-plugin-textdomain' ),
52 | 'search_items' => __( 'Search Books', 'your-plugin-textdomain' ),
53 | 'parent_item_colon' => __( 'Parent Books:', 'your-plugin-textdomain' ),
54 | 'not_found' => __( 'No books found.', 'your-plugin-textdomain' ),
55 | 'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' )
56 | );
57 |
58 | $args = array(
59 | 'labels' => $labels,
60 | 'description' => __( 'Description.', 'your-plugin-textdomain' ),
61 | 'public' => true,
62 | 'publicly_queryable' => true,
63 | 'show_ui' => true,
64 | 'show_in_menu' => true,
65 | 'query_var' => true,
66 | 'rewrite' => array( 'slug' => 'book' ),
67 | 'capability_type' => 'post',
68 | 'has_archive' => true,
69 | 'hierarchical' => false,
70 | 'menu_position' => null,
71 | 'show_in_rest' => true,
72 | 'rest_base' => 'books',
73 | 'rest_controller_class' => 'WP_REST_Posts_Controller',
74 | 'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
75 | );
76 |
77 | register_post_type( 'book', $args );
78 | }
79 | ```
80 |
81 | If you are using a custom `rest_controller_class`, then the REST API is unable to automatically determine the route for a given post. In this case, you can use the `rest_route_for_post` filter to provide this information. This allows for your custom post type to be properly formatted in the Search endpoint and enables automated discovery links.
82 |
83 | ```php
84 | function my_plugin_rest_route_for_post( $route, $post ) {
85 | if ( $post->post_type === 'book' ) {
86 | $route = '/wp/v2/books/' . $post->ID;
87 | }
88 |
89 | return $route;
90 | }
91 | add_filter( 'rest_route_for_post', 'my_plugin_rest_route_for_post', 10, 2 );
92 | ```
93 |
94 | ## Registering A Custom Taxonomy With REST API Support
95 |
96 | Registering a custom taxonomy with REST API support is very similar to registering a custom post type: pass `'show_in_rest' => true` in the arguments passed to `register_taxonomy`. You may optionally pass `rest_base` to change the base url for the taxonomy's routes.
97 |
98 | The default controller for taxonomies is `WP_REST_Terms_Controller`. You may modify this with the `rest_controller_class` if you choose to use a custom controller.
99 |
100 | Here is an example of how to register a custom taxonomy with REST API support:
101 |
102 | ```php
103 | /**
104 | * Register a genre post type, with REST API support
105 | *
106 | * Based on example at: https://developer.wordpress.org/reference/functions/register_taxonomy/
107 | */
108 | add_action( 'init', 'my_book_taxonomy', 30 );
109 | function my_book_taxonomy() {
110 |
111 | $labels = array(
112 | 'name' => _x( 'Genres', 'taxonomy general name' ),
113 | 'singular_name' => _x( 'Genre', 'taxonomy singular name' ),
114 | 'search_items' => __( 'Search Genres' ),
115 | 'all_items' => __( 'All Genres' ),
116 | 'parent_item' => __( 'Parent Genre' ),
117 | 'parent_item_colon' => __( 'Parent Genre:' ),
118 | 'edit_item' => __( 'Edit Genre' ),
119 | 'update_item' => __( 'Update Genre' ),
120 | 'add_new_item' => __( 'Add New Genre' ),
121 | 'new_item_name' => __( 'New Genre Name' ),
122 | 'menu_name' => __( 'Genre' ),
123 | );
124 |
125 | $args = array(
126 | 'hierarchical' => true,
127 | 'labels' => $labels,
128 | 'show_ui' => true,
129 | 'show_admin_column' => true,
130 | 'query_var' => true,
131 | 'rewrite' => array( 'slug' => 'genre' ),
132 | 'show_in_rest' => true,
133 | 'rest_base' => 'genre',
134 | 'rest_controller_class' => 'WP_REST_Terms_Controller',
135 | );
136 |
137 | register_taxonomy( 'genre', array( 'book' ), $args );
138 |
139 | }
140 | ```
141 |
142 | If you are using a custom `rest_controller_class`, then the REST API is unable to automatically determine the route for a given term. In this case, you can use the `rest_route_for_term` filter to provide this information. This allows for your custom taxonomy to be properly formatted in the Search endpoint and enables automated discovery links.
143 |
144 | ```php
145 | function my_plugin_rest_route_for_term( $route, $term ) {
146 | if ( $term->taxonomy === 'genre' ) {
147 | $route = '/wp/v2/genre/' . $term->term_id;
148 | }
149 |
150 | return $route;
151 | }
152 | add_filter( 'rest_route_for_term', 'my_plugin_rest_route_for_term', 10, 2 );
153 | ```
154 |
155 | ## Adding REST API Support To Existing Content Types
156 |
157 | If you need to add REST API support for a custom post type or custom taxonomy you do not control, for example a theme or plugin you are using, you can use the `register_post_type_args` filter hook that exists since WordPress version 4.6.0.
158 |
159 | ```php
160 | /**
161 | * Add REST API support to an already registered post type.
162 | */
163 | add_filter( 'register_post_type_args', 'my_post_type_args', 10, 2 );
164 |
165 | function my_post_type_args( $args, $post_type ) {
166 |
167 | if ( 'book' === $post_type ) {
168 | $args['show_in_rest'] = true;
169 |
170 | // Optionally customize the rest_base or rest_controller_class
171 | $args['rest_base'] = 'books';
172 | $args['rest_controller_class'] = 'WP_REST_Posts_Controller';
173 | }
174 |
175 | return $args;
176 | }
177 | ```
178 |
179 |
180 | For custom taxonomies it is almost the same. You can use the `register_taxonomy_args` filter that exists since WordPress version 4.4.0.
181 |
182 | ```php
183 | /**
184 | * Add REST API support to an already registered taxonomy.
185 | */
186 | add_filter( 'register_taxonomy_args', 'my_taxonomy_args', 10, 2 );
187 |
188 | function my_taxonomy_args( $args, $taxonomy_name ) {
189 |
190 | if ( 'genre' === $taxonomy_name ) {
191 | $args['show_in_rest'] = true;
192 |
193 | // Optionally customize the rest_base or rest_controller_class
194 | $args['rest_base'] = 'genres';
195 | $args['rest_controller_class'] = 'WP_REST_Terms_Controller';
196 | }
197 |
198 | return $args;
199 | }
200 | ```
201 |
202 | ## Custom Link Relationships
203 |
204 | Taxonomies & custom post types have a built-in association within WordPress, but what if you want to establish a link between two custom post types? This is not supported formally within WordPress itself, but we can create our own connections between arbitrary content types using the `_link` relation.
205 |
--------------------------------------------------------------------------------
/reference/application-passwords.md:
--------------------------------------------------------------------------------
1 | ---
2 | ---
3 |
4 | # Application Passwords
5 |
6 |
7 |
8 |
Schema
9 |
The schema defines all the fields that exist within a application password record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | uuid
14 |
15 |
16 |
The unique identifier for the application password.
The schema defines all the fields that exist within a plugin record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | plugin
14 |
15 |
16 |
The plugin file.
17 |
18 | JSON data type: string
19 |
Read only
20 |
Context: view, edit, embed
21 |
22 |
23 |
24 |
25 | status
26 |
27 |
28 |
The plugin activation status.
29 |
30 | JSON data type: string
31 |
Context: view, edit, embed
32 |
One of: inactive, active
33 |
34 |
35 |
36 |
37 | name
38 |
39 |
40 |
The plugin name.
41 |
42 | JSON data type: string
43 |
Read only
44 |
Context: view, edit, embed
45 |
46 |
47 |
48 |
49 | plugin_uri
50 |
51 |
52 |
The plugin's website address.
53 |
54 | JSON data type: string,
55 | Format: uri
56 |
57 |
Read only
58 |
Context: view, edit
59 |
60 |
61 |
62 |
63 | author
64 |
65 |
66 |
The plugin author.
67 |
68 | JSON data type: object
69 |
Read only
70 |
Context: view, edit
71 |
72 |
73 |
74 |
75 | author_uri
76 |
77 |
78 |
Plugin author's website address.
79 |
80 | JSON data type: string,
81 | Format: uri
82 |
83 |
Read only
84 |
Context: view, edit
85 |
86 |
87 |
88 |
89 | description
90 |
91 |
92 |
The plugin description.
93 |
94 | JSON data type: object
95 |
Read only
96 |
Context: view, edit
97 |
98 |
99 |
100 |
101 | version
102 |
103 |
104 |
The plugin version number.
105 |
106 | JSON data type: string
107 |
Read only
108 |
Context: view, edit
109 |
110 |
111 |
112 |
113 | network_only
114 |
115 |
116 |
Whether the plugin can only be activated network-wide.
117 |
118 | JSON data type: boolean
119 |
Read only
120 |
Context: view, edit, embed
121 |
122 |
123 |
124 |
125 | requires_wp
126 |
127 |
128 |
Minimum required version of WordPress.
129 |
130 | JSON data type: string
131 |
Read only
132 |
Context: view, edit, embed
133 |
134 |
135 |
136 |
137 | requires_php
138 |
139 |
140 |
Minimum required version of PHP.
141 |
142 | JSON data type: string
143 |
Read only
144 |
Context: view, edit, embed
145 |
146 |
147 |
148 |
149 | textdomain
150 |
151 |
152 |
The plugin's text domain.
153 |
154 | JSON data type: string
155 |
Read only
156 |
Context: view, edit
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
Retrieve a Plugin
167 |
168 |
Definition & Example Request
169 |
170 | GET /wp/v2/plugins
171 |
172 |
Query this endpoint to retrieve a specific plugin record.
The schema defines all the fields that exist within a nav_menu_item revision record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.
10 |
11 |
12 |
13 | author
14 |
15 |
16 |
The ID for the author of the revision.
17 |
18 | JSON data type: integer
19 |
Context: view, edit, embed
20 |
21 |
22 |
23 |
24 | date
25 |
26 |
27 |
The date the revision was published, in the site's timezone.