Thread

I’m currently building a fairly meager EE2 site. I have a lot of pages with mostly “static” content, and I’m trying to figure out the best way to deal with it. The idea is that, for each page on the site, the client needs a blurb area at the top where they want to do their own thing, and then there will be more dynamic content below (usually a list of documents which are attached to the template using categories).

I bought Michael Boyink’s book, “Building an Expressionengine 2 Site”, and it suggests creating a new channel for each static page, and just having a single entry in that channel. I feel like this might be confusing to the client—what if they try to add a new entry in the “Home” or “Contact” channel and nothing shows up?

I’ve thought about also trying the Pages module, but I’ve been heard that it’s a bad idea (although I’m not sure what to believe). I’ve also thought of just placing everything into one “static content” channel… I’m just not sure what issues might come up if I do that.

I guess I’m just wondering: what are some other approaches? What are their pros/cons? What do you do for these sorts of things?

Thanks!

EDIT: Sorry! After posting I realized this sort of thing probably should have gone under “Community Help”. Is it possible to move this thread?

Moved to Community Help forum by Moderator

Quite often I just create a “snippets” Channel and use a few custom fields to give the publisher a few options, ie, if the sites structure isn’t too complex I might create a SELECT field with some predefined values such as “home” “about” “contact” so they can choose where to display that item of content. You could also use Statuses or Categories to do the same, it really depends how you want to approach it.

Thanks for the assist, Rob.

Gavin - there are multiple ways you could approach this, moving to the Community Help forum for additional community support.

Regarding:

I feel like this might be confusing to the client—what if they try to add a new entry in the “Home” or “Contact” channel and nothing shows up?

Perhaps I am misunderstanding, but this suggests that the content isn’t going to be “static” after all.

Perhaps I am misunderstanding, but this suggests that the content isn’t going to be “static” after all.

Hi Kernon,

The idea from Mr. Boyink’s book is that each “static” page is in a content channel of its own, and each “static channel” should have exactly one entry. That doesn’t mean that the client couldn’t accidentally try to create a new entry in that channel, and be confused as to why it doesn’t show up on the associated page.

Also, I’ve been using “static” with quotes because, no, these pages aren’t really static. The client requested the ability to edit them (that’s why I’m using a CMS)—the problem is that they don’t fit the Channel paradigm of most truly dynamic content. I assumed that was what the Pages module was for, but a lot of folks rally against it (although I’ve never heard a good explanation why—one of the reasons I created this topic). However, these pages really aren’t ever going to be edited. They might as well be static content, but I have to show the client that if they want to they have the ability to make changes to any page.

The word “static” is always misleading. By “static” people often mean pages/content that don’t change very often, eg an “about” page. What you have to understand is that every CMS is dynamic, you can call your content “static” “flat” etc but it’s always served “dynamically” at some point.

EE allows you to build these general page types in a number of ways:

1. By using one or more “Channels” to store the information in
2. By using the “Pages” module
3. By using a3rd party addon such as Low Variables

The word “static” is always misleading. By “static” people often mean pages/content that don’t change very often, eg an “about” page. What you have to understand is that every CMS is dynamic, you can call your content “static” “flat” etc but it’s always served “dynamically” at some point.

EE allows you to build these general page types in a number of ways:

1. By using one or more “Channels” to store the information in
2. By using the “Pages” module
3. By using a3rd party addon such as Low Variables

Yup, I agree. I guess what I’m asking here (which is why it’s a part of the title of this thread) is what’s your strategy and why.

EDIT: Also, bluedreamer, I wasn’t pointing the “your strategy” part at you so much, as you’ve already posted some options above. I just feel like people a being a bit light on the “why” part.

These are just some various thoughts…

First, though, what I did for mostly static content was have one to two “static” channels, but since I am also responsible for the content, there’s no possibility of confusion (I hope!).

You could build SAEFs for the client to update only the pieces that change sometimes, keeping them away from the back-end and the possibility of messing things up.

Or, if that isn’t possible, you’ll need to be very clear about how the information is organized and updated and what not to do—such as not adding new entries and expect them to show up automatically.

These are just some various thoughts…

First, though, what I did for mostly static content was have one to two “static” channels, but since I am also responsible for the content, there’s no possibility of confusion (I hope!).

You could build SAEFs for the client to update only the pieces that change sometimes, keeping them away from the back-end and the possibility of messing things up.

Or, if that isn’t possible, you’ll need to be very clear about how the information is organized and updated and what not to do—such as not adding new entries and expect them to show up automatically.

Thanks Kernon,

I’m into the site build fairly deeply at the moment, so I’m sticking with the “one channel per page” approach now, but I think that for my next project I’ll use the “a channel or two for static content” approach you mention above. Have you ever tried using the Pages module? If so, do you have any thoughts about it?

Also, I don’t know if I’ll go the SAEF route, as I doubt I could quickly make something which looks as nice as the EE2 backend for my clients to use. On of the reasons I’m using EE2 in the first place is because this project requires a PHP CMS, and it has a crazy turn-around time. I’m usually used to working with Django, and find that EE2 is as close as I can find to the Django admin app in terms of flexibility + ease of use (after having using Drupal, WordPress, Symphony, and having built a few PHP CMSs on CodeIgniter).

I’m into the site build fairly deeply at the moment, so I’m sticking with the “one channel per page” approach now, but I think that for my next project I’ll use the “a channel or two for static content” approach you mention above.

Ok, I went back on what I said here. A bunch of new pages needed to be added to the site, and the number of channels was ballooning like crazy. Each of these pages is just one or two paragraphs followed by some content pulled in from another Channel based on Categories. Because of this, I decided just to push the “static” content over to a “Static Pages” channel as was suggested above. This makes the Publish drop-down a lot more clean looking.

Gavin - as you’ve found creating many Channels isn’t always viable!

For added reference, for what you’d call “static” pages I’d first look at the content and create Channels by theme or topic. On a typical site I might have 2 Channels, one for “About pages” and another for “Legal pages”, I can then add entries to each of those Channels and serve them up as required.

Gavin - as you’ve found creating many Channels isn’t always viable!

Hi bluedreamer,

Yeah, agreed, but this was the advice I was given by Michael Boyink’s book, “Building an Expressionengine 2 Site”, as I mentioned above.

For added reference, for what you’d call “static” pages I’d first look at the content and create Channels by theme or topic. On a typical site I might have 2 Channels, one for “About pages” and another for “Legal pages”, I can then add entries to each of those Channels and serve them up as required.

The devision between legal and page content makes sense to me. I could imagine wanting to split things up farther in the future if it makes sense.

Thanks for the pointers!

Edit: Sorry, my first attempt at a response was snarky. I apologize. It’s 9pm here and I’m still working on a site that’s due tomorrow and which is still missing a lot of content to be provided by the client. I’m not in the best of head-spaces. Still, I should be more civil. Sorry about that.

You’re not being rude at all, it’s good to discuss topics like this, and we like to help 😊

Part of the EE learning process does make you think about content and how to best organise it within the CMS’s framework. There’s no right or wrong way, that’s part of EE’s attraction because it allows you unlimited possibilities with how you approach everything.

In my early EE days I built some sites with many Channels, and when I look back I see some areas that could have been combined into a single Channel, and others that were in a single Channel could have been better managed in different Channels. It’s all part of the learning process, typically the more you do with EE the more ways you discover of doing things.

Just to add some more ideas which may help. Imagine you have an About section on the site. It has a few general information pages, a list of staff members with profiles, and a list of all their offices around the world. For a scenario like this I’d probably set up 3 Channels, one for the About general pages, another for Staff profiles, and a third for “locations” (or whatever you wanted to call it). Why 3 Channels? Well the content on each type of page is quite different to the others so you’d probably need a different set up custom fields for each type. Does that make sense?

Part of the EE learning process does make you think about content and how to best organise it within the CMS’s framework. There’s no right or wrong way, that’s part of EE’s attraction because it allows you unlimited possibilities with how you approach everything.

Yeah, this makes sense to me. While I agree that there’s probably no “wrong way” to design an EE application, my questions are mostly based around what is easiest for end-users to administer. My background is in working with frameworks, so I’m used to designing the user-interaction part of this myself, and I’m not yet used to how EE’s UI will be accepted by someone who isn’t quick to pick up on a web interface.

Just to add some more ideas which may help. Imagine you have an About section on the site. It has a few general information pages, a list of staff members with profiles, and a list of all their offices around the world. For a scenario like this I’d probably set up 3 Channels, one for the About general pages, another for Staff profiles, and a third for “locations” (or whatever you wanted to call it). Why 3 Channels? Well the content on each type of page is quite different to the others so you’d probably need a different set up custom fields for each type. Does that make sense?

Yeah, absolutely. This is the sort of thing I’m used to building, and the Channels paradigm is why I’m attracted to EE as a CMS platform. The only point I find more difficult to do in EE than elsewhere is dealing with pages where, if it were just me editing things, all the content would be in the templates because it’s never going to change. Django handles this easily with flatpages, and less flexible systems like WordPress have pages as first-class citizens. I was tempted to try the Pages module in EE2, but was warned away by several people’s comments.

The “static” channel makes sense to me, and I don’t have much of a problem with it now that it’s set up, but I feel like it’s something clients won’t be as happy with as Django’s flatpages or WP’s pages. I think that’s what my confusion has been about so far.

Not sure if this is helpful or not (though it worked for me in some cases): if you have the “right” kind of admins, you could consider coding a special “edit” link that only shows up for them, and takes them DIRECTLY to editing the “static” content for that page.

This could help minimize the effort in finding the given “static” content in the “static” channel.  It might also help to suggest that if they want more content on that page, they need to add it to the entry as opposed to creating a whole new entry in the “static” channel.

Of course, they would need to not be bothered by the extra “edit” link, and understand that it doesn’t show up for the general public or regular members.