<ol>
<li>I would use <strong>separate</strong> Structure for each content type, instead of having them all in a single structure.</li>
</ol>

<p>Separate structures would allow cleaner 'relationships' between entries.</p>

<ol start="2">
<li>Your template structure looks good. (<em>could you explain how 'content-page.html' differs from '_entry.html'?</em>)</li>
</ol>

<p>In addition: I typically add a 'static' Section for each content type so that I can display some introduction text or imagery for a page which displays a collection of entries. e.g. </p>

<p>Sections might be:</p>

<ul>
<li>Single = "Housing Page"</li>
<li>Structure = "Housing"</li>
</ul>

<p>Templates:</p>

<p><strong>/housing/index.html</strong> would display the content from the Single AND Titles+links to each Housing entry page at:</p>

<p><strong>/housing/_entry.html</strong></p>

CC BY-SA 3.0
2016-03-09T12:44:36.713Z
Hi MattP thanks for your feedback. _entry.html purely fetches the correct template in that folder based on entry type e.g. `{% include "housing/" ~ entry.type %}`. some structures have 2 or 3 entry types (not just content-type.html), so i have a template file for each one (content-page-type1.html, content-page-type2.html and so on). I'd tried to get away from creating a 'single' related to each structure by having an 'index' at the top level of a structure, which plays the same role as the single approach you are suggesting i think (the index entry type has fields for content)
alexr
CC BY-SA 3.0
2016-03-09T13:57:26.017Z
Ah, thanks! That's an interesting approach which I've not come across before.
Matt P
CC BY-SA 3.0
2016-03-09T12:27:17.203Z
2016-03-09T12:34:10.457Z
2016-03-09T12:34:10.457Z
Matt P
<p>I'm hoping this isn't too broad or long! I have two questions. I'm trying to streamline the organisation of my site.</p>

<p>Firstly: Currently, for every section of my website (e.g. website.com/housing , website.com/skiing, website.com/guitar) i have created separate structures for each one, with an index page in it with content entries being children of that index. The index template loops through children and displays links to each page.</p>

<pre><code>Housing structure
  - index
    - entry
    - entry
</code></pre>

<p>I have seen some people saying they are putting all entries of the site in a single structure with hierarchy, e.g. one structure that has:</p>

<pre><code>- Single Structure
  - housing
    - entry
    - entry
    - entry
  - guitar
    - entry
    - entry
  - skiing
    - entry 
    - entry etc.
</code></pre>

<p>Is this a good idea? Is there any drawkbacks to the way i've done it? or is it a case of 'whatever works best for you'. It does make my Entries area of the CMS full of lots of structures, but it is clear which to access to edit which pages.</p>

<p>Second question: template organisation. In light of my separate structure approach, my templates folder has a folder in it for each structure type with an _entry that routes to the correct template based on entry type e.g.</p>

<pre><code>templates folder
  &gt; housing
    - _entry.html
    - index.html
    - content-page.html
  &gt; guitar
    - _entry.html
    - index.html
    - content-page.html
</code></pre>

<p>_entry.html in each folder has something like this:</p>

<pre><code>{% include "housing/" ~ entry.type %}
</code></pre>

<p>The index page on nearly all my structures is exactly the same, and the content page is often pretty similar (although varies slightly), so it feels like i should really point each structure to a single folder to load templates (e.g._pages/), where i'd realistically have maybe 6 or 7 templates total, as opposed to 10+ folders in /templates/ (one for guitar, one for skiing etc.). </p>

<p>I've abstracted all of the repeated logic in each structure template folder to a macro file to make it easy to manage updates to templates but is a single folder a better approach? Would i be best off still keeping a separate folder for /news/ in the templates folder? Or is it again 'what works best for you'.</p>

<p>I'd love to hear how others are doing things so i can improve my future craft builds.</p>

CC BY-SA 3.0
2016-03-09T12:21:32.843Z
Please could you explain how you use the 'content-page.html' template?
Matt P
<best-practice>
Best way to organise sections and templates
# Best way to organise sections and templates

(Asked by: username_0 on 2016-03-09)

I'm hoping this isn't too broad or long! I have two questions. I'm trying to streamline the organisation of my site.
Firstly: Currently, for every section of my website (e.g. website.com/housing , website.com/skiing, website.com/guitar) i have created separate structures for each one, with an index page in it with content entries being children of that index. The index template loops through children and displays links to each page.
Housing structure
  - index
    - entry
    - entry

I have seen some people saying they are putting all entries of the site in a single structure with hierarchy, e.g. one structure that has:
- Single Structure
  - housing
    - entry
    - entry
    - entry
  - guitar
    - entry
    - entry
  - skiing
    - entry 
    - entry etc.

Is this a good idea? Is there any drawkbacks to the way i've done it? or is it a case of 'whatever works best for you'. It does make my Entries area of the CMS full of lots of structures, but it is clear which to access to edit which pages.
Second question: template organisation. In light of my separate structure approach, my templates folder has a folder in it for each structure type with an _entry that routes to the correct template based on entry type e.g.
templates folder
  > housing
    - _entry.html
    - index.html
    - content-page.html
  > guitar
    - _entry.html
    - index.html
    - content-page.html

_entry.html in each folder has something like this:
{% include "housing/" ~ entry.type %}

The index page on nearly all my structures is exactly the same, and the content page is often pretty similar (although varies slightly), so it feels like i should really point each structure to a single folder to load templates (e.g._pages/), where i'd realistically have maybe 6 or 7 templates total, as opposed to 10+ folders in /templates/ (one for guitar, one for skiing etc.). 
I've abstracted all of the repeated logic in each structure template folder to a macro file to make it easy to manage updates to templates but is a single folder a better approach? Would i be best off still keeping a separate folder for /news/ in the templates folder? Or is it again 'what works best for you'.
I'd love to hear how others are doing things so i can improve my future craft builds.

**Tags:** best-practice
> **Comments:**
> **username_1**: Please could you explain how you use the 'content-page.html' template?  

---

## 1 answers

### Answer by username_1 on 2016-03-09. Score: 1

1. I would use **separate** Structure for each content type, instead of having them all in a single structure.

Separate structures would allow cleaner 'relationships' between entries.

2. Your template structure looks good. (*could you explain how 'content-page.html' differs from '\_entry.html'?*)

In addition: I typically add a 'static' Section for each content type so that I can display some introduction text or imagery for a page which displays a collection of entries. e.g.

Sections might be:

* Single = "Housing Page"
* Structure = "Housing"

Templates:

**/housing/index.html** would display the content from the Single AND Titles+links to each Housing entry page at:

**/housing/\_entry.html**

> **Comments:**
> **username_0**: Hi MattP thanks for your feedback. _entry.html purely fetches the correct template in that folder based on entry type e.g. `{% include "housing/" ~ entry.type %}`. some structures have 2 or 3 entry types (not just content-type.html), so i have a template file for each one (content-page-type1.html, content-page-type2.html and so on). I'd tried to get away from creating a 'single' related to each structure by having an 'index' at the top level of a structure, which plays the same role as the single approach you are suggesting i think (the index entry type has fields for content)  
> **username_1**: Ah, thanks! That's an interesting approach which I've not come across before.  

---

