WordPress CMS CRUD (Part 3): Some additional thoughts and ideas

• June 01 2020
• 3 min. read

In the last posts we created a CRUD system for authenticated WordPress requests but it's not complete. It currently only deals with the post content, it doesn't provide an easy way to paginate content, and it doesn't provide for how to access other parts of a WordPress site or app.

This post will discuss solutions to these problems.

Embedding content related to the post #

When we load the data from the posts REST endpoint we get references to the post assets like featured image, author, and comments.

This is good when we're exploring the API but it becomes troublesome when we are building the content out for displaying it to the user. We would have to make additional requests for these assets and we're not guaranteed that they exist so these additional requests and delays may be for nothing.

Instead we can leverage the API and use the _embed query parameter to include the additional post resources when we fetch the posts. This makes the response larger but it guarantees that we will have all the data available to build post listings and individual posts.

TO make the embedded assets available to individual posts, we need to modify the init() function to add the _embed: "" parameter to the get Axios call

The modified code looks like this

export function init(event) {
  if (event) {
    event.preventDefault();
  }

  .get(state.restUrl + "wp/v2/posts/", {
    params: {
      _embed: "",
      // Set number of posts to get
      per_page: 10,
    }
  })
}

This code will embed all associate assets to each post on the response, making it easier to create posts the match what we get with a WordPress theme.

Paginating content for navigation #

By default, the WordPress REST API will return ten items per request. We can change that using the per_page parameter to change the number of items that the API returns up to one hundred.

Creating the pages #

But in and of itself this is not enough. Using per_page will always return the same data. We need to tell WordPress what page of the content we want.

The way to do it is to combine per_page, that will give us the number of items that we want the API to return, and page that provides the offset where to start the count of items to return.

For example the following request will return the second page of 5 items from the site's REST API.

/wp-json/wp/v2/posts/?per_page=5&page=2

Both parameters are optional.

Leveraging X-WP-TotalPages #

So we know how to create pages of content but how do we make sure that we don't go over the last page?

WordPress's REST API provides two custom headers: X-WP-Total that gives you the total number of the type's items (post, pages, etc) in the collection and X-WP-TotalPages that gives the total number of pages available given the number of items per page we specify.

Using X-WP-TotalPages we can build page navigation links and we can build links to each page.

Accessing other elements of a WordPress site #

So far we've only worked with posts and their embedded content but many other items make up a WordPress application.

The following table, taken from REST API Handbook Reference shows you the default routes available through the API.

Default endpoints available on the WordPress REST API

This table does not include API routes added by plugins or generated outside the core API. Your overall API route table will certainly look different.

Edit on Github