Middleweight Content Management with Barley

Miles Blackwood's picture

Software Architect

Blog

Middleweight Content Management with Barley

share

It's no secret that in the market for complex web applications and projects, Drupal has become a staple CMS amongst developers. A vibrant community, no lack of contributed add-ons and open coding standards have made it a reliable favorite--and climbing the learning "cliff" that's associated with understanding its inner workings is well worth the time spent.

On the other side of the CMS spectrum, the past several years have seen a couple lightweight blog engines pop up. Ghost and AnchorCMS, both lightweight services have both found solid footing. Jekyll, a GitHub project, allows for command line blogging with the option to write in lightweight Markdown and host for free on GitHub's own Pages service. Microblogging site Tumblr allows you to set-up multiple pages from the get-go; even the average WordPress site tends to forgo extensive configurability in lieu of the basic blog and static pages setup.

Perhaps directly in the middle of this great divide lies a CMS called Barley. Barley may actually have more notoriety as an inline-editor plugin (currently supported by WordPress and as of this writing, soon gaining Drupal support) but they also provide a hosting service, and a behind the scenes CMS that, while ultimately not as flexible as Drupal, still takes a fresh view of templating, content-types and static pages.

At its very basic, a Barley-powered site can use the inline editor by simply taking normal markup, and applying data-attributes to the sections which should be editable. For anyone familiar with the HTML syntax of adding an attribute, this is easy as pie (or cheesecake). Simply add a unique 'data-barley' attribute declaring that the section should be editable and another specifying which editor to include (WYSIWYGs of different complexity or an image specific editor).

<h1 data-barley="title" data-barley-editor="simple">Click to Edit Me!</h1>

Pretty simple, right?

Barley makes use of Dropbox to host the templating files and sync with Barley's codebase--so after creating a Barley account, I'd reccomend starting with one of their default templates to get acquainted with how dynamic content types work in Barley.

Here's a closer look at the root structure of the theme Red Oak:

> css
> images
> javascripts
v pages
  page.html
404.html
about.html
contact.html
humans.txt
index.html
photos-single.html
photos.html
post.html
tags.html
timeline.html
LICENSE.txt
README.html
settings.json

For Drupal developers, note that the settings.json is a sort of corrolary to the theme.info file. It houses theme information and lists aliases for content types. Here's what that looks like:

{
    "name": "Red Oak",
    "creator": "The Plain Team",
    "creator_url": "http://plainmade.com",
    "content_types": {
        "photos": "Photo Album"
    }

}

For the readers who are familiar with static HTML templating, this root directory may not strike you as that interesting. It looks like there are a few static pages, About, Contact, and so on. Conterintuitively, not all of these are necessarily static. the *-single naming conventions holds a template that displays what the page will look like when visiting a page of the a single type. Therefore photos-single.html (besides applicable page markup) contains a grid of placeholder images surrounded by a tag with an advanced editor allowing you to replace the images.

Following the Barley naming convention, photos.html contains a Barley loop, a bit of repeatable markup (with Barley-specific syntax) that displays how Photo albums ought to be rendered when in a list. When the site is live, these are the only two files needed for Barley to recognize a new Content type and allow you to dynamically create new Photo Albums.

Out of the two files, photos.html and photos-single.html only the file with the *-single.html pattern is required. The former can be utilized with a Barley loop that can be displayed anywhere, on any page in the template, the latter initiating the ability to upload and change content from a specific template.

Say, for example, you wanted a list of staff members to appear in the sidebar of the contact page only and not have their own individual pages. Simply create the layout of a single staff member. staff-single.html might look like this:

<section>    
    <p data-barley="staff_photo" data-barley-editor="simple">
        <img src="http://placehold.it/300x300" />
    </p>
    <h1 data-barley="staff_name" data-barley-editor="simple">Staff Name</h1>
    <p data-barley="staff_bio" data-barley-editor="advanced">Short Bio</p>
</section>

Everything has a unique data-barley identifier and is editable. This is key. Next here's an example of the Barley loop you could place in the sidebar to render the staff members:

<!-- repeat:staff -->
    <section>
        <p>%PHOTO%</p>
        <h1>%NAME%</h1>
        <p>%BIO%</h1>
    </section>
<!-- endrepeat -->

This will automatically pull any Staff content created into this loop wherever it appears in the template.

So as you can see, templating and adding custom content types is a breeze. There's no limit to how many content types you can render on a page other than the fact that there's a 50 count limit for each type. Also, be sure to never nest your editable sections or loops, as that can cause issues.

Out of the box, this is way more granularity than a lot of simple blog engines provide, but the downside is that unlike Drupal, things happen "automagically", that is, provided you don't have some way to see into Barley's source. This means that while it is flexible in the arena of content types, there's not much more extending you can do without some amount of blindness.

But the on-the-page editing does feel pretty futuristic, and it may be the right solution for a client who has no need for complex configurations but wants to keep their content fresh and dynamic without learning a brand new interface.

Barley - About, Downloads, Documentation

Miles Blackwood -- Home