Yep, imagine incrementally improving an open-source toolkit which is absolutely brilliant at doing the job it was intended to do over 5 years, but being reluctant to publicise it.

Terence started building wp-kit when he was Director of Creative Little Dots in 2015. Back then Wordpress was the main game, and almost all projects that came through the door were bespoke Wordpress builds.

It made sense to start to package up the commonly used code used in every project into one re-usable theme toolkit. Back then v0.9 was a terrible cocktail of code in semi-contextual files all included in functions.php and you'd just dump it in as a theme and begin dissecting it.

The idea was to make Wordpress, which has event-driven architecture i.e. hooks and filters, into something which feels more MVC. Any keen developer who undertakes this naive utopian yet endearing endeavour soon finds it's like trying to fit an apple in a keyhole.

After a long time trying to think of ways to make Wordpress handle requests like a Controller would, I decided to give up and embrace its event-driven architecture, namely it's "hooks". I figured if we just attached the code (Controller), which we only want to run on certain pages or templates, on hooks called in that template, or higher up in the Wordpress ecosphere but under certain conditions that checked the wp_query, or even the URL itself, then we'd essentially achieve the basic hypothesis.

From there we could do what we want, like reference custom models, or query Posts or Terms. We built some helper functions to output a view and send variables into the view. Views worked initially with Timber for twig files then later to TwigBridge to reduce bloating. From a Controller we could then output a bunch of HTML and kill the process.

The reality is, Controllers became a place to organise your code contextually and invoke on a certain hooks under certain conditions. Mostly, Controllers are where you'll put your code such as adding filters, where the filters are mainly related to one template. E.g. SingleProductController. It's become rarely a place where you'll actually handle the templating our output the HTML itself.

Version 2.0

It's moved on a long way from then. Version 2.0 was released in February 2018, which is basically a completely different framework to v1.0. Though it has very much the same features, it is much less opinionated, less bloated and gives the developer much more control.

Currently on 2.1.4 as at time of writing, installable via composer, using several Symfony/Illuminate composer packages, built in a way that feels like you're building a Laravel app and compatible with commonly used Wordpress environment toolkit Bedrock.

It comes packaged with great features like Webpack to auto-build your ScSS and JS files, with manifest file for super-duper cache-busting. Assets are declaratively enqueued within Controllers, which are can be declaratively invoked under certain conditions in certain Wordpress hooks.

Though you could say it's an opinionated toolkit, it's all very diplomatic and gives you full control. Much like Laravel, everything is basically a Service Provider attached to the main Container/Application and everything has a config file.

Since wp-kit/theme was released we've since worked on wp-kit/rest-kit which is a super stripped back version for just when you want to use Wordpress as a headless CMS but want to use of the good stuff in wp-kit like the Invoker, Controllers, ACF Integration.

On the ACF front, you can save down ACF groups as JSON files which is great for version control, and with wp-kit/rest-kit in particular the config file for ACF allows you to register ACF blocks for Gutenberg, and automatically saves down Gutenberg data to JSON and sends it as a field on the JSON object for a post. Meaning you can parse Gutenberg data as JSON in your app more conventionally.

Just to add the icing on the cake, wp-kit/rest-kit has webpack set up so you can easily register custom Gutenberg blocks using the React way and comes packages with some examples too. It also throws in some cool contenteditable features on ACF blocks so you can edit the fields on the left-hand side.

Yeah yeah, I get the picture, why don't you publicise it then?

I hate it. It's amazing, I love it, but I hate it.

For starters, we rarely use Wordpress anymore. Perhaps one or two projects a year. One of our client agencies uses it all the time as they have in-house developers, and I'm happy to support it. Sometimes they know how to use better than we do!

Secondly, the fact that it started as a research and development piece to see if we could achieve a viable and non-ugly MVC pattern within a custom Wordpress Theme and failed just upsets me. It's now a toolkit that lets you organise your code and invoke that code on a hook. I think this more reflects how much of a one-way street Wordpress is.

Thirdly, though we started wp-kit/rest-kit in 2019 and it's a real success, with Creative Little Dots having used in on two major projects this year, Wordpress as headless CMS just feels like a Frankenstein solution right now while there are solutions for headless CMS' out there.

Wordpress released Gutenberg without any real consideration of how that data could be consumed via the Rest API aside from just sending it all as one big "let me dangerously inner that" string. Again, another nauseatic moment from Wordpress. Having to built some opinionated feature in rest-kit to properly parse that data and add it to the Rest API response just feels similar to the taste of cow's milk in my oat latte.

I'm proud of the View system (Twig etc.), ACF-Integration and the way it makes development feel more like your writing a Laravel app and the way. But, I don't like to publicise it, since I have a complicated relationship with Wordpress.