1

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".

Improve this question
2
  • 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.
    – carlcs
    Commented May 20, 2015 at 7:16
  • 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.
    – Jack McKenzie
    Commented May 20, 2015 at 7:31

3 Answers 3

Reset to default
4

I guess I'd refactor this and introduce different 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?"), 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.

Improve this answer
4
  • 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.
    – Jack McKenzie
    Commented May 20, 2015 at 7:34
  • 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.
    – carlcs
    Commented May 20, 2015 at 7:48
  • 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?
    – Jack McKenzie
    Commented May 20, 2015 at 8:50
  • 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, ...).
    – carlcs
    Commented May 20, 2015 at 9:10
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 %}
Improve this answer
6
  • This is a good approach, though I'd consider using the Template Select plugin instead of hard coding the slugs in Twig.
    – Mats Mikkel Rummelhoff
    Commented May 20, 2015 at 8:32
  • 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.
    – Jack McKenzie
    Commented May 20, 2015 at 8:48
  • With the plugin duplicate slugs wouldn't be an issue.
    – Mats Mikkel Rummelhoff
    Commented May 20, 2015 at 8:56
  • 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.
    – carlcs
    Commented May 20, 2015 at 9:01
  • 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 :)
    – Mats Mikkel Rummelhoff
    Commented May 20, 2015 at 9:32
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. 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/'
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.