Taproot is Barnaby Walters’ publishing software. It’s written in PHP 5.4 and drives most of waterpigs.co.uk. It is not currently released to the public, although various parts of it have been extracted into libraries:
Most of the Taproot design artefacts are up on github too in taproot/design.
All content-creation UIs in taproot are publicly viewable — take a peek!
In addition to the indiewebcamp principles, these are some principles I have discovered through building taproot.
Taproot supports the following:
(Less of a “road” map, more of a kind of vague treasure map with no compass. Like pirates have)
Currently working on:
I got sick of all the complicated frameworkey nonsense which was accumulating in taproot. Symptoms:
And as such I am rewriting taproot to be smaller and flatter and saner.
Documentation of the aforementioned frameworkey nonsense is retained for posterity at the bottom of the page.
Modules all store their data in flat files (usually YAML) which I index in CSV file indexes, read/written using PHP’s
Mentions are stored separately from the content they refer to, for ease of editing and moderation. They’re stored with a flattened h-entry-like representation of them which can be easily used in various contexts.
The HTML and HTTP headers from cachable (i.e. public) URLs which are fetched (e.g. webmentioned or webmentioners) are stored in an archive, which also acts as a cache.
For content which has an intrinsic name (like pieces of music, contacts or blog posts) I tend to use an ASCII-fied slug of the name for the ID, generated using Helpers::toAscii. Otherwise (for notes) I create a <= six-character ID from the newbase60 representation of epoch days + number of seconds into that day.
The data is all stored in a microformats-2 JSON variant structure which is substantially flatter than mf2 JSON — all properties are properties of the parent object, not a properties key, there is no “children” key and only plural properties map to arrays. I keep most of the semantics the same except on the occasions where I prefer a different term (tag over category) or want to aggregate the properties from what would be multiple different mf properties into one (e.g. combining geo, adr and venue into “location”).
Previous, abandoned structure
Taproot has a highly modular structure. It is made up of an Application class, which handles event dispatching, simple dependency injection, routing and module loading. There are two types of modules — full modules, which expose URLs, and listeners, which listen to events dispatched within taproot.
Currently there are modules for Index, Notes, Articles, Contacts, Tunes, Tags and Mentions.
There are a large number of listeners which handle everything from authentication to POSSE and content transformation. Typically if I want to add a new piece of functionality I’ll do it in a listener, if I want to add a new content type I’ll create a new module.
(out of date as of 2013-12)
The Notes module is the mainstay of my Taproot usage. It handles the creation and display of short notes — kinda like tweets, but with a potentially much larger scope through the excessive use of tagging.
As in most of Taproot, the notes module handles basic CRUDL of data, and various listeners do everything else, including converting markdown, interpreting hashtags, autolinking @names, syndication of content.
Posting a note looks like this:
A still of the posting UI just after the note has saved: