Simplifying How Content Works
by Brian Warren
When building a website it’s easy to get focused on the stuff that’s under the hood. You want to minimize database queries and find smart ways to use your markup and styles. Those things are absolutely important, but what’s also important is to make sure the site makes sense for those running it. With this article, I’m going to dive into one way to simplify how content works in ExpressionEngine by expanding the use of the Pages module to contain not just static content on a site, but a centralized hub for all those other bits of content that one might need to edit.
When I first started using the Pages module, I looked at it as a handy way to gather “static” pages in their own separate area in the Control Panel. This was an excellent solution for About pages, Privacy Policies and the like. The Pages module filled a gaping hole in how ExpressionEngine works.
Then I started using it for some slightly more non-traditional ways and the usefulness of the Pages module for me elevated to a new level.
Take this news release page:
News release page
In the main part of the page, we have a list of entries from a news channel. That’s not the only thing on this page. We have an intro, some snippets of information on the side, and a great big photo. How does that information get on the page?
I used to do this via templates, keeping all that information safe and sound in the code. This is a solid approach, but alas, it’s a little on the unfriendly side if your client ever wants to edit that photo or bit of text. It could also lead down a dangerous path if your client has Super Admin rights and decides to dive into the templates to change something.
Another option is to put these into EE Snippets, or Low Variables where everything is editable and safely away from the templates. These are great options, which are pretty dang useful for lots of scenarios, but they are not my favorite solutions for this situation. You will see why that is as I explain how it works.
This isn’t really a “Page”
You’re right. It’s not a single-entry “static” page, and it’s not really what the Pages module was designed for. To that, I say, pfui. Let’s get on with making this site awesome and extremely easy to use for your clients.
First you need to set up your fields. Think through all the bits content of a client would want to edit on this page. We’ve done a bit of that already:
- Intro
- Masthead image
- Sidebar text
- Ad space
Remember, the news releases themselves will be in their own channel so we’re focusing on all the surrounding content.
Set up these as custom fields in a new field group and then create a new channel for your Pages (I call mine “pages,” can you believe it?).
Now it’s time to create that page for the news releases, filling in the text and uploading the image. As for what to put in the Pages tab of the publish form, I suggest giving this a pages URI of “news.” It’s funny because this part isn’t extremely critical to how the templates work, but it’s essential for why this whole idea matters for your clients. You’ll see what I mean in just a bit.
All of the data is there for this news release page. Let’s create the template to put all of this together.
Creating the template
First, create a template that will live at /news/. You can go back and edit the page entry you just created to use this template, but that’s not critical since we won’t be relying on EE to know what template to use. However if it makes you feel better, who am I to stop you?
There are two main parts to this template, the shell and the list. The shell is where we pull in all of the content for the page we just created. The list is where you have your channel entries tag for the actual news releases.
Let’s jump into code so you can see what I mean:
{!-- pages shell code --}
{exp:channel:entries channel="pages" entry_id="244" dynamic="off"
disable="categories|member_data|pagination|trackbacks"}
<h2>{title}</h2>
{pages-intro}
{pages-photo}
<div id="sidebar">
{pages-sidebar}
</div>
{/exp:channel:entries}
{!-- news release loop --}
{exp:channel:entries channel="news" limit="25" paginate="top"
disable="categories|member_data|trackbacks"}
<h3>{title}</h3>
<p class="date">{entry_date format="%F %j, %Y"}</p>
{excerpt}
<p class="more">
<a href="{title_permalink=news/archives}">Read More →</a>
</p>
{/exp:channel:entries}
In the first section of the code we have the “Pages Shell Code”. This is where we bring in the content for the shell of the news release section. You can see how I specified the entry_id. We can do this because we can know exactly the entry_id of this page. Also, we can’t guarantee that we will always be on the /news/ URL (for instance, once we jump to the second page of the pagination the Pages URI will cease to match. For the same reason I’m using dynamic=“off”, which isn’t a bad idea since we are being so explicit.
As-is this should work just fine. We haven’t done anything really magical, but, the really exciting part comes when trying to explain this to clients.
The Payoff
It wasn’t until I adopted this method that I could really start to tell clients that the Pages tab is where you go to edit pages on the site. I know, it’s a radical thought. But if you have to tell clients that content lives in four different places and they have to consult a cheat sheet to find the hidden treasure, you’re doing something wrong.
With this method, any kind of content that stays put on the site can now live in Pages. Heck, even the Homepage can be there. By all means create a page for the homepage (give it the pages URI of “homepage”), and put any kind of specialized homepage-only content there.
While there are scores of ways to do this sort of thing (I know many of you are stretching your fingers ready to type a comment telling the world how awesome the Structure add-on is—and it is), using the Pages module makes managing the non-dynamic site content easier and simpler for your clients.
Posted on May 25, 2010
Post to Twitter