TigerStripes CMS

TigerStripes CMS, the content management system we built and run this site on: pages that nest, every save kept, and a media library in the database.

What it is

TigerStripes CMS is the content management system this site runs on, and the one we install for the sites we build. A page is a title, an address, the layout it uses, a body written in Markdown, the pictures it carries, and the handful of fields that decide how it turns up in a search result or a share card. That is the whole content model, and it is small on purpose: a CMS with more features than the site it manages is a CMS somebody has to be trained to use.

tigerstripes-cms

Why we built our own

Most sites we build are particular. A page tree that matters, a design that is the point, a handful of pages edited every week and a hundred that never change. The off-the-shelf systems are built for the average of every site, which is why they arrive as a page builder, a plugin directory and a settings screen longer than the sitemap - and why a site ends up arranged to suit the software rather than the other way round.

Ours is the other way round. The templates are the site's own, the content model is the shape of the sites we build, and nothing is in it that no page of this site uses. The eight services above, the two projects on the Work page and every note in the news are rows in it - and so is this page, which is as good a demonstration as we can offer.

What it does

  • The page tree is the address. A page filed under Services lives at /services/<its slug>, and a page filed under that lives below it in turn. Move or rename a page and its old addresses keep working: every URL it used to have is answered with a permanent redirect to wherever it lives now, so an address that was printed, posted or linked from somewhere else does not rot.
  • Drafts, publishing, and a history of every save. Each save is a numbered revision with the person who made it, the time, and the note they wrote. An unpublished section takes everything inside it off the site rather than leaving links to pages nobody can open - and the CMS says so when a published page is stranded under an unpublished one, in the page list and on the sitemap, rather than leaving it for a visitor to discover.
  • Search and sharing are fields, not guesswork. Every page carries a meta title, a meta description, a canonical address, a noindex switch and the picture shown when it is shared. The sitemap and robots.txt come out of those same answers, so what the site tells a search engine and what it actually does cannot drift apart.
  • A media library, with the files in the database. Pictures, documents, audio and video in folders, searchable, with thumbnails at two sizes; galleries, and embeds for maps and social posts. Deleting something a page uses is refused, and names the pages that use it - which is the difference between a library and a folder that quietly breaks a page.
  • Templates instead of a page builder. A page chooses one of the site's layouts - Home, Service, News article, Portfolio item - and writes inside it. The design stays the design, the writing stays writing, and nobody can put together a page the stylesheet has never seen.
  • The enquiry inbox. The contact form on this site lands in the CMS, with new, read and archived states, so the studio answers enquiries in the same place it edits the site.
  • Accounts with roles. Administrators manage people, editors write, viewers read. A password is replaced rather than reset, and no screen can show you one - including ours.

What it does not do

No drag-and-drop layout builder, no multi-language content, no shop, no plugin directory. When a project needs one of those, the honest answer is to build the piece that is missing or to use a platform that already does it well. Either way it is a conversation before the work starts rather than a surprise halfway through.

How it starts

A walkthrough of this site's TigerStripes CMS, then your own: your templates, your pages imported from whatever you have (a spreadsheet, a folder of documents, or the site you are replacing), a session with whoever will be editing, and a short written guide to the two or three things you will actually do.

Then it is yours. A page's body is Markdown and its pictures are ordinary files, so nothing is trapped in a format only one product can read, and a backup is one file you can keep.

A little ambition goes a long way

Got a wild idea?
Let’s make it real.

Start a conversation