Limit page children to specific template (as page option)

[MarcinP]

Hi. I wonder if is there possibility to limit page children to specific template. I know that it can be done in template settings. But I think it could be good option to do it in page settings.

Lets say we have templates like news, gallery, author, tag, movie, song itc. We have also pages with the same names. If we want page 'Video' to accept children only with template 'video' we need to create template like 'videos-container' and set it to accept only children with template 'video'. And so on with other pages and teplates.

It ends with many 'empty' templates which role is only limitation child templates in specific pages.

If we could limit children templates in page settings it would be enough to have one template like 'common-container'.

PS: sorry for my bad english.

[LostKobrakai]

Currently there's no way to this with the core, but one could maybe write a module to implement this constraint-management. I would love to see something like this, because I do like to limit down all templates, so it's easier for the client to not break stuff.

[Macrura]

@MarcinP -

Lets say we have templates like news, gallery, author, tag, movie, song itc. We have also pages with the same names. If we want page 'Video' to accept children only with template 'video' we need to create template like 'videos-container' and set it to accept only children with template 'video'. And so on with other pages and teplates.

i don't see any problem with this, and you can always use the alternate template filename to limit the # of actual file templates you need to create...

my philosophy is that I create as many of those family type relations templates as necessary;

I don't think it really affects anything...

[rajo]

@MarcinP -

i don't see any problem with this, and you can always use the alternate template filename to limit the # of actual file templates you need to create...

my philosophy is that I create as many of those family type relations templates as necessary;

I don't think it really affects anything...

I found this thread because I was looking to solve the very same problem. It does look like a new module would be needed. The "problem" that I see is that you end up with an explosion of templates "polluting" the list, where they don't do anything else than constraining what their children can be.

colour

colours

image

images

member

members

news-item

news-items

region

regions

Double the noise, double the funk.

So, I'm with @MarcinP and I might (maybe, perchance) do something about it...

[Joss]

Templates are there to give the very functions you want - that is what their job is

[horst]

@rajo: I cannot really follow the logic. To me it looks simply wrong and the opposite is true:

a) actually we have that every parent page need:

1. 1 entry for a special parent template name at templates setup (add one entry per different parent type)
2. 1 entry for a special child template name at templates setup
3. 1 entry for storing the parent template name on the page

b) the way you want to change it would result in:

1. 1 entry for a basic parent template name at templates setup (is used by multiple parents)
2. 1 entry for a special child template name at templates setup
3. 1 entry for storing the parent template name on the page
4. +1 for storing a children template name on the page (what is very different compared to only one relation in family settings in the templates setup, or I'm wrong here?)

Conclusion:

• Both solutions may use equal amount of DB entries to specify family relations, whereas b) seem to add some more as it delegates a setting from centralized templates setup (where it is defined only one time) onto the pages layer, what multiply these entries. So, a) needs more entries for template parent names, whereas b) only needs one parent template name here. - So lets say it is equal!
   
• with a) you have a centralized and informational overview on the templates setup page, whereas with b) some informations are hidden from there and also from everywhere. You will lost the overview of your family relation settings!
   
• thats all tolerable, may be, but not: Additionaly, if you want to create a new module for something what you allready can do, you put another layer of overhead to it the process. The module needs to hook into something and check and decide and may pass back or take it into its department, etc etc etc. !!

So a) seems to be a good solution and b) seems at least to triple the noise here. Or have I got something wrong with this?

[rajo]

@horst, thank you for giving this some thought.  I'll confess I did not follow all your listing. I think you're describing what is in the DB. What I'm describing is what is the admin user interface.  I think you're concerned with the possible performance issues of injecting a module in the mix when you believe it's redundant.  And you're concerned there will be a lack of transparency in the structure if some new meta data is introduced to control the shape of the tree.

On the one hand, I like that the template collection can be very structured. It's a strength of PW. It reflects what the shape of the page tree can be.

On the other hand, when I'm creating a new site, every time I need to insert a new type of object in the tree for the users to maintain, I have to create a container as well as the actual object of interest. The container is often very generic -- its ONLY purpose is to constraint the type(s) of children under it.  Most of the time, it's a single child type (template) that is needed. When I need to modify templates, I have to exclude from my gaze the container ones.  It "looks" messy to use.

Also, when I set up a "container" for pages of a particular template, I usually don't want the user to change it. They might change the title(s), but that's about it. In those cases, a dedicated template instead of a generic one feels not "DRY".

So, after I wrote my previous  post, before reading your further thoughts, and still believing this isn't redundant, I went and built a simple module to deal with issue.  I'm going to start using it for myself. I hope some find it useful. I hope I'm not trampling on some of the principles behind PW.   I'll say it again, I think PW offers a fantastic model for building sites. Its "object tree" is brilliant in its simplicity and transparency for the user and the developer.  And yet here, I think there's a hook missing.

https://github.com/jeanrajotte/processwire_module_PageAllowedTemplate

Looking forward to feedback.  Thanks.

[Macrura]

I usually just need one template called 'option' with a title field and a container called 'option-index', also with only title. That I use for dozens of different page selects tree branches...

Do all of your templates that require containers have different fields?

[rajo]

@Macrura, yes, many do.

It's also a question of presentation for the user. I use this for lookup tables. Say a resource that is findable on the site can have:

- one of many neighbourhoods (neighbourhood have a map)

- one of many sizes (a size has a title, but also a numerical value)

- one of many amenities (no special field here, just a name).

All these (and maybe more) each have a container node on the root of the page tree, or in a sub-root like "lookups". Each container only hold a specific template, but every container is identical other than that.

[Joss]

If you want a quick way of creating loads of selectors, then try this

http://modules.processwire.com/modules/process-page-field-select-creator/

It creates the templates, the relationship and even the fields.

You might be interested in a Villa site that Ryan did with processwire that used pagefields for criteria:

http://www.villasofdistinction.com/

And if you need, you can also look at the Page Table field where you not only establish the relationships and can create new variations from the field, but those variations can be complex pages in their own right.

There is no problem in ProcessWire with using lots of templates to create familial relationships. You are not going to stuff the system and you can tie down what can be added at any fixed place.

I must have missed something, but I am struggling to work out what you need to achieve that the existing powerful system does not already do.

[rajo]

Mr. Pirate, thanks for the pointer. I didn't know about ProcessPageFieldSelectCreator. Now I do .  It could be useful to kick start a branch and to do the grunt work. It still creates two templates where (IMO) only one would have done.  And it creates a page field whether I wanted one of not.  But it's superb for a lot of purposes. Thanks.

[Martijn Geerts]

a bit related:

I use InputfieldSelectFile and then select the custom 'template' in the page. In the example below, I have a /site/templates/includes/ folder with PHP files in it. I now can select a file and use that as a template. So no need for additional templates.

$tpl = new TemplateFile($config->paths->templates . "includes/" . $page->select_file);
$tpl->set('current', $page);
$markup = $tpl->render();

echo $markup;

[MarcinP]

@Martijn Geerts: It is good solution for templates in context of HTML output. It will not work for templates considered as group of fields.

@horst: Propably you are right but my idea is not to make better performane but 'ease of use'. Limiting teplates for pages could be more efficient for developers. I think it dont have to affect core and db.

[horst]

but my answer is (meant) in regard of "ease of use" ! 

• lesser fields to type in or to select from
• centralized overview compared to no overview!
• etc.

[OLSA]

I would love to see something like this, because I do like to limit down all templates, so it's easier for the client to not break stuff.

The "problem" that I see is that you end up with an explosion of templates "polluting" the list, where they don't do anything else than constraining what their children can be.

colour

colours

image

images

member

members

news-item

news-items

region

regions

Double the noise, double the funk.

Came here with the same question.

[MarcinP]

There is new module for PW, that do exactly that what i needed - https://processwire.com/talk/topic/13381-templateschildpages/