State of the WordPress REST API

There are two key “components” to the API: the infrastructure that makes it possible to register endpoints and define their behaviours, and the core endpoints which leverage the infrastructure bits to create RESTful endpoints that let you read/write/manipulate WordPress features like posts, pages, etc.

The infrastructure bits are already in WordPress core. If you maintain a plugin or client website that you’d like to build a custom API for, that’s all set. You can go ahead and do that right now, no questions asked.

The core endpoints are what are causing all the fuss and drama. Essentially, a certain group of people (most vocally WordPress creator Matt Mullenweg) feel that the core endpoints, which are not yet in WordPress core, shouldn’t be merged until they can replicate every piece of functionality that the WordPress admin panel(wp-admin) is capable of.

The team who has been building the REST API for the past few years isn’t thrilled about that stance. They designed the API to be capable ofprogressive enhancement, where new features can be added without breaking old clients. They argue this gives them more time to determine the best approaches for some of these really complex features.

The other faction feels that releasing a limited set of core endpoints will ultimately cause more confusion and frustration for users, many of whom may be encountering APIs for the first time ever when they work with the WP REST API.

That’s essentially the state of affairs. Because Matt Mullenweg is a sort of “benevolent dictator for life”, the API is kind of in a stalled point until his (and others; he’s not the only one with this stance, but he’s uniquely positioned to affect change) concerns are quelled.


Drupal goes with Angular 2, WordPress with React, Laravel with Vue.js

Drupal and WordPress continue their battle for supremacy of the web, it looks like the two have also sided differently when it comes to their decoupling with JavaScript and REST efforts. Back in November 2015, Automattic – the driving force behind WordPress – announced their WordPress shell running on Facebook’s React view library:

Calypso is a modern shell for the old WordPress back end, using the soon to be available REST API. The shell is built with contemporary technologies such as React and Node.js. The interface is built off a clean slate and is already in production use over at
– The future of WordPress is JavaScript

Some six months later and much deliberation Dries Buytaert seems to have sided with the Google backed Angular 2 front end framework for their future:

Decoupling Drupal and working with a front end framework has been a hot topic in the Drupal Community for a while now. Dries Buytaert has discussed the prospects of different options, and has even credited the Angular 2 team for changing their licensing to be compatible with Drupal.
– Drupal team working on Angular 2 Universal support for Twig / PHP

These are competing technologies and the battle has now been upped a notch. What remains notable is that both sit on the shoulders of Giants; WordPress Facebook’s and Drupal on Google’s. The odd one out is Laravel showing support for Vue.js:

Vue.js is the best JavaScript framework that you’ve likely never heard of. We’ve already covered React here at Laracasts, so let’s move on to something else – something far more simple, many might say. Intrigued?
– The Vast World of Vue.js 0.12

JS Comparison: Angular vs. React vs. Vue

Data Journalism CMS Requirements

Content Management Systems are tools for publishing created content online. With the rise of rise of Data Journalism there is an increasing need to provide content creators with the tools to merge content and data.

Below are some opinions on what those requirements should be for a good Data Journalism CMS should have.

A mature DMS will let people do all the following things. Whether as a proprietary monolith, or by slick integration across the web:

  • Load and update data from any source (ETL)
  • Store datasets and index them for querying
  • View, analyse and update data in a tabular interface (spreadsheet)
  • Visualise data, for example with charts or maps
  • Analyse data, for example with statistics and machine learning
  • Organise many people to enter or correct data (crowd-sourcing)
  • Measure and ensure the quality of data, and its provenance
  • Permissions; data can be open, private or shared
  • Find datasets, and organise them to help others find them
  • Sell data, sharing processing costs between users

– Content Management Systems, remember those?

And another set:

Data Journalism requires flexibility from the publishing platform. Not only do you need to provide tools for creating original content by hand, but also integrated tools to collect and analyse large amounts of data. And all this needs to be done in a single easy-to-use environment to keep production cost reasonable.

Four points sum up what you should look at when selectign :

  • Excellent content creation tools: Content is where the media focuses at, you should not compromise on this.
  • Integrated data collection and analysis tools: There should be basic collection and analysis tools for collecting data from the visitors.
  • Integrated personalization tools: Automatic content recommendation tools for inserting data into the correct visitor context – based on profile or device at hand
  • An extensible interface: Both content and data centric activities need to be done in the same interface. It should be easy to embed content derived from data.

– Best CMS for Data Journalism

