movie icon image

ExpressionEngine How-to Articles

Topics range from beginner to advanced, but are all born out of real world, professional, day-to-day use of ExpressionEngine.

Simplifying How Content Works

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>
    <
class="date">{entry_date format="%F %j, %Y"}</p>
    
{excerpt}
    
<class="more">
         <
a href="{title_permalink=news/archives}">Read More &rarr;</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

Filed Under: How-To, Displaying Content

AJP12:16 on 05.25.2010

This is one reason why I like using Structure. Parent page (in structure) gets all this type of content, and the child weblog (news in your case) gets all the news entries. Win win! Good stuff Brian

Hambo12:35 on 05.25.2010

How does it handle category or archive pages?

Brian K14:19 on 05.25.2010

Great insight Brian.

carvingCode21:07 on 05.25.2010

Nice!  I’m currently in the process of redesigning/reworking a site (I didn’t design) which uses pages.  I now better understand the methodology and can see that it won’t be necessary to totally scrap and start over.

Brian Warren21:16 on 05.25.2010

@AJP: Thanks for your kind words! I had a hunch Structure would get mentioned which is why I brought it up in my closing paragraph. There are lots of great solutions out there to a situation like this, which is one reason I really dig EE!

@Hambo: It should handle category or archive pages just fine, since we’re using dynamic=“off” and specifying the entry id in the parameters.

@Brian K: Thanks!

@carvingCode: If this article helped save you from having to scrap everything and start over that just brings a smile to my face. Fantastic!

John Faulds06:20 on 05.27.2010

I’ve been doing this for a while now. I always have a weblog/channel called Site pages, even if I’m using Structure as well. However, I tend to only use it only for pages that don’t have any subpage content. If it’s for a section of more than one page, I’ll use the entry_id or url_title method for the home page, but without the need to use the pages module.

moogaloo11:06 on 05.27.2010

I’ve never been a fan of structure, so have been looking for an alternative, client friendly solution and have come up with something kinda similar to this….
i have teh misc channel with a simplae title, text field (with WYGWAM most likely), and then an optional matrix for adding images, accordion lines etc.
Whenever I need to add a snippet of text, be it an intro paragraph, an error message, a piece of footer info, etc I do a simple entries tag to that specific Misc entry.
In terms of finding the right entry again, should the client wish to edit these snippets, I include a small Edit icon to the end of that text - whenever a client sees that little icon, they know they can edit it, and the icon links them straight through to the corresponding entry.

lebisol14:17 on 06.15.2010

Nice one Brian, pages get overshadowed by the magic word of ‘blog’ so they don’t get much attention.
On a smaller setup I agree with John F. above. If you have only a few ‘pages’ just make tabs in CP linked to particular entries if you want to link them directly to eg. “about us” page. But this only works for as many tabs as you can squeeze in the CP. Alternatively to CP tabs, teach a client to always edit weblog called “site pages” (or whatever).
It would be nice if there was a ‘menu builder’ something close to ‘publish’ menu in CP where you can quickly list-to-edit entries from specific weblog.
Anyhow…the beauty of EE is that there is so many ways to make the end user happy wink.

Post a Comment




Please notify me of follow-up comments.


Search EE Insider
EE Screencasts