Concrete 5.7 vs Concrete 5.6.
The release of version 5.7 has brought Concrete 5 right up to date with the latest web practices. 5.7 now utilizes the Bootstrap responsive framework, making it a lot more future proof than 5.6 and allowing developers to work within a grid to create template layouts. Now I can’t really comment on the choice of framework as I have never worked with Bootstrap; we tend to develop our own themes using Foundation, bypassing any of the Concrete default themes.
The whole look and feel of 5.7 have been simplified and brought up to date to fit in with modern web trends. Everything from the dashboard to the on page editing has been addressed and redesigned. There’s no real advantage here except for a more visually pleasing interface, and let’s be honest we all like something that’s nice to look at!
In my opinion, one of the best new features (but maybe one of the hardest to get your head around) is the separation of page templates and page types. Now, I admit when I first installed 5.7 and started building a site I wasn’t a fan of this feature. I didn’t really know it existed and if I had, I would have structured and named my page templates very differently.
In 5.6 I could never decide whether to base templates on layout (e.g. full_width, left_sidebar, right_sidebar, fifty_fifty) or page type (e.g. about, blog_post, portfolio, project_page). For this build I went for the latter, my reason being I would be creating 2 pages using the same grid layout but including totally different content, and I wanted to have separate page defaults for each type of page.
By separating page templates and page types 5.7 allows you to do exactly this but using just one template, thus allowing you to keep the more generic layout based template names and reducing the number of page templates you need. For example, you could have a template “right_sidebar” and using that template create 2 different page types “blog post” and “project” which will most likely contain pretty different content. The user can choose from page type rather than page template when creating a page, being offered the choice of “blog post” or “project” when creating a page. This allows you to have one template with multiple content options.
For some reason 5.7 has chosen to use LESS rather than Sass for its CSS integration syntax on the new default theme “Elemental”. As I mentioned earlier, we bypass this and create our themes from scratch using Foundation and Sass, but it seems like an odd choice seeing as Sass is so widely used. There’s nothing wrong with LESS but it just seems like Sass is slightly more user friendly.
Default page attributes, unlike on 5.6, have to have a value in order to be shown automatically in the page attributes. It’s not hard to get around this – you just use a placeholder value when you create your page type attributes. Whilst it’s not necessarily a bad thing, if you’re not used to having to put a value in an attribute in order for it to show up you could spend a lot of time trying to figure out why your default page attributes aren’t showing.
The dashboard menu seems a bit quirky or doesn’t quite work how you would expect. Subsections are not accessible on the menu until you have accessed the top-level section, then the list of subsections appears once the top-level page has loaded. The way practices have changed it wouldn’t be alien to see an expand/collapse built into the menu to access subsections without having to load another page first.
I did, by pure chance, find a solution for this… Just double-click on the top-level section. This brings up the subsections instead of loading the top-level page. Who would have guessed that?!
Again it’s not a huge issue but I still can’t find a way to access the full dashboard page from the menu apart from landing on the page after you log in. Everything you need to access is in the menu but sometimes it’s useful to see everything laid out in front of you.
From a usability point of view, the most frustrating thing about 5.7 is the “Body” composer area you see when creating a new page. Version 5.7 automatically adds this block but you can choose to add more as you need to. Seems like a good idea, and we thought so too. We added all of our pages and put all of the main content copy within the “Body” area.
Then however, it came to trying to work out how to display it on the page. It took a while to figure this out but we got there in the end. For reference, go to the page type you would like to output the content on, and then go to outputs. On this page, you can edit the page defaults. You need to edit the page and add a “Composer Control” block and select which composer element you would like to display. In this case “Body”.
Now if that wasn’t awkward enough, if you do not set up the “Composer Control” block on the page type before adding content to the corresponding block you will loose all of the content in those blocks and have to go back and add it again. As you can imagine that’s very frustrating when you have added all the content once already!
One of the main downfalls with 5.7 is the inability to upgrade directly from 5.6. In the past version updates have been easy to implement through a simple process within the back end of your site. This version however, won’t be as simple. Concrete are using the term “Migrate” in relation to upgrading your site to 5.7.
This fundamentally means creating a fresh install of 5.7, re-installing your theme, and moving your content across manually. Not a quick task even for a developer. Although it may be a fairly time-consuming job at least developers will have the know how to implement the upgrade, but this is difficult if you have limited knowledge.
Why have they decided to go down this route?
“Giving up our backwards compatibility with this one version was a hard decision and path to take. WordPress has never done it, Drupal does it frequently. It’s not something we take lightly, but after 6 years there were just too many new best practices and handy frameworks that had matured to not move forward. In a perfect world we would certainly have preferred to have our cake and eat it too. Creating the opportunity to approach any problem without backwards compatibility concerns was the only way our team was going to get the UX and technical approach into 5.7 that we wanted. Seeing what we’ve made with 5.7, we know it was well worth it.”
Why do you even need to upgrade?
Mainly, Concrete has announced that they will only be releasing security patches for 1 more year for 5.6 meaning after a year your version of 5.6 will no longer be supported in terms of security updates.
We have since received the following comment from Franz Maruna – Founder & owner of Concrete5 regarding future support for 5.6
“We promised we’d provide security updates for a year after the community stopped supporting 5.6. So far, the community has kept 5.6 releasing coming out no problem so the clock isn’t quite ticking as fast as you imply.”
Another thing to note is that developers will lean towards developing for the most popular platform. As 5.7 starts to gain popularity you might start to see a drop off in available add-ons for 5.6.
Should I try 5.7?
If you are bound to using Concrete as your CMS I would definitely go for 5.7 on your next build, purely for the fact that Concrete has already suggested that they will only be supporting 5.6 for the next year. If you start a new site now in 5.6 you will only be creating yourself more work in the long run when you have to manually migrate to 5.7 in a years time because you want the benefit of security updates.
Yes, it does have its quirks, but it is still a relatively new platform and this is bound to happen. With the help of user feedback and bug reporting, no doubt Concrete will be releasing further updates to fix the little quirks. Like anything new, it always takes a little while to get used to. Just think how much you hate a new version of Facebook when it is released – a week later it’s the norm and you don’t think about it anymore.