Working with Perch
I wrote this post a while back. The content can still be relevant but the information I've linked to may not be available.
I love working with Perch CMS and it's a very flexible and powerful system. Here's my Perch workflow and a few of my favourite things about working with it.
Layouts and pages
On a new site build, I build a static page(s) first. Once I have 2-3 pages (or sometimes only a single page), I add Perch layouts for common elements, for example
<footer>, navigation menus etc. I might have .html files at the start of the process but I change to .php when adding Perch layouts. The .html pages are kept if I think I need them as a reference.
The Perch layouts are just static HTML at the start. I'm really just using Perch layouts like PHP includes at this point. For example, for site navigation, I have a static menu and I change to a Perch-driven menu later depending on the site requirements.
I might have a couple of Perch layouts for the
<head> element because I like having a separate blog/news layout. I don't use layout variables much. Note to self: Maybe I should use them more.
- Tip: Use page attributes to add canonical links into your pages for SEO purposes - as described by Simon Cox.
For site content, I use Perch Blocks as much as I can. For instance, on CVW Web Design, each page has a single "Page Content" region and this is assigned to a "Content - Blocks" template that has six items, for example "Text in Columns", "Heading and Strapline", "Content Row" etc. When adding content, I just choose different items for each page.
I want my pages to be a series of instructions
Each Block has all the mark-up needed to display that section of the page. I want my pages to be a series of instructions for PHP/Perch and this modular approach enables that.
Of course, for some clients, a page full of editable fields in Perch admin isn't the best approach and in these cases, I would separate out page content into separate regions.
- Tip: Use template includes to make Blocks and templates easier to manage.
I use Redactor most of the time because I've never been very keen to give clients an editor with Markdown. I'm not saying that clients won't/cannot learn Markdown but I just think this is another unknown for clients at the start of their CMS experience. And that's something I want to avoid.
I've used SimpleMDE editor on personal sites. I like it for my own use.
For Perch admin, I add a few custom styles similar to what Graham Street describes. I think this differentiates some areas of the admin better.
I use Blog and Forms apps the most. For the blog post page, I get the post data at the start of the page and add it into a
$post variable that I can use anywhere on the page. This is different to the example post page that comes with the Perch blog add-on but it works better in many cases.
... and Perch Dashboard Links widget :-)
This is a short description of my Perch workflow. However, I hope it highlights a few things that will be useful for anyone working with Perch CMS.