Answers.Body: <p>I guess I'd refactor this and introduce different <a href="http://buildwithcraft.com/docs/sections-and-entries#entry-types" rel="nofollow">entry types</a> for your section. Besides being able to "lock" each entry type to a specific template (→ <a href="http://buildwithcraft.com/help/entry-type-templates" rel="nofollow">"How can I give each Entry Type its own template?"</a>), you can also have the CP fields (slightly) different. Maybe it makes sense to have extra fields for your special entries, if it doesn't, just add the same fields to each entry type. </p>
  
  <p>Another option would be to have a dropdown field to select the template, but I like that the entry type dropdown is in the right panel in the CP.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T07:34:53.343Z
Answers.Text: Yes, that would work, but then I would have to build 20 different entry types and modify each one of them when there is a change. My special templates typically don't have extra information from the entry page. Examples might be a sitemap (3 variations), all my forms, or pages that pull data from other sections (like staff profiles/job vacancies) and so on.
Answers.UserDisplayName: Jack McKenzie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T07:48:24.237Z
Answers.Text: Don't you need extra fields to make those relations to the other sections? I think you could make those entry types more universally, so that you don't need 20. Or combine this with the `entry.slug` solution I just posted as another answer.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T08:50:04.017Z
Answers.Text: I haven't used extra fields for the relations - everything is done in the templates. I'd need a one to one match of entry type to template to make that work wouldn't I?
Answers.UserDisplayName: Jack McKenzie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T09:10:12.793Z
Answers.Text: You could load different template partials for each entry type with any Twig logic. Compare against field values, or common entry properties (ID, slug, dates, ...).
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T07:20:24.213Z
Answers.LastActivityDate: 2015-05-20T07:20:24.213Z
Answers.UserDisplayName: carlcs
Answers.Body: <p>There are obviously many ways to skin this cat. Thanks to those that offered answers. The one that I think works the best for me is the <a href="https://straightupcraft.com/craft-plugins/template-select" rel="nofollow">Template Select plugin</a>. The added advantage is that when the special template is used more than once I won't have to go and edit the template code to call it for that entry. </p>
  
  <p>The only thing I had to work my around was the plugin help that said</p>
  
  <blockquote>
    <p>In general.php, add this line:</p>
    
    <p><code>'templateselectSubfolder' =&gt; 'subfolder'</code></p>
  </blockquote>
  
  <p>whereas to make it work I had to add a trailing slash</p>
  
  <pre><code>'templateselectSubfolder' =&gt; 'subfolder/'
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T09:44:27.753Z
Answers.LastActivityDate: 2015-05-20T09:44:27.753Z
Answers.UserDisplayName: Jack McKenzie
Answers.Body: <p>The entries' IDs or slugs doesn't change, so you could compare against that to include your partials dynamically.</p>
  
  <pre><code>{% set specialPages = ['sitemap', 'contact-form', ...] %}
  
  {% if entry.slug in specialPages %}
      {% include '_partials/' ~ entry.slug %}
  {% endif %}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T08:32:09.050Z
Answers.Text: This is a good approach, though I'd consider using the [Template Select plugin](https://straightupcraft.com/craft-plugins/template-select) instead of hard coding the slugs in Twig.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T08:48:14.593Z
Answers.Text: Hmmm - I like this approach - I think it might do what I want, if I can find a way to deal with potential duplicate slugs (it happens). Thanks, I'll give it a go! I'll also check out the plugin.
Answers.UserDisplayName: Jack McKenzie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T08:56:36.277Z
Answers.Text: With the plugin duplicate slugs wouldn't be an issue.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T09:01:31.597Z
Answers.Text: Or just use the entries' IDs. Any field (default or from a plugin) can only be added to the main panel, where I probably wouldn't want it to be. That's why I'd actually recommend the entry types approach. Probably not more of a hassle to set up that this templates plugin, @mmikkel.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T09:32:03.100Z
Answers.Text: Yeah using entry types would be best. Maintaining an array of slugs or ids in a template could get unwieldy though. As for the template select field, I'd probably chuck that in a separate "Settings" tab or something :)
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T09:36:49.703Z
Answers.Text: @mmikkel yes, a separate tab would do. Oh and I just had a look at that Templates Select plugin and noticed I was wrong, there isn't any setup necessary at all! I thought you had to add each template individually. Want to add a quick answer for that approach?
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-20T07:46:03.083Z
Answers.LastActivityDate: 2015-05-20T07:57:47.970Z
Answers.LastEditDate: 2015-05-20T07:57:47.970Z
Answers.UserDisplayName: carlcs
Body: <p>I have site with a few hundred entries in a structure section. About 95% of these pages use the same template, with the remainder (about 20 pages) needing a special template. I manage this the following way:</p>
  
  <p>The section (main) has a template called _entry.html which consists only of the following:</p>
  
  <pre><code>{% extends [entry.uri, "main/_main"] %}
  </code></pre>
  
  <p>I then match the uri in the templates folder and that template also extends main/_main with a block override to deal with the special case.</p>
  
  <p>All of this works very well until the content editor moves the special entry in the structure, and then of course it loses its template and goes back to the default.</p>
  
  <p>Is there way I can "lock" an entry to a specific template (which still inherits) so that when the entry is moved in the structure it does not "disconnect".</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-20T07:16:24.630Z
