Category Archives: Wordpress

Co-Authors Plus WordPress JSON REST API

I was trying to figure out if someone already wrote an REST API endpoint for WordPress Co-Authors plugin. There is wp-api-co-author-plus-endpoints, but it seems that it is focused on guest authors. For my project I needed to include information about co-author users. It turns out it’s very simple to extend existing REST API endpoints.

Here’s a full snippet:


if ( function_exists('get_coauthors') ) {
    add_action( 'rest_api_init', 'custom_register_coauthors' );
    function custom_register_coauthors() {
        register_rest_field( 'post',
                'get_callback'    => 'custom_get_coauthors',
                'update_callback' => null,
                'schema'          => null,

    function custom_get_coauthors( $object, $field_name, $request ) {
        $coauthors = get_coauthors($object['id']);

        $authors = array();
        foreach ($coauthors as $author) {
            $authors[] = array(
                'display_name' => $author->display_name,
                'user_nicename' => $author->user_nicename

        return $authors;

This allows you to query and get coauthors key back in response.

Jeff Kubina -

How to Super Charge your WordPress with Microservices

Confession: I’m amazed at the authoring experience that WordPress provides. Users are productive from the first hour and UI doesn’t get in their way. The story is similar for developers, if you stay inside the world of theme development. Try to do anymore complex and with tests, and it gets complicated. That is where (micro)service oriented architecture can help us.

At the Open Education Consortium, we use a mix of all the different approaches.

1. Let the WordPress call external API’s


At OEC, we provide functionality of Course search. While I could build it inside WordPress, it wouldn’t be optimal. I’ve developed it in Django with REST Framework. We get API Documentation for free and our Main WordPress site is using the same calls as everyone else.

To call an external API, you’ll need to extend template_redirect, init,
and query_vars actions and filters.

This way, you can format output inside your WordPress theme.

2. Let the Javascript call external API’s


This is not strictly WordPress, but it solves the other half of the problems you might have. If you don’t need to have output visible to Search Engines, you can render it with JavaScript. In one example, we’re showing a map of where our members are. We have a separate portal, where members can edit their contact information.

On WordPress side, Leaflet library calls the GeoJSON endpoint and displays it on the map. The data is always up to date and we’re using the best tool for the job.
This portal then exposes GeoJSON API, that Leaflet then displays.

3. Embed your WordPress output


For our Directory feature, I needed a flexible membership system. I ended writing it in Django with Solr. Django provides powerful form editing, that I didn’t want to replicate inside WordPress.

What I ended doing, is that I exposed API from WordPress with header and footer HTML. That way Django can just include 3rd party content. It also simplifies keeping the themes in sync.

I could do it using iframes, but then I would have problems with urls and the size of iframe content.

There is also a possibility for a future upgrade. Because we’re running on the same domain, we can read cookies from WordPress. This would allow us to check if user is logged into WP Dashboard and elevate their privilages inside Django app.


Modern Web applications are moving away from monolithic, one size fits all, solutions. While it’s common to see such infrastructure in the backend, it’s time that we start embracing it also on user facing sites. I wish some of the infrastructure inside WordPress, would make it easier, but I guess that’s an opportunity for a new library.

Architecting scalable WordPress Themes that are easy to maintain

WordPress Themes are like good computer games – easy to learn, but difficult to master (Bushnell’s Law). Unless you start writing them from scratch, you don’t appreciate good structure.

WordPress Template Hierarchy diagram displays all the possibilities we have:


While it explains, how things are working, it also shows how many different templates we need to create.

There is an alternative approach – we can use get_template_part. That way the core of your theme resides in index.php and specific template partials.

Your index.php should like this:

or more high level:

File 28-06-15 18 27 42

For each custom post type, create a template part inside partials/content-{post-type}.php. If it doesn’t exist, WordPress will load partials/content.php.

This approach has several benefits:

  • You don’t have to repeat the header and loop code for every template, reducing the amount of code repetition.
  • You can reuse template parts in other parts of the side (e.g. search results or custom archive pages).
  • If you write good generic fallback for template partials, you can have a first prototype of the theme running much faster.

Excellent starter theme that follows this design is _s (underscores) theme.

Results of WordPress Ninja Forms entries as JSON

Ninja Forms is rather nifty WordPress Plugin for forms. The main problem I have with it at the moment is that’s a rather mess in terms of data structure and getting data out of it. One can grab CSV file, but doesn’t really help you if you want to make a nice front-end.

So here’s a snippet that will dump your current form results in a way that you can further display them with AngularJS or similar.