For a while now I’ve been working on a small library that can be used for bespoke, carefully ring-fenced content layout. Today I released a user-facing demo video that shows it in action on my next theme.

But I wanted to give a bit of a preview of what’s going on under the hood, in lieu of the developer documentation (which is still missing).

The content-layout-control is a small library which provides a Customizer control to which a developer can add components. The user can then use this control to add/edit/remove/re-order the components. And the components are then rendered out and saved into post_content .

The easiest way to think of it is like “widgets” for posts, except without all the data storage problems that widgets come with, and with more careful developer control over which components are supported.

The main goals of the project were:

Provide an alternative approach to content layout from traditional page builders by making most of the design decisions for the user. Solve some issues around data storage and persisting content long-term.

I feel pretty happy about how this library addresses the first goal. I think the library can be a really useful tool for client work and other situations where developers need to be able to support rich content editing but don’t want to hand over design control to users. Right now it’s a lib to be included manually, but I’m definitely thinking about putting the lightweight core into a plugin for easier dependency management.

The second goal is a bit of a mixed bag. By rendering the components into post content, the data is indexable and scalable, which solves a large part of the issue. But in my experience there’s still a heavy reliance on shortcodes for dynamic data – not layout data, but just for populating a page with data which might change (like a post). For example, there’s currently no way to register dependencies and re-render post_content when a post title that’s displayed in a component on another page changes. That means you end up needing to rely on shortcodes more than I’d like.

A quick developer-y run-down of what’s going on:

Backbone Models/Views and WP’s Underscore-like templates for rendering controls

Uses the REST API for retrieving component previews and other bits

Object-oriented approach to components so it’s easy to scaffold new layout components

Event-based architecture for communicating between control/preview panes (pretty much what the customizer already does, but adds easy retrieval of templates from server for PHP-side template rendering)

Event-based control of a slide-out panel for component controls (similar to widgets and menus in core)

Date rendered to post_content and “source” data serialized in post meta

and “source” data serialized in post meta Support for custom callback to restrict what posts can be edited this way (default is page , but in my theme I limit it to just the homepage)

I’ll be pretty tied up for a bit releasing this theme, but I want to get a stripped-down demonstration theme put together soon so that others can start playing around with it.

In the meantime, you can look at the github project and let me know what you think.