As much as I love ExpressionEngine, sometimes it isn't the right fit for a project, and often it's because it provides more power and flexibility than a site really needs. Sometimes you just need something a bit simpler. Or sometimes you get a project that the site owners don't want a CMS for, but as a developer, it's quicker to build the site with one. So this year, I began looking at some CMSs that I could use an alternative.
Of course, I've used Wordpress in the past, as it was what Tyssen Design was originally built on, and for the sort of situations I've been looking at alternatives for, it would be a viable option. But this year I've also had cause to dip back into a bit of Wordpress development (working on sites that have already been set up with it), and have to say that I haven't really enjoyed the experience. It could just be the themes I've had to work with, but the process of trying to track down a piece of content to edit across theme template files, theme framework files, theme language files, theme assets, or as a setting or user-entered content within the control panel has diminished my desire to work with Wordpress as a whole.
I've used CushyCMS on a couple of legacy static HTML sites in the past but it's too easy for site editors to make a mess of layouts with, particularly with images that haven't been resized to the correct dimensions beforehand.
There's only been a couple of requirements for the CMSs that I've been looking at: the ability to easily create custom fields, and upload images of any size which could then be used in templates at the correct size for the design. I drew up a bit of a shortlist of the ones I wanted to check out and they were Concrete5, Hero Framework, PyroCMS and Processwire.
The first I tried and which I've used on two sites this year is Concrete5 which describes itself as a
CMS made for Marketing but built for Geeks.
Concrete5 has a similar theming system to Wordpress: you add a folder to the themes folder and then select that theme from within the control panel. Like with Wordpress, you're encouraged to duplicate an existing theme as the starting point for making your own. A Concrete5 template can be very basic. Below is an example of one from one of the sites I did this year:
You can create as many different templates as you need and can assign templates to pages in a similar fashion as you would with Wordpress.
Unlike ExpressionEngine and Wordpress, Concrete5 is designed primarily to create and edit content from the front end of the site, rather than the CMS control panel. So in that respect, it's closer to Drupal. Once you've logged in to the control panel, you then navigate to the front end of the site where a toolbar appears above the page giving you a variety of editing options.
Area('Main') appears in the template above, you'll see a text link to Add To Main on your site's page when in page edit mode. Clicking on the link will bring up a context menu, of which one of the options is Add Block. Blocks literally are the building blocks of Concrete5 and give the site editor the ability to enter any sort of content into a particular area of a page. Not only that, but you can add as many different blocks as you want. After you've entered one block, a link to add another will appear below it.
Concrete5 comes with a default set of blocks that you can add that include:
- WYSIWYG editor for general text content
- search, and
You can also install custom blocks from the Marketplace to provide functionality not included in the default set, or you can code your own custom blocks. For one of the sites I did, I needed simple label/value pair functionality which if I'd been using ExpressionEngine would've required a single custom field, so I created a custom block. For the other site, the client didn't like the functionality provided by the default Concrete5 image slider so I thought it'd be straightforward enough to replace it with Nivo Slider.
The concept of add-ons for Concrete5 is similar to that of ExpressionEngine, but the process of adding them is different. With ExpressionEngine, you download your add-on (quite often after having purchased it first), which could be from one of several locations (although more often than not from Devot-ee), then upload it to your site and install. With Concrete5 the only place you can get add-ons is the marketplace, and whether it is free or not, it has to be added to a cart first so that it can be associated with a particular account. You then associate your account with individual sites and only sites that are linked to accounts that have the add-on associated with it can download and install the add-on which is all done through the individual site's control panel.
This is good for add-on developers because it ensures that a licence is paid for before being used on a site, whereas with ExpressionEngine, you could download an add-on once and then just reuse it across several sites even though the licensing doesn't permit it.
It may just be me, but I found the process of associating add-ons with a site a bit confusing. You first create a user account with Concrete5 and then log in to your site's control panel and navigate to the site settings and choose to ‘connect to the community’ to create a project. You can then assign multiple URLs to a project which is good if you're working on a site with different environments. That worked out fine for the first site I did, but when it came time to do the second, it seemed to me that I had to create a new account to create a new project as there's no way to add projects from the projects page of your account. I didn't think having multiple Concrete5 accounts was the way to go, so I just added URLs to the project I already had going which also doesn't seem right because I would think it should be one project per site.
Pros & Cons
Some people like being able to see the page they're working on when entering content and that also helps too if you prefer to have the site in front of you with its navigation easily viewable when adding new pages. Giving site editors that sort of ability is probably Concrete5's main strength. That and its ability to add different content blocks and add more than one block per page. With some CMSs, if you want to add text, an image gallery, more text and then a video, the developer needs to know that information up front so templates can be coded accordingly. With Concrete5, that ability is all in the hands of the editor.
Getting up and running was also a fairly quick process. The way Concrete5 templates are put together is very similar to the way I code static PHP sites and also similar to Wordpress templates with includes for header and footer and then the body of your page in between.
As mentioned above, creating custom fields is not as easy with Concrete5 as it is with other CMSs as you have to code both the control panel views as well as front-end template output. And while it's necessary to be able to edit the site from the front end, the other thing I don't like about Concrete5 is that it forces some mark-up on you by adding scripts necessary for site editors. It's not a great deal when not logged in, but if you like to have 100% control of your mark-up output, then Concrete5 may not be for you.
I find the management of users and their roles to be a bit unintuitive wth Concrete5. Users are managed from Users and Groups, but their permissions are managed from Sitewide Settings, and only after clicking Click here to modify other permissions from under the Access tab.
And by default, new user groups are created with Sign in as User set to Yes which means that once you've logged in, regardless of your other access permissions, you can navigate to the area of the control panel that lists other users and then choose to log in as that user, which means that if you choose a super admin, you can then get the same level of access. The very first Concrete5 site I worked on had been created by a developer who had then gone away on holiday and wasn't contactable and the client couldn't log in to actually make the site live. I was able to log in with their editor login and then log in as the developer and make the necessary changes. That was a good thing for the client in that particular case, but in general doesn't strike me as a particularly good security practice.
I like some things about Concrete5 but there's enough there that niggles me about it too for it probably not to become my main alternative to ExpressionEngine. If anyone else has had experiences with Concrete5 they'd like to share, I'd love to hear them in the comments.
Next up in this series, Hero Framework.