I read somewhere that its good to use a channel for each page on your site, that way it makes it easy for the person who will ultimately be updating content to easily understand how its structured. Is that the best way? If so, I have probably 30 pages on the site I'm currently working on, and the navigation has sub-menus that lead to more pages. It seems crazy to me to have 30+ channels listed in the publish content drop-down. Can someone help me clarify the best way to structure all of this?
Not a channel per page, closer to a channel per section. If you think of pages as the final contact, like an individual post, a single product description or say a mission statement; then sections are what groups them.
A section would be what separates, all the content related to say your About Us area versus say all your organizations research, blog posts or products.
If and when creating a section or content area ( template groups) you may end up with multiple content types (templates). For example, the index page of the section may display the most recent 10 items. That acts as a 'listing' page, and that would be, but doesn't have to be, seperate from an actual full content page, like an article, staff profile, publication, etc.
Let's give a better example. Let's assume you were creating a fairly basic 'portfolio' site (you want to give people information about you and your work). You might have these sections: About, Blog, Contact, Clients.
Some About areas are a single page, some are very detailed, listing staff, projects, newsletters, etc. A staff listing may differ far enough from a project or newsletter listing, that you'd want 2 separate templates. If so, your section may end up with the following:
template_group: about templates: about/index about/staff about/post
This is one section that references a single template_group, that then has three different display options.
The index page would introduce people to the section. It could be a listing of recent items, or composed to introduce everything you consider relevant. See SnowShoe as an example. Not a site we designed, but I was just looking at it today for other purposes. It's about page, gives you the quick mission and then a listing of other items you can access—mainly staff profiles.
The staff profiles could be an overlay, like on that page, or could be separate template that specifies, picture size and placement, contact information, then the profile.
The post template, would then handle everything else— press releases, newsletters, project listings etc. Assuming that the formats are all similar (title, summary, body).
So NO you don't want 30 templates, you want to think about content areas and how people will interact with them. Then create the smallest number of templates that you need. For example, 80% of our sites are formatted with this formula:
Template Group name matches navigation section (About == about, Research == research, etc.). Each template_group starts with three templates— index, archive, article. More templates are added if needed, sometimes 'archive' is removed.
So a site with five sections— about, contact, research, blog, links, may have 10-15 templates, that serve up between 50 to a couple hundred pages of data. Creating one template per page defeats the purpose of a content management system, which is to separate content from design, and allow your templates to be reusable.
If you has 20 staff members, you wouldn't want to create 20 templates, but one template that is the staff profile and a second template that is the staff listing or directory.
I like @nonprofit_tech's answer, and I'll throw an example at you based on how I handle templating relative to channels. I too tend to create a channel per section or content area, though I specifically break it into a "pages" channel for the section and then, if needed, content-specific channels for specialized areas of content. An example will help make this approach a bit more clear. Sticking with an "about" section as an example, since I think it demonstrates this well... Let's say I have an "About" section. Within that section, I know I'm going to create a page that will list staff members, as well as link to each staff member's detailed profile. I will also include in that section a page of "locations" that will list my retail stores, again each with a details view. I often handle a setup like this as follows:
I create an "about pages" channel. I also create a channel for staff and a channel for locations. I do this because I want to create entry screens that use custom fields that are very deliberately tailored to the staff and locations info that are certainly very different from more "page-oriented" content.
My idea is that any entry in the "about pages" channel actually creates a page within the section. And so within that section's index template, I use two channel loops - one in the body area, which uses a limit of 1, and one in the sidebar with a limit of perhaps 30 (let's assume I don't expect the client to ever create more than that number of pages in the section, for example) and dynamic="no" to ensure that it displays the same way even when the URL changes.
That approach alone will allow each entry to act as a page within the section. And so the client can then easily create a page for "Staff" or "Locations" or "Our History" or "Returns Policy" - really whatever they dream up. But how do they tie the staff channel entries to the entry in the about channel that the client has created for the Staff content? The client doesn't need the ability to format the list of staff members - just to indicate that they would like that content to display on that specific "page" they created as an entry. And so I create a sub-template for the list view of the staff - all pre-formatted and ready to drop in where the client needs it.
To do this, I add a custom field to my "about pages" field group to allow the client to select which custom, section-specific subtemplate they would like displayed right after the body field content - I usually use a radio button so they can see all the options available, and i make the first one "none" (since clearly not every page entry actually needs a subtemplate to be displayed).
And so in my template, we look to see what they have selected in that field (I tend to use Switchee for this) and then if it's something other than "none", such as "staff list" or "locations list" then the sub-template is used. Since that subtemplate involves pulling content from another channel, you may need to approach this with an embed (since you can't have an entries loop inside another entries loop - though there are add-ons and techniques to get around that as well). It does require you to think ahead and plan specific options for them to select and display conditionally within the template. But I have used this approach many times now and clients really seem to like it and find it easy to use.
So then within the "about" section, like @nonprofit_tech outlined, I wind up with only a couple of templates (and a couple of "embed" templates as well for the lists appropriate to the section). The index template handles the display of all the page content, and the embedded sub-templates handle displaying the listing of staff, locations, etc), and then I need a display template for a staff person's profile, for example. So something like this:
About Template Group - index - bio (single staff profile template) - location (single location details template) - staff-list-embed (list of staff) - locations-list-embed (list of locations)
I actually tend to actually put embeds all in one "embeds" template group, but I display then here to show you that with this example, you would have only 5 templates in total needed for the about section.
Hope you find the example useful.
I don't do a channel per page, that wouldn't even make sense for many dynamic sites with the same content spanning multiple pages. I make a channel for every stream of data (a news channel, a program channel) and one channel for all the fairly static pages that I want to be editable in the CP. I then use the pages module or one of the more complex Addon's to lay out their URL structure and hierarchy on the site.