Answers.Body: <p><strong>TL;DR:</strong> Let the content dictate how you model and architect it.</p>
  <hr />
  <p>If the site is sufficiently <em>small</em> or sufficiently <em>simple</em>, I think either approach is ok. My team has used both approaches, and it really depends on the Client's needs.</p>
  <p>An incomplete list of reasons to use separate channels and structures are:</p>
  <ul>
  <li>Tagging/Categorizing things like Products is probably easier to manage when they are in their own channel</li>
  <li>Your client has multiple divisions and they are managing their content separately, and thus need to control permissions</li>
  <li>You want to reference content pieces in multiple places</li>
  </ul>
  <p>An incomplete list of reasons to use a <em>Site Pages</em> approach are:</p>
  <ul>
  <li>The content isn't highly relatable, or doesn't rely much on relationships/categories/tags</li>
  <li>The site is small enough</li>
  <li>The client has demonstrated an ignorance or apathy for understanding content and &quot;just needs a site&quot;</li>
  <li>Project management constraints: fast timeline, cheap budget, or pain-in-the-ass-go-away clients.</li>
  </ul>
  <p>If you're familiar with ExpressionEngine and channels, then you probably know that things don't have to be pages to be in a channel or structure. You can combine the two approaches for a slightly sophisticated site.</p>
  <p><strong>Here's an example we have done that uses both approaches:</strong></p>
  <blockquote>
  <p>We used structures for things like <a href="http://www.cswindustrials.com/about/management" rel="noreferrer">Executive Team Bios</a> that appear on one page. The landing page is in the Site Pages structure, which supports 3 levels max, while the bios themselves are managed in a separate structure (a channel would have been fine here, but the structure allows us to order by rank without an &quot;order&quot; field). We put a <em>Management Widget</em> blockType in a Matrix/Neo field so the user can put that content where they need to. That block allows them to select &quot;Management&quot; or &quot;Board of Directors&quot;, so the block is reusable on multiple pages.</p>
  <p>This block could have easily been a nested block using Neo/SuperTable fields, but the categorization (Management/Board) is what led us to make it it's own structure. Some members belong to both groups, and without the relationship it would have required inputting and managing duplicate content.</p>
  </blockquote>
  <p>If navigation is your concern, you can use plugins like <a href="https://straightupcraft.com/craft-plugins/navee" rel="noreferrer">Navee</a> or <a href="https://straightupcraft.com/craft-plugins/a-m-navigation" rel="noreferrer">A &amp; M Navigation</a> to allow content managers to build navigations. Or on smaller sites, we just have a &quot;Navigation&quot; global field group with entries fields, and users can build out header and footer navigation as they deem appropriate.</p>
  <p>My advice is let the content dictate how you model and architect it. If you have complex content requirements, don't try to shoehorn them into a one-structure architecture. Craft's CP allows you to group channels and structures, and the <a href="https://straightupcraft.com/craft-plugins/expanded-singles" rel="noreferrer">Expanded Singles</a> plugin allows you to put singles in the entry sidebar. This can help content managers know what they are editing while allowing for more complex models. See below:</p>
  <p><a href="https://i.sstatic.net/ytFBw.jpg" rel="noreferrer"><img src="https://i.sstatic.net/ytFBw.jpg" alt="Groups in a control panel help content managers know what to edit" /></a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-14T19:47:44.900Z
Answers.Text: Many thanks for such a detailed reply Emkaytoo. I now see that some of the line breaks from my original post were lost, so I've formatted the examples of the content model I would typically use to hopefully make that clearer. So I think this approach would be the combination approach you reference i.e. one main site pages structure, with separate channels (or structures) for listings (news, events) and content with different management needs. I never meant one single structure to rule them all, seeing all content as a page, so sorry if I didn't explain that properly!
Answers.UserDisplayName: Janine
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-19T23:52:08.847Z
Answers.Text: +1 for proper information architecture baed on your content. So many people get this wrong...
Answers.UserDisplayName: RitterKnight
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-14T15:00:11.153Z
Answers.LastActivityDate: 2016-07-14T16:37:14.443Z
Answers.LastEditDate: 2020-06-17T08:56:27.903Z
Answers.UserDisplayName: Ian DeRanieri
Body: <p>I'm new to Craft CMS and I would appreciate some advice re the best approach to take for modelling content.</p>
  
  <p>I'm coming from an ExpressionEngine background, where I would typically use one pages channel for standard text pages, usually in conjuction with the Structure add-on to generate a nice site tree in the control panel where users could move page entries around between various sections as needed. </p>
  
  <p>Now in Craft, I see a Structure type and it's tempting to have one structure called Pages to act in a similar way. This would enable the main nav for the site to be dynamic using the nav tag, and users could easily move pages wherever they want site wide.</p>
  
  <p>So I would end up with the following content model:</p>
  
  <ul>
  <li>Singles: Homepage </li>
  <li>Channels: News, Events etc </li>
  <li>Structures: Pages</li>
  </ul>
  
  <p>Pages would end up as a site map excluding the homepage, with each top level entry being a site section e.g.</p>
  
  <pre><code>About
  -History
  -Team
  News (page used for news landing)
  Events (page used for events landing)
  Visit
  -Facilities
  -Opening Hours
  Contact
  etc
  </code></pre>
  
  <p>However, I see that the Happy Lager demo site takes a one structure per section approach. Also, early on in the Mijingo video series, it cautions against using one structure for most/all your site.</p>
  
  <p>I am keen to use best practice from the off, so would appreciate if you could advise whether having one master pages structure is a valid approach or why it's a bad idea.</p>
  
  <p>Many thanks</p>
  
Tags: <structure><best-practice><content><contentmodel>
Title: One structure vs a structure per section?
ThreadText: # One structure vs a structure per section?
  
  (Asked by: username_0 on 2016-07-14)
  
  I'm new to Craft CMS and I would appreciate some advice re the best approach to take for modelling content.
  
  I'm coming from an ExpressionEngine background, where I would typically use one pages channel for standard text pages, usually in conjuction with the Structure add-on to generate a nice site tree in the control panel where users could move page entries around between various sections as needed.
  
  Now in Craft, I see a Structure type and it's tempting to have one structure called Pages to act in a similar way. This would enable the main nav for the site to be dynamic using the nav tag, and users could easily move pages wherever they want site wide.
  
  So I would end up with the following content model:
  
  * Singles: Homepage
  * Channels: News, Events etc
  * Structures: Pages
  
  Pages would end up as a site map excluding the homepage, with each top level entry being a site section e.g.
  
  ```
  About
  -History
  -Team
  News (page used for news landing)
  Events (page used for events landing)
  Visit
  -Facilities
  -Opening Hours
  Contact
  etc
  
  ```
  
  However, I see that the Happy Lager demo site takes a one structure per section approach. Also, early on in the Mijingo video series, it cautions against using one structure for most/all your site.
  
  I am keen to use best practice from the off, so would appreciate if you could advise whether having one master pages structure is a valid approach or why it's a bad idea.
  
  Many thanks
  
  **Tags:** structure, best-practice, content, contentmodel
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-07-14. Score: 9 | Accepted answer
  
  **TL;DR:** Let the content dictate how you model and architect it.
  
  ---
  
  If the site is sufficiently *small* or sufficiently *simple*, I think either approach is ok. My team has used both approaches, and it really depends on the Client's needs.
  
  An incomplete list of reasons to use separate channels and structures are:
  
  * Tagging/Categorizing things like Products is probably easier to manage when they are in their own channel
  * Your client has multiple divisions and they are managing their content separately, and thus need to control permissions
  * You want to reference content pieces in multiple places
  
  An incomplete list of reasons to use a *Site Pages* approach are:
  
  * The content isn't highly relatable, or doesn't rely much on relationships/categories/tags
  * The site is small enough
  * The client has demonstrated an ignorance or apathy for understanding content and "just needs a site"
  * Project management constraints: fast timeline, cheap budget, or pain-in-the-ass-go-away clients.
  
  If you're familiar with ExpressionEngine and channels, then you probably know that things don't have to be pages to be in a channel or structure. You can combine the two approaches for a slightly sophisticated site.
  
  **Here's an example we have done that uses both approaches:**
  
  > We used structures for things like [Executive Team Bios](http://www.cswindustrials.com/about/management) that appear on one page. The landing page is in the Site Pages structure, which supports 3 levels max, while the bios themselves are managed in a separate structure (a channel would have been fine here, but the structure allows us to order by rank without an "order" field). We put a *Management Widget* blockType in a Matrix/Neo field so the user can put that content where they need to. That block allows them to select "Management" or "Board of Directors", so the block is reusable on multiple pages.
  >
  > This block could have easily been a nested block using Neo/SuperTable fields, but the categorization (Management/Board) is what led us to make it it's own structure. Some members belong to both groups, and without the relationship it would have required inputting and managing duplicate content.
  
  If navigation is your concern, you can use plugins like [Navee](https://straightupcraft.com/craft-plugins/navee) or [A & M Navigation](https://straightupcraft.com/craft-plugins/a-m-navigation) to allow content managers to build navigations. Or on smaller sites, we just have a "Navigation" global field group with entries fields, and users can build out header and footer navigation as they deem appropriate.
  
  My advice is let the content dictate how you model and architect it. If you have complex content requirements, don't try to shoehorn them into a one-structure architecture. Craft's CP allows you to group channels and structures, and the [Expanded Singles](https://straightupcraft.com/craft-plugins/expanded-singles) plugin allows you to put singles in the entry sidebar. This can help content managers know what they are editing while allowing for more complex models. See below:
  
  [![Groups in a control panel help content managers know what to edit](https://i.sstatic.net/ytFBw.jpg)](https://i.sstatic.net/ytFBw.jpg)
  
  > **Comments:**
  > **username_0**: Many thanks for such a detailed reply Emkaytoo. I now see that some of the line breaks from my original post were lost, so I've formatted the examples of the content model I would typically use to hopefully make that clearer. So I think this approach would be the combination approach you reference i.e. one main site pages structure, with separate channels (or structures) for listings (news, events) and content with different management needs. I never meant one single structure to rule them all, seeing all content as a page, so sorry if I didn't explain that properly!  
  > **username_2**: +1 for proper information architecture baed on your content. So many people get this wrong...  
  
  ---
  
  