Comments.Text: I didn't get what you mean with matching the URI in the templates folder, is there a static array of URIs in your template that you match it against? Not really dynamic this is, if that's how you do it.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-20T07:31:38.060Z
Comments.Text: I mean that if the path of the entry is /about/history, then if there is a template at /about/history.html or /about/history/index.html then it uses that instead.
Comments.UserDisplayName: Jack McKenzie
Tags: <templating>
Title: Permanently connecting templates to entries
ThreadText: # Permanently connecting templates to entries
  
  (Asked by: username_0 on 2015-05-20)
  
  I have site with a few hundred entries in a structure section. About 95% of these pages use the same template, with the remainder (about 20 pages) needing a special template. I manage this the following way:
  
  The section (main) has a template called \_entry.html which consists only of the following:
  
  ```
  {% extends [entry.uri, "main/_main"] %}
  
  ```
  
  I then match the uri in the templates folder and that template also extends main/\_main with a block override to deal with the special case.
  
  All of this works very well until the content editor moves the special entry in the structure, and then of course it loses its template and goes back to the default.
  
  Is there way I can "lock" an entry to a specific template (which still inherits) so that when the entry is moved in the structure it does not "disconnect".
  
  **Tags:** templating
  
  > **Comments:**
  > **username_1**: I didn't get what you mean with matching the URI in the templates folder, is there a static array of URIs in your template that you match it against? Not really dynamic this is, if that's how you do it.  
  > **username_0**: I mean that if the path of the entry is /about/history, then if there is a template at /about/history.html or /about/history/index.html then it uses that instead.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2015-05-20. Score: 4
  
  I guess I'd refactor this and introduce different [entry types](http://buildwithcraft.com/docs/sections-and-entries#entry-types) for your section. Besides being able to "lock" each entry type to a specific template (→ ["How can I give each Entry Type its own template?"](http://buildwithcraft.com/help/entry-type-templates)), you can also have the CP fields (slightly) different. Maybe it makes sense to have extra fields for your special entries, if it doesn't, just add the same fields to each entry type.
  
  Another option would be to have a dropdown field to select the template, but I like that the entry type dropdown is in the right panel in the CP.
  
  > **Comments:**
  > **username_0**: Yes, that would work, but then I would have to build 20 different entry types and modify each one of them when there is a change. My special templates typically don't have extra information from the entry page. Examples might be a sitemap (3 variations), all my forms, or pages that pull data from other sections (like staff profiles/job vacancies) and so on.  
  > **username_1**: Don't you need extra fields to make those relations to the other sections? I think you could make those entry types more universally, so that you don't need 20. Or combine this with the `entry.slug` solution I just posted as another answer.  
  > **username_0**: I haven't used extra fields for the relations - everything is done in the templates. I'd need a one to one match of entry type to template to make that work wouldn't I?  
  > **username_1**: You could load different template partials for each entry type with any Twig logic. Compare against field values, or common entry properties (ID, slug, dates, ...).  
  
  ---
  
  ### Answer by username_0 on 2015-05-20. Score: 3
  
  There are obviously many ways to skin this cat. Thanks to those that offered answers. The one that I think works the best for me is the [Template Select plugin](https://straightupcraft.com/craft-plugins/template-select). The added advantage is that when the special template is used more than once I won't have to go and edit the template code to call it for that entry.
  
  The only thing I had to work my around was the plugin help that said
  
  > In general.php, add this line:
  >
  > `'templateselectSubfolder' => 'subfolder'`
  
  whereas to make it work I had to add a trailing slash
  
  ```
  'templateselectSubfolder' => 'subfolder/'
  
  ```
  
  
  ---
  
  ### Answer by username_1 on 2015-05-20. Score: 3
  
  The entries' IDs or slugs doesn't change, so you could compare against that to include your partials dynamically.
  
  ```
  {% set specialPages = ['sitemap', 'contact-form', ...] %}
  
  {% if entry.slug in specialPages %}
      {% include '_partials/' ~ entry.slug %}
  {% endif %}
  
  ```
  
  > **Comments:**
  > **username_2**: This is a good approach, though I'd consider using the [Template Select plugin](https://straightupcraft.com/craft-plugins/template-select) instead of hard coding the slugs in Twig.  
  > **username_0**: Hmmm - I like this approach - I think it might do what I want, if I can find a way to deal with potential duplicate slugs (it happens). Thanks, I'll give it a go! I'll also check out the plugin.  
  > **username_2**: With the plugin duplicate slugs wouldn't be an issue.  
  > **username_1**: Or just use the entries' IDs. Any field (default or from a plugin) can only be added to the main panel, where I probably wouldn't want it to be. That's why I'd actually recommend the entry types approach. Probably not more of a hassle to set up that this templates plugin, @mmikkel.  
  > **username_2**: Yeah using entry types would be best. Maintaining an array of slugs or ids in a template could get unwieldy though. As for the template select field, I'd probably chuck that in a separate "Settings" tab or something :)  
  > **username_1**: @mmikkel yes, a separate tab would do. Oh and I just had a look at that Templates Select plugin and noticed I was wrong, there isn't any setup necessary at all! I thought you had to add each template individually. Want to add a quick answer for that approach?  
  
  ---
  
  