Choosing between a CMS (with a REST API) and Contentful

Contentful is a competitor to CMSes like WordPress, Drupal and Joomla. In fact the company specifically targets the classic CMS market directly on their website:

Like a CMS… without the bad bits.

How well does this statement hold water? First of all you have to consider the limited scope that Contentful targets. They only provide a CRUD and an API for their proprietary Content Repository.

For many use cases this is enough. If you’ve got an iOS/Android API that you want to complement with FAQs, for example then this is what Contentful works very well for. The provided APIs, SDKs and Documentation are top notch – and as a centrally controlled Commercial Entity they are arguably more stable than an Open Source effort which can lack direction.

Where Contentful does nothing is website management.. There are no tools for creating menus, no tree like structure to visualise your site’s information architecture. In simple cases it’s fine just to push content to a repository and pull it out with Angular 2 front end of a Metalsmith site generator.

But if your business needs focuses heavily Content and managing the the experience visitors get – then you’ll likely be better off with a Content Management System (CMS), which provides a lot of the tools you need to work on a site / web application on a daily basis. Managing content lifts, layouts, site languages and more dynamically is an effort that you’ll need to do manually then. And this is potentially a lot of work.

So Contentful is useful, but it’s hardly the only thing you’ll need to run a content based business like a Media Portal. You’ll need to add custom features, which will eat on the promise of simplifying and focusing on content.

Learn more about CMSes, Contentful and other options:


Drupal 8 is slower?

One of the advertised key selling points of Drupal 8 is speed. But according to some numbers it seems like the Drupal 7 is actually quite a bit faster than the latest iteration:


This probably ties into the large architectural changes in Drupal 8 to that aim to modernise the legacy application. Of course perceived speed is what matters in the end, but with advertising being that Drupal 8 is faster than Drupal 7, I would suggest everyone to look into these benchmarks: Drupal 7 vs. Drupal 8 benchmarks

Alternatives to WordPress

WordPress is a juggernaut of the internet. It all kinds of web sites, ranging from blogs to complex business critical web applications. Matt Mullenweg, the founding father of the project imagines WordPress as being an Operating System of the Internet.

So WordPress is everywhere, powering smartphone applications as well as nuclear power plants (who knows…), but is it really the best solution for everything? Of course not! There are plenty of different needs WordPress can fill adequately, but it is easy to stretch out of it’s capabilities in the long run.

This platform which was originally a humble blogging platform is still hardly the silver bullet some people see it as. This is why it is always healthy to keep an eye on the market and look for alternatives to WordPress, even if you’re heavily invested in it.

Here are some alternatives to WordPress that might work for you:

  1. Medium: This is a direct competitor to the platform ran by the Automattic company. It is a platform for publishing content and is superior in usability and has a great API. Medium has attracted big names such as Basecamp‘s developer blog, Signal vs. Noise
  2. Laravel: Laravel is a rapid application development framework that allows quick development of custom applications. It is very opinionated and thus very easy to pick up for developers, something which WordPress developers love.
  3. Contentful: WordPress has tried to keep up in the race to provide comprehensive Content APIs with their own initiatives with varied success. With a company fully in control of the platform, Contentful delivers excellent tools for content publishing and distributions.
  4. Bolt CMS: Bolt challenges WordPress in it’s own original turf. Being a simple and easy to use content management system. It focuses solely on content publishing and website creation. With a superior technological implementation Bolt is inherently more secure than WordPress.
  5. API Platform: API Platform is a general purpose application framework built using Symfony. It is completely agnostic to what data is being served and, thus is a better option for serving pure data – not content.


Symfony, ZURB Foundation and Gulp

Foundation from ZURB is a great framework for creating both sites and web applications with. It comes with it’s own handy command line tools that help you work with the source material, using a JavaScript build process powered by Gulp.

Symfony as a backend framework should interfere as little as possible with the flow developers are accustomed to when using Foundation (or some other similar front end toolkit). In the past Symfony relied heavily on Assetic, a PHP based front end build tool chain to optimise and minimise CSS and JavaScript.

Assetic served the Symfony community great for a long time, but with JavaScript powered workflows being the norm it might have seen it’s limelight. It will continue to power thousands of web application and sites well into the future, but with Symfony offering the Asset component there is a simple way that developers should consider:

The example in case was a very simplistic way of working with Symfony and the Foundation CSS framework Gulp build tools. It allows the use of the Foundation command line interface, for upgrading the framework itself. No messing around with Symfony bundles with outdated versions or hacking around with pure CSS versions of Foundation.

In this article you’ll find instructions on using ZURB Foundation with Symfony with Gulp, the original toolchain.

Why WordPress is so much more Successful than Drupal

For years the LAMP open source CMS scene has had the “big three”: Joomla, Drupal and WordPress. Joomla is still large, but has fallen a bit behind in mindshare when compared to it’s peers. You just don’t hear that much about it.

Both WordPress and Drupal founders and public spokesmen, Matt Mullenweg and Dries Buytaert respectively, are obsessed with marketshare. Mullenweg likes to underline the sheer WordPress marketshare numbers, where as Buytaert likes to point out that Drupal runs more of “the important” websites.

That makes it ok to quantify success as popularity.  It’s clear that WordPress has been much more successful than Drupal when it comes to numbers. But why? Drupal and WordPress share a lot of the base components for technology. While Drupal maybe a technically better product, there are a lot more technically more elegant systems out there – none of which enjoy even the popularity Joomla! still enjoys.

So why is this? It’s all about the control of the User Experience. WordPress development is more centrally controlled by a commercial entity, where as Drupal thought of as a community effort. With examples like Apple and Google, it’s clear that central control is key to creating great User Interfaces. Community efforts tend create products like GIMP, which is a fractal of bad design. Successful Open Source applications with UIs are often emulations of commercial products.

With many CMSes being capable of the same things, being peers featurewise, the battle moves from lines of code to providing the best user experience. WordPress has a better history at this and it has already taken the next step with Calypso, a fresh user shell for the WordPress backend. Meanwhile Drupal only recently gained basic WYSIWYG capabilities by default.

Acquia, the commercial entity with tens of millions in funding is also pondering on the next move for Drupal. In the meanwhile they need to keep the Drupal community happy with grants to the community members executing their base system product development.

Just as with large corporations like Microsoft and Google open sourcing out their machine learning frameworks (DMTK and TensorFlow) the key is providing the best user experiences and best date on top of commodity technology. This is where investors for both Acquia and Automattic are seeing the money at. In the process it will benefit Open Source as well.

With the lead WordPress currently has in the usability sector, compared to the patchwork experiences offered by Drupal it’s set to dominate in the future as well.


RxPHP: Async programming with observable streams in PHP

PHP has traditionally been synchronous, but with initiatives like Icicle joining the PHP-FIG that is bound to change. In the future doing things like database queries asynchronously will unlock improved performance by removing redundant waiting time.

ReactiveX is a group that offers reactive extensions for asynchronous programming. The flagship product is RxJS, a set of JavaScript libraries bound to become popular as the Angular 2 framework uses it for HTTP communications.

The ReactiveX group supports a number of technology platforms and PHP is now one of them. With RxPHP developers can use the same concepts as with RxJS, but in an Asynchronous PHP setting. This displays that while PHP may be boring, it is very much alive and evolving just as Java and JavaScript are.

Learn more about ReactiveX


Drupal is a monolith?

Monolith was a common buzzword through out 2014 and 2015. In software a monolith refers to a single large piece of software that handles a lot of different types of tasks. Microservices being the popular alternative, breaking the tasks out to smaller stand alone pieces of code.

If you look at the above definition it’s clear what category Drupal a site built with Drupal falls into: It’s a monolith. Just the common statement of “there’s a module for that” directs users to creating large software handling all kinds of tasks with Drupal.

Drupal core itself is relatively lean and has a rather focused task. Sure there are still “monolithic” modules like blog, comments and more in Drupal 8 core – but they don’t get in the way of things. Drupal offers tools for storing content and managing layouts.

In this trend of breaking tasks down to smaller pieces of software the Drupal community, leaded by Dries Buytaert has been drumming up the thought of decoupled Drupal by playing catch-up with WordPress as it hits 15 years of age. This quote underlines how Drupal is seen as a tool for everything:

Drupal may not always be the best solution, but it is almost always a solution
Building bridges, linking islands

But maybe you shouldn’t set up for “a solution”, but look at purpose built software and orchestrate them to work together? Why should you build a mediocre forum to your website with a Drupal module when you could just use something better suitable for that?

This has already happened with comments moving to services like Muut or Disqus. Other fields like commerce are ripe for this and the role of CMSes is increasingly focusing on the basics: Providing a content repository.

Maybe the prime time for a monolithic platform like Drupal and other traditional CMSes is past us. Big is not beautiful.