Headless Wordpress/Drupal is galloping into view with Sleepy Hollow references tagging along for the ride

By: (plus.google.com) +David Herron; Date: 2015-12-16 11:31

Tags: Wordpress » Drupal Themes » Drupal

Headless Wordpress is becoming a thing, now that Wordpress 4.4 has been released and has some core support for a REST API. The Drupal world has seen Headless Drupal work for a couple years now, and the Wordpress community has seen the light as well. The advantages of decoupling the website rendering from content management are many, the biggest perhaps being the rapidly changing best practices landscape for delivering content to the display device. The capabilities at the client end are rapidly morphing, much more quickly than the release cycles of the content management systems.

Yesterday, Pantheon held a Webinar about Headless Wordpress .. so here's a few thoughts and notes. I'm excited by the possibilities but disagree with some of the policies being developed.

Foundational understanding -- what the heck are we talking about: Headless What?

Are we talking about Ichabod Crane and the Headless Horseman? Nope. Headless Wordpress/Drupal is to split away the website rendering task from the rest of the system. You'd have your preferred content management system to store the content. The rendering layer would then access that content via an API. And it's feasible to have multiple rendering layers for different delivery destinations -- render the content one way for Google AMP, another way for Facebook, another way for desktop browsers, another for mobile, etc.

To generalize the concept a bit, what about switching from a monolithic system to one built up from microservices? The microservice architecture is all the rage nowadays, but it's not just a cool buzzword. A system built from microservices should be more scalable - just increase/decrease resources on the service that needs it. But more importantly each microservice will be more maintainable. A small service with a well defined API can be easily coded/tested by a small team, and its feature-set can be iterated independently of other microservices so long as it maintains API compatibility. Building a large service from several microservices means the whole system should be easier to maintain, and features can be iteratably added in an organic fashion.

By contrast the current popular content management systems (Wordpress, Drupal) are big monoliths. How long did the Drupal 8 development cycle take? How long before the bulk of Drupal websites will migrate to Drupal 8? And, more importantly, the architecture of both Drupal and Wordpress are what you'd call a monolith that supports plugins to extend capabilities.

One downloads a Wordpress or Drupal distribution from the central website, and poof in a few minutes you have a website. That has user experience advantages in setting up sites, but what's the long term cost? The whole system is more rigid than it should be. What about the task of integrating user/account management with some other service? Neither make it easy to replace specific services within the content management system, because it's a monolith.

In a microservice architecture system, the individual services could be swapped out for other services that implement the same API. Suppose you wanted a centralized media (image, audio, video) service that supplied media files out to several websites? How would you do that in Wordpress or Drupal? If, on the other hand, an appropriate media service API existed, a centralized media server could be connected into the backend of several websites.

Permeable boundary between theming and the-rest-of-the-system

A serious problem with Wordpress or Drupal is the mixing of business logic into templates. Is a template the correct place to put an SQL query? Nope. But, it happens.

In Wordpress it is common practice to make WP_Query calls in theme files -- essentially meaning you're making an SQL query, in a theme file, fiddling with the data, and placing all kinds of business logic code in the theme layer. Architecturally this is wrong. Plus, it's a security/stability problem because it makes changes to theming code just as critical as code changes elsewhere.

With Drupal 8 this is somewhat fixed because the new theming layer prohibits code in template files. During the lead-up to Drupal 8 I'd seen a presentation on the new theming mechanism in Drupal 8, and one point by the presenter is the risk of a theme template containing code that executes the SQL command: "DROP TABLE users;" ... and that to generate the slide the person put the necessary code in their template file, then accidentally saved the template ... which then caused the SQL to execute, deleting their users table, thereby proving their point about the inherently risky architectural flaw.

This is one primary purpose for developing the Headless Wordpress/Drupal architecture. Done well it eliminates this risk, while additionally making it possible for the content rendering layer to iterate much more rapidly than the content management system.

First step - slap an API on the content management system allowing client code to access content as data.

Third step - PROFIT

The intermediate step is to implement one or more systems to access content through that API, and render the content for devices. It's possible to implement multiple client app's to access that API for different purposes.

  • Static website generator: Iterates over the content, dumping it out to static HTML files. This is hugely more scalable than any dynamically generated page out of a content management system.
  • Fully dynamic: Every page hit calls the API to access content
  • JavaScript in browser: The API calls could all be done in the browser, and its the browser that assembles the content in the page
  • Hybrid: Some static content, some dynamic content
  • Single page app: Build what looks like an Application, running inside a web browser window, with JavaScript driven controls and API's to the server
  • CMS-to-CMS: It's supposedly possible to rig one CMS instance to not store any content, but to access it from another CMS instance.

Implementation

I think all this is cool. Where I diverge from the story told by the Pantheon presenter is the implementation.

What he suggested is to, rather than render HTML on the server for delivery to browser, rig the CMS to send an HTML that's mostly JavaScript code that then uses the API to bring content to the browser.

As a result, the browser has to do a lot of work assembling the content, and there's lots of round trips between browser and server as it does so.

Another big problem is that search engines no longer have indexable HTML. Instead they must run faux web browsers in their web crawler farm, so that the faux browser can render the content in order to have indexable HTML. And, yes, the search engines have done this in response to the large number of websites that do significant amounts of content rendering in the browser.

