At UVD we have an array of projects that vary greatly in their scope, budget and uses. We always try and come up with the best, most appropriate software solution to any business problem and that can mean selecting the tools we use very carefully. We tend to consider technologies which are appropriate for the task in hand, that will be efficient (in terms of resources) and that are hopefully interesting for us as developers. Enter Perch..
In this article we’ll be analysing Perch CMS after using it for the first time in a recent client project for a Architectural firm ‘Michael Drain Architects’. They envisioned a small and simple, yet visually stunning site with lots of high quality photography – you can read more about that project here.
Choosing a CMS
When it came to choosing an appropriate CMS solution there were a few key factors to consider:
- Initially, the CMS needed to be simple to implement due to the available resources at the time. We needed the solution to have a relatively low learning curve for the developers on the project who are predominately frontend focused.
- It also needed to be simple and lightweight, but still have an effective user experience. As the site was relatively simple we didn’t want to have a large over-engineered CMS solution that may confuse a user as to what they are able to change.
- Finally, having a support system and a community in place to help should the need arise.
Perch seemed to tick a lot of the boxes when it came to selecting a CMS. It markets itself as ‘the really little CMS’ so is lightweight and simple to get started with.
The good bits
- Perch’s tag system meant it was quick and simple to get started with creating editable regions within the page templates we’d built. An example of this is shown below:
- The admin area of Perch is clean and simple to use. Editable areas appear as soon as you place the
<perch:content>tags in the mark-up. These areas are easy to find and relatively simple to use for both the client and developer.
- Perch works on the LAMP stack so creating production and local development environments proved relatively pain-free.
- Perfect for small and simple sites.
Below is a short demonstration of how the admin works for altering content on the site. The simple interface allows the user to make alterations as necessary without any need for training or documentation.
Much like any other CMS it’s simple to use but in the case of Perch, it was activated by putting in
perch:content tags into the markup. Here’s a screenshot of the mark-up for this particular section:
The bad bits / Improvements
- Although it was quick to set up editable content areas, it proved quite difficult to configure the admin to our exact needs without editing the core files. So you could say it was simple to a point but the complexity increased quite dramatically when customising the admin.
- Any customisations to the core code meant that updating Perch would become a nightmare. Mainly because in order to update perch you have to replace the core files with the updated versions – meaning you lose any customisations you might have made.
- The asset handling could be greatly improved. At the moment Perch will place all assets in one ‘bucket’ and it’s impossible to dynamically create new buckets. This made handling these assets a little less user friendly as you had to tag each one to maintain some sort of sanity.
In conclusion, Perch did provide a good platform for the project – the solution was fit for purpose and the client was pleased with the end result. The main shortcoming for this project in particular was the asset management as it was very image heavy. One potential solution would be to look at Perch Runway, which is larger version of the Perch CMS, although there may be some other larger CMS’s available that are better suited to asset management.