Developing a plugin using DI and TDD 06

Planning the “call home”.

Thinking about clicks

The current implementation of the “I’d like this” plugin is merely printing a button on the page.
Adding the [idlikethis] shortcode anywhere on a post or page will print the button inline with the text; clicking it will amount to nothing though.
Three I’d like this buttons The button is meant to allow users to have a quick and anonymous interaction with the post or page at hand giving the author a quick and dirty feedback about an idea expressed in the post body.
In a way the button is a comment to the post; similarly to a comment it expresses a user opinion in the context of a post that means nothing outside of that scope.
This is to say the way I will store the “clicks” a button gets is by adding a comment to the post in a 1 to 1 relation.
Showing more than one instance of the “I’d like this” button on the page raises the issue of how each will be distinguished: I will change the shortcode rendering code to allow the post editor to add a small distinguishing description to each button so that in the backend each button will have its own story and statistics.

How to call home?

In essence each button should come with a unique description/descriptor in the context of a single post that will allow me to query and fetch them in the backend.
Since a page reload is out of consideration here the button click will rely on an AJAX call to the back-end that will handle the request appending a new comment to the post at hand.
The call might come from a user clicking the button on a single post view or a loop and hence the post ID has to be sent along.
Now: how to handle that AJAX call? The admin-ajax.php handling approach comes to mind but these are modern times and a think ahead approach is in order: why not use the WP REST API infrastructure that was put in place in version 4.4 of WordPress?
The fact that I’ve just attended the “A day of REST” conference might have an influence on the choice.

A POST request

Without relying on the core endpoints the WP REST API plugin offers and just taking what’s into WordPress latest version as granted I will register the first endpoint the small plugin API should listen on to handle the POST request a click on the button will send along.
Starting from the end I will define a new service provider class to handle the endpoint registration

<?php

class idlikethis_ServiceProviders_Endpoints extends tad_DI52_ServiceProvider
{

    /**
     * Binds and sets up implementations.
     */
    public function register()
    {
        $this->container->set_var('endpoints-namespace', 'idlikethis/v1');

        $this->container->singleton('idlikethis_Endpoints_ButtonClickHandlerInterface', 'idlikethis_Endpoints_ButtonClickHandler');

        add_action('rest_api_init', array($this, 'register_endpoints'));
    }

    public function register_endpoints()
    {
        $namespace = $this->container->get_var('endpoints-namespace');

        register_rest_route($namespace, '/button-click/', array(
            'methods' => 'POST',
            'callback' => array($this->container->make('idlikethis_Endpoints_ButtonClickHandlerInterface'), 'handle'),
        ));
    }

    /**
     * Binds and sets up implementations at boot time.
     */
    public function boot()
    {
        // TODO: Implement boot() method.
    }
}

and the bootstrap.php file has changed accordingly

<?php
$container = new tad_DI52_Container();

$container->register('idlikethis_ServiceProviders_Shortcodes');
$container->register('idlikethis_ServiceProviders_Endpoints');

On GitHub

The version of the code current to this post is on GitHub.

Next

I will start from the end of the request handling and TDD the code needed to append a comment to the current post while handling the request to move, with knowledge of what I will need, to the front-end and hence the shortcode markup later.