I disagree that's a good idea for general purpose websites, but don't want to rathole on that topic.

The Pantheon dude suggested three JavaScript app frameworks: ReactJS, Backbone, AngularJS

There are of course a large variety of JavaScript app frameworks for in-browser development. Those three have significant marketshare, and big players are backing each.

By way of example the Calypso project was discussed. This is (developer.wordpress.com) a desktop application developed by Automattic, which lets people manage their Wordpress.com websites from an app rather than by logging into the (wordpress.com) Wordpress.com website. There's a Github repository containing all the code, and you can easily download an app for your platform (unless you're on a Chromebook, as I am).

Another example is a TodoMVC style app developed by the presenter -- (github.com) https://github.com/joshkoenig/todo-wp -- using Wordpress as the backend data store, and a front end app consuming a REST API from Wordpress.

« Republican Presidential Candidates want massive violation of First Amendment and other American legal freedoms MEADS Capability Nodes »
2016 Election Acer C720 Ad block AkashaCMS Amazon Amazon Kindle Amiga Android Anti-Fascism AntiVirus Software Apple Apple Hardware History Apple iPhone Apple iPhone Hardware April 1st Arduino ARM Compilation Astronomy Asynchronous Programming Authoritarianism Automated Social Posting Ayo.JS Bells Law Big Brother Big Finish Bitcoin Mining Black Holes Blade Runner Blogger Blogging Books Botnet Botnets Cassette Tapes Cellphones Christopher Eccleston Chrome Chrome Apps Chromebook Chromebooks Chromebox ChromeOS CIA CitiCards Citizen Journalism Civil Liberties Clinton Cluster Computing Command Line Tools Computer Hardware Computer Repair Computers Cross Compilation Crouton Cryptocurrency Curiosity Rover Cyber Security Cybermen Daleks Darth Vader Data backup Data Storage Database Database Backup Databases David Tenant DDoS Botnet Detect Adblocker Developers Editors Digital Photography Diskless Booting DIY DIY Repair DNP3 Do it yourself Docker Docker Swarm Doctor Who Doctor Who Paradox Drobo Drupal Drupal Themes DVD E-Books E-Readers Early Computers Election Hacks Electric Bicycles Electric Vehicles Electron Emdebian Encabulators Energy Efficiency Enterprise Node EPUB ESP8266 Ethical Curation Eurovision Event Driven Asynchronous Express Facebook Fake News Fedora VirtualBox File transfer without iTunes FireFly Fraud Freedom of Speech Gallifrey git Gitlab GMAIL Google Google Chrome Google Gnome Google+ Government Spying Great Britain Heat Loss Hibernate Hoax Science Home Automation HTTPS I2C Protocol Image Analysis Image Conversion Image Processing ImageMagick InfluxDB Infrared Thermometers Insulation Internet Internet Advertising Internet Law Internet of Things Internet Policy Internet Privacy iOS Devices iPad iPhone iPhone hacking Iron Man Iternet of Things iTunes Java JavaScript JavaScript Injection JDBC John Simms Journalism Joyent Kaspersky Labs Kindle Marketplace Lets Encrypt LibreOffice Linux Linux Hints Linux Single Board Computers Logging Mac OS Mac OS X MacOS X setup Make Money Online MariaDB Mars Matt Lucas MEADS Anti-Missile Mercurial Michele Gomez Micro Apartments Military Hardware Minification Minimized CSS Minimized HTML Minimized JavaScript Missy Mobile Applications MODBUS Mondas MongoDB Mongoose Monty Python MQTT Music Player Music Streaming MySQL NanoPi Nardole NASA Net Neutrality Node Web Development Node.js Node.js Database Node.js Testing Node.JS Web Development Node.x North Korea Online advertising Online Fraud Online Journalism Online Video Open Media Vault Open Source Governance Open Source Licenses Open Source Software OpenAPI OpenVPN Personal Flight Peter Capaldi Photography PHP Plex Plex Media Server Political Protest Postal Service Power Control Privacy Production use Public Violence Raspberry Pi Raspberry Pi 3 Raspberry Pi Zero Recycling Remote Desktop Republicans Retro-Technology Reviews Right to Repair River Song Robotics Rocket Ships RSS News Readers rsync Russia Russia Troll Factory Russian Hacking SCADA Scheme Science Fiction Search Engine Ranking Season 1 Season 10 Season 11 Security Security Cameras Server-side JavaScript Shell Scripts Silence Simsimi Skype Social Media Social Media Warfare Social Networks Software Development Space Flight Space Ship Reuse Space Ships SpaceX Spear Phishing Spring Spring Boot SQLite3 SSD Drives SSD upgrade SSH SSH Key SSL Swagger Synchronizing Files Telescopes Terrorism The Cybermen The Daleks The Master Time-Series Database Torchwood Total Information Awareness Trump Trump Administration Trump Campaign Ubuntu UDOO Virtual Private Networks VirtualBox VLC VNC VOIP Web Applications Web Developer Resources Web Development Web Development Tools Web Marketing Website Advertising Weeping Angels WhatsApp Window Insulation Wordpress YouTube YouTube Monetization