One of the challenges you face when when you create something new is how best to describe it to people so they understand what it is for and how they can use it. While a number of developers and theme authors have dug into the documentation and example themes and learned how to use Carrington, we’d like to make it a little more accessible to others. We’d also like to clear up some misconceptions about the Carrington framework vs. other WordPress theme frameworks.
To get started with this, we’re going to try a good old O’Grady-style Q&A.
What is Carrington?
Carrington is a new (we think better) way of organizing a WordPress theme, coupled with a core framework engine that provides a bunch of exciting functionality for free, just by creating different named templates.
The Carrington framework is a completely additive framework. It builds on the existing core WordPress theme structure and functionality and uses core WordPress theme functions for easy adoption by experienced theme authors.
You can even use the Carrington framework selectively when creating a theme, more on this later.
Why did you originally create Carrington?
When you spend enough time creating advanced web sites using WordPress you eventually notice a number of things that you find yourself needing to do over and over again. Like any good developer, when you notice patterns you look for ways to automate and re-use functionality. We did this with WordPress themes and Carrington is the result.
Instead of having to create a bunch of conditional statements in theme code, Carrington supports a rich set of named template files and applies them as appropriate based on data conditions (examples: post is in category X, has a custom field of Y or a comment is by a user with a role of Z). Using Carrington allows you to create richer, more complex sites more easily.
At WordCamp SF this year, I was chatting with Adam Tow and he reminded me that I was talking about building this sort of system back in 2007 when we were working on the All Things Digital site together. It’s something I’ve wanted to build for a long time, and I’m really proud of how the idea has been realized with Carrington.
Why is the multiple template approach better than conditional code?
It’s a bit of a generalization, but the multiple template approach is a win over writing conditional code for a number of reasons:
- Less code = fewer bugs. It’s a bit of an oversimplification, but writing less code reduces the chance for bugs and edge-cases to sneak into your code.
- Fewer reference lookups = faster development. When you don’t have to look up how to access user permissions, if a post is in a certain category, the syntax for checking custom fields, etc. your development is quite a bit faster.
- Maintaining your conditional rules all in one place ensures that the logic for your site is consistently applied.
- Having the conditional rules all in one place also makes the site easier to maintain. It makes it less likely that you run into unexpected edge cases when adding a new post type, etc. – this sort of issue is common when you have complex conditional code in lots of different places.
- Designers/front-end developers have more power. By removing the requirement to write PHP code to achieve custom visual styling is certain situations for posts, comments, sidebars, headers and footers, etc., WordPress theme creation is more accessible for designers and front-end developers that aren’t as comfortable writing PHP.
Multiple templates does have a potential drawback of code duplication, but if you’re smart about how your structure your templates and create includes for common code bits, most of those concerns are non-issues.
How does Carrington differ from other theme frameworks?
A development framework trades convention for code. Basically, you (the developer) agree that you’ll follow certain conventions in your code and as a result you’ll get certain functionality, features, etc. for free as part of the framework you are using.
This is how development frameworks like Rails for Ruby, Django for Python, CakePHP/Symfony/CodeIgniter for PHP work, and it’s how we built Carrington as well.
You use the template naming conventions and directory structure supported by Carrington and you get to write less conditional code.
So it’s not a parent theme?
No, it’s not a parent theme and it isn’t intended to be. I think it’s really unfortunate that people decided to call parent themes theme frameworks. They aren’t frameworks in the standard development sense, they are parent themes that support child themes to override certain components of them.
How do people maintain their changes if they can’t create child themes?
Carrington was created to help build complex web sites that are powered by WordPress. To do this it has added certain conventions that are not well supported by the current parent/child theme system in WordPress.
We may look at submitting core improvements in the future to allow this to work better, but it’s not at the top of the priority list yet.
Why call it a “CMS theme framework”?
When we started building Carrington we called it a theme framework because that’s what it is. However, since “theme framework” has been co-opted to mean “parent theme” this was causing all sorts of confusion.
We changed our terminology to “CMS theme framework” in an attempt to differentiate Carrington from the parent themes out there, while still indicating that it is indeed a framework – a framework intended for creating CMS web sites with WordPress.
Sounds complicated, it’s only for developers?
Not at all. The concepts are strikingly simple, however perhaps because they are somewhat challenging to the WordPress theme status quo and perhaps because we have not produced any tutorials yet, some folks seem to dismiss Carrington as too hard to use.
In fact, the opposite is true – using Carrington makes creating complex WordPress themes and web sites much easier.
How come there are so many files and folders?
With Carrington we took care to re-think and re-conceptualize how we use WordPress themes, and to abstract things at the levels we commonly need to make customizations. We also made sure to keep the same logical flow as a standard WordPress theme so that it would be as easy as possible for people to follow.
It basically boils down to this: where a traditional WordPress theme has a single file, a Carrington-based theme has a folder. Inside that folder can be as many templates as you like and the Carrington framework will choose and select the right file to use based on the page being shown.
This means that at just about every spot in the theme that you need to make a customization, you can do so without needing to write conditional code. You can simply make a new theme with a name that matches the situation you want it used in.
By abstracting the parts of the theme in a more granular way, it also means you have less repetition of code for a more elegantly constructed theme. The WordPress Default theme includes the code to display a post in several different files. Carrington uses the same file (or files, if you have different templates for different post types) in different places – you only have to change things once and they get updated everywhere.
Whare are the benefits for a designer?
Mainly the fact that you don’t have to write PHP code to apply rich, different designs to different posts, comments, sections, etc. You can spend your time working on your design and let the Carrington framework do all the heavy lifting for you.
Why did you release it?
We believe strongly in giving back to the WordPress community. We are thrilled at how powerful the Carrington framework is and how much easier it makes building the sites we work on. We want others to have those same benefits, and perhaps contribute back to Carrington as well.
The Carrington CMS theme framework has always been free, Open Source under the GPL. The code is hosted publicly on Google Code and we’ve even created our Carrington JAM theme to give folks a good starting point for creating a Carrington-based theme.
Why did you release themes based on it?
Again, to give back to the community. Also, we wanted to put out some examples of how the Carrington template abstractions can make certain features (AJAX loading of posts and comments for example) much easier than the traditional WordPress theme file structure.
How do you plan to help people better understand the power of Carrington and how to use it?
Hopefully this Q&A is a start.
Besides the thorough reference documentation that is already available and included with each Carrington theme, we’ve been working on some overviews and tutorials that should help explain the power of Carrington and make it more accessible to people.
Thankfully we’ve been very busy at Crowd Favorite this year, and this documentation has often taken a backseat to our project commitments (I started writing this Q&A 2-3 weeks ago). I hope we’ll have more examples and tutorials available soon. We welcome any tutorials, overviews, etc. from the community as well and will be happy to host them here with appropriate credit links.