Continuing on in our journey to creating this app.

We now have functionality to create a new post, and while I want to get into post meta, I want to get back to creating a new user.

As you may remember, a while back I mentioned that the default WP-API / JSON-REST-API does not actually support creating a new user, and I was awaiting for my change in the code to get pulled in. Well, good thing it is so extendable, we can just add a new route straight into our plugin! In fact, for really full control, lets create a whole new route and endpoints for all CRUD for users.

Creating a new WP-API endpoint

There are a couple things we want to think about before we even writing code. What routes do you want to use, will it/they make sense for the project, and how will you handle the endpoint or function that runs when that route is hit. I think it would be unwise to override the /users routes & endpoints, so instead what I am going to do is create a new one, have the basic functionality we need for it, and anything that /users already supports we can still tap into.

Where do add the code?

I know that Themes and Plugins have a pretty tight coupling in WordPress, but I have a philosophy of a faux MVC. MVC keeps all data logic in the controller, and since WP-API is our “controller”, I am going to put the code into our plugin. You may choose to put this into your theme, but think about it this way. If one day you want to change your theme, why worry about not having the endpoints / routes anymore?

Defining the routes

You don’t need much to start, you need to add a filter defined as ‘json_endpoints’, and the callback function will define out the new routes, and their respective callback functions. If you are using the dev branch of WP-API then the syntax has changed a bit, but the methodology remains the same. I am going to put everything into a class to keep organization of my objects.

This code is pretty simple. The real important part is the “register_routes” method, lets break out one of the arrays and take a look at what it defines.

In the first array I am defining ‘/sg_users/’ by itself. This defines routes to “”. Once you have that line in, the next step is to define a callback function, and finally assign which methods will trigger that callback.

So just to give you a more “template” feel to it.

Methods correspond to how you access the route, for example, when accessing a route via your browser (like you are viewing this webpage) that is a default GET request. You are requesting to “GET” data from the server. This also corresponds with your jQuery or AngularJS functionality.

$.get | $.post or | Factory.query()

Here are the available definitions for the methods to define after your callback, remember to separate with a pipe ( | ).

  • WP_JSON_Server::READABLE: Read endpoint (responds to GET)
  • WP_JSON_Server::CREATABLE: Creation endpoint (responds to POST)
  • WP_JSON_Server::EDITABLE: Edit endpoint (responds to POST/PUT/PATCH)
  • WP_JSON_Server::DELETABLE: Deletion endpoint (responds to DELETE)
  • WP_JSON_Server::ALLMETHODS: Generic endpoint (responds to GET/POST/PUT/PATCH/DELETE)

Additionally there are other configurations for how to accept data

  • WP_JSON_Server::ACCEPT_RAW: Accepts raw data in the HTTP body
  • WP_JSON_Server::ACCEPT_JSON: Accepts JSON data in the HTTP body (automatically deserialized by the server)

Finally there is a way to hide the endpoint from the index

  • WP_JSON_Server::HIDDEN_ENDPOINT: Hide the endpoint from the index

There is another route I have defined

Unlike the previous one, this only has 1 endpoint, but if you look at the route itself it includes ‘(?P<id>d+)’ which is a regular expression which defines the id. For example if we wanted to go to route

In any RESTful API we would assume this would return the user object for just the user with ID 5. I’m not sure if we will use this in our app, since the default WP-API users handles this already, but I am leaving it in for now.

Defining the endpoints

Now that we have the routes created, we have to do the real logic, the callback functions. We have already named them “get_users”,  “add_user”, and “get_single_user”.

Our main issue from before was the lack of ability to create new users, but we can easily solve that now. Since we want to address that issue first, lets tackle the ‘add_user’ callback first.

Creating a New WordPress User

Honestly to save time here, I am going to in the WP-API plugin and take out their add_user functionality, but just address the issue we were having, which is a non-authenticated user creation.

They have it setup so that the functionality is separated into a few different methods, so even though copying the inner functionality for add_user, we also need to copy over insert_user, prepare_user, and get_user.

Luckily if you go back to Part IV, we actually setup everything we need to test this whole thing! But we will need to change the factory, remember that?

Go back into wp-app/wp-app-factories.js and you will see the factory we need to change.

Notice the change to the route, this is so we point to our newly created API.

If you navigate to your – you should be able to see the sign up form we created earlier, open your console and fill in the information.


While I typically like having a delete option in the user creation, it is not that hard to just delete with the users page open in another tab. I am removing the delete functionality on save callback.

GitHub Repo

Don’t forget the GiHub repos where you can collaborate on the project is ready.

There is one comment

Comments are closed.