Answers.Body: <p>I would like to offer another solution: We always  have a structured section <code>pages</code> where our clients can insert all the pages they want to show. It's a structured section because the menu is generated by this structure and they have certain options in these entries if they should appear in the menu/footermenu and so on.</p>
  
  <p>Different Entry Types in this section have different templates, sometimes when it's required we create special field types to choose different templates as well. When the client wants to insert an "overview" page to display <code>news</code> he/she creates a new entry in our <code>pages</code> section with the entry type <code>news</code> that has a special template that fetches all latest entries in the <code>news</code> section and renders them. </p>
  
  <p>That way we don't need to create a special rule and we don't need to create a single page -> thus we don't need to offer a special menu plugin. From the feedback we got from our clients they prefer this method because they have everything they need in this structured section and they don't need to create a separate menu or something like that. Dragging/moving these entries causes the menu to change and due to Craft it's very intuitive. </p>
  
  <p>When it's required, we restrict the number of times certain entry types can be used. For example we only need one <code>news</code> overview or one <code>login</code> page. It does not make sense to create 3-4 different login pages so as soon as our client selects this entry type it disappears from the list and he/she can only create another <code>login</code> page after the first was deleted.</p>
  
  <p>If you are interested: this is our default template for entries in the <code>pages</code> section</p>
  
  <pre><code>{% extends [
      'pages/_custom/' ~ entry.slug ~ '.twig',
      'pages/_entrytypes/' ~ entry.type ~ '.twig',
      'pages/_generic.twig'
  ] %}
  </code></pre>
  
  <p>Craft/Twig takes the first template that is found. <code>_generic</code> is the default content template</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T09:54:04.337Z
Answers.Text: Thanks robin. I really like this approach and it is great to have the direct feedback from clients - singles don't often make much sense to them.I think the content if it is specific, eg  a publication,  sometimes sit better in the admin panel as 'add a publication' as opposed to a page. I guess trading entry types for specific content types makes sense when the content is highly differentiated. But as you say building navigation fits into the page/entry type philosophy very well.
Answers.UserDisplayName: joomkit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T10:06:16.280Z
Answers.Text: Yes I would create a section `publications` so clients can insert all their different `publications` and for the "index" page where users can filter/search publications I would create an entry in our `pages` section and create a new entry type for that. That's the purpose of different entry types from the beginning. The concept of singles is sometimes hard to understand and clients need to have a "menu plugin" in order to move these singles in the page navigation. Thus they'll have more work because they need to create an entry and then once again in the menu tree
Answers.UserDisplayName: Robin Schambach
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T10:12:51.230Z
Answers.Text: ON the default template above how does the generic template ever get loaded? Doesn't everything have an entry type and therefore get loaded before generic?
Answers.UserDisplayName: joomkit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T10:15:52.010Z
Answers.Text: When we don't have the specific twig file. Let's say we have an entry with the type `foo` but no `pages/_entrytypes/foo.twig` then the generic will be loaded
Answers.UserDisplayName: Robin Schambach
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T10:17:08.280Z
Answers.Text: DOH! of course. I am just in the middle of a build and think i might change to this method now. Thanks. DO you ever end up with too many entry types?
Answers.UserDisplayName: joomkit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T10:22:28.590Z
Answers.Text: Not really because we restrict the limit how often one can be used. So let's say we have 15 different entry types (for very huge multisite systems) our clients can usually see only 5-6 of them because there is no need to create multiple `login` or `registration` entries. So there are only a few of them in the entry type select and not all
Answers.UserDisplayName: Robin Schambach
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-01T08:47:56.273Z
Answers.LastActivityDate: 2018-03-01T08:55:15.420Z
Answers.LastEditDate: 2018-03-01T08:55:15.420Z
Answers.UserDisplayName: Robin Schambach
Body: <p>Most websites have three distinct types of page.
  List of items
  Item
  Special layout of items / content</p>
  
  <p>A list of entries require a list view. Craft lets us do this with singles - eg blog index page. But we can also just use a template and custom route.</p>
  
  <p>What are the pros and cons of each?
  The pros of single index style pages is that I can then build a navigation structure that has an entry link to the single.  Beyond that are there any other reasons why one over the other? </p>
  
Tags: <routes><navigation><singles>
Title: Singles or routes solution
ThreadText: # Singles or routes solution
  
  (Asked by: username_0 on 2018-02-28)
  
  Most websites have three distinct types of page.
  List of items
  Item
  Special layout of items / content
  
  A list of entries require a list view. Craft lets us do this with singles - eg blog index page. But we can also just use a template and custom route.
  
  What are the pros and cons of each?
  The pros of single index style pages is that I can then build a navigation structure that has an entry link to the single. Beyond that are there any other reasons why one over the other?
  
  **Tags:** routes, navigation, singles
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-03-01. Score: 2 | Accepted answer
  
  I would like to offer another solution: We always have a structured section `pages` where our clients can insert all the pages they want to show. It's a structured section because the menu is generated by this structure and they have certain options in these entries if they should appear in the menu/footermenu and so on.
  
  Different Entry Types in this section have different templates, sometimes when it's required we create special field types to choose different templates as well. When the client wants to insert an "overview" page to display `news` he/she creates a new entry in our `pages` section with the entry type `news` that has a special template that fetches all latest entries in the `news` section and renders them.
  
  That way we don't need to create a special rule and we don't need to create a single page -> thus we don't need to offer a special menu plugin. From the feedback we got from our clients they prefer this method because they have everything they need in this structured section and they don't need to create a separate menu or something like that. Dragging/moving these entries causes the menu to change and due to Craft it's very intuitive.
  
  When it's required, we restrict the number of times certain entry types can be used. For example we only need one `news` overview or one `login` page. It does not make sense to create 3-4 different login pages so as soon as our client selects this entry type it disappears from the list and he/she can only create another `login` page after the first was deleted.
  
  If you are interested: this is our default template for entries in the `pages` section
  
  ```
  {% extends [
      'pages/_custom/' ~ entry.slug ~ '.twig',
      'pages/_entrytypes/' ~ entry.type ~ '.twig',
      'pages/_generic.twig'
  ] %}
  
  ```
  
  Craft/Twig takes the first template that is found. `_generic` is the default content template
  
  > **Comments:**
  > **username_0**: Thanks username_1. I really like this approach and it is great to have the direct feedback from clients - singles don't often make much sense to them.I think the content if it is specific, eg  a publication,  sometimes sit better in the admin panel as 'add a publication' as opposed to a page. I guess trading entry types for specific content types makes sense when the content is highly differentiated. But as you say building navigation fits into the page/entry type philosophy very well.  
  > **username_1**: Yes I would create a section `publications` so clients can insert all their different `publications` and for the "index" page where users can filter/search publications I would create an entry in our `pages` section and create a new entry type for that. That's the purpose of different entry types from the beginning. The concept of singles is sometimes hard to understand and clients need to have a "menu plugin" in order to move these singles in the page navigation. Thus they'll have more work because they need to create an entry and then once again in the menu tree  
  > **username_0**: ON the default template above how does the generic template ever get loaded? Doesn't everything have an entry type and therefore get loaded before generic?  
  > **username_1**: When we don't have the specific twig file. Let's say we have an entry with the type `foo` but no `pages/_entrytypes/foo.twig` then the generic will be loaded  
  > **username_0**: DOH! of course. I am just in the middle of a build and think i might change to this method now. Thanks. DO you ever end up with too many entry types?  
  > **username_1**: Not really because we restrict the limit how often one can be used. So let's say we have 15 different entry types (for very huge multisite systems) our clients can usually see only 5-6 of them because there is no need to create multiple `login` or `registration` entries. So there are only a few of them in the entry type select and not all  
  
  ---
  
  