Strategy for flexible content types in a template

[jordanlev]

Is there a way to achieve a situation where my users who are editing a site can choose between different sets of fields that they will place in a certain spot in a page?

My understanding of how ProcessWire works is that the developer creates fields and then assigns fields to a page type, then the user can log into the dashboard, create a page of that page type, then edit the content of those fields that were defined by the developer. But instead what I would like is to be able to designate an area of the template in which users have a choice of fields they want to add (actually, what I really want is for the user to be able to choose a SET of fields that I have defined and grouped together as the developer).

What I am trying to recreate here is an amazing feature of the Concrete5 CMS (which I have been using successfully for many years now) where you don't define the types of fields that must be placed in a specific spot on the page, but instead define "areas" that the user can then choose which fields (actually, a set of fields, which C5 calls "blocks") to place in that area. These areas are "repeatable" in a sense because the user can add as many or as few of these blocks as they want.

The primary use case for this is the main content area of most pages -- I don't just want one WYSIWYG editor the whole section, but instead I want the user to be able to choose that they want perhaps a WYSIWYG editor, an image or two, a video, etc.

I came across this old thread in the forums which seems to be asking a similar thing: https://processwire.com/talk/topic/3264-selectable-layouts-within-a-repeater/ -- perhaps that will help explain my question even more.

Thanks for your thoughts.

   -Jordan

[adrian]

There is a new field type (PageTable) in the dev version of PW which will be released as 2.5 probably in the next week or two.

There isn't much documentation on it yet, but there is already a cool extended version of it that will help you to visualize how it can work for exactly the scenario you are talking about:

https://processwire.com/talk/topic/7459-module-pagetableextended/

[totoff]

Contao CMS has a similiar approach but as far as I know this is not possible with PW.

[renobird]

There are a few ways to do this.

Option 1 (Field Dependencies in Repeaters)

The dependencies are limited to field=value, and you need to be sure to change this config option.
Create a page field (select) with all the "block" types you want. Create fields for each of those block types and add them to the repeater.

(Example: Text, Image(s), File(s), Video, etc…) This method works, but it can be a little clunky from a UX perspective. I'm mostly mentioning it for reference, option 2 below is really much cleaner.

Option 2 (PageTable or PageTable Extended)

As Adrian mentioned, PageTable will be available in 2.5 (available now on the dev branch). The extended version that Marc (MadeMyDay) released is amazing, and sounds like a perfect fit for what you need. The benefit of this method, is that each block type can have as many fields as you need. You can create complex layouts (even within each block) without the user attempting to size/position things in a WYSIWYG.

[bernhard]

hi jordan and welcome to the forum, i really liked your posts so far and had a look at concrete5

there is an old thread with lots of thoughts on this problem. i'm linking to the last post, as the core has new features for that: https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=63924

but maybe you find all the older posts interesting as well.

[jordanlev]

Thanks everyone for your responses. It looks like the PageTable Extended feature might be the solution I'm looking for. I'll try it out when 2.5 is officially released soon.

[Peter Knight]

Sounds like something I've seen recently in Craft ( entry types ).

http://buildwithcraft.com/docs/sections-and-entries#entry-types

Good to know PW is up to the job too.

[Martijn Geerts]

I'll try it out when 2.5 is officially released soon.

I'm using the DEV now for 4 or 5 months and didn't experienced any major bugs that prevent me from using it. You could start using DEV now I think. 

[bernhard]

I'm also using dev with no troubles! you can get it here: https://github.com/ryancramerdesign/ProcessWire/tree/dev

there's also a link on the download page, intentionally not very prominent

[renobird]

For posterity, and in case anyone missed it:

https://processwire.com/talk/topic/7459-module-pagetableextended/?p=72035

[jordanlev]

I had some time this weekend to install the dev branch. Unfortunately I could not get things to work as expected. Primarily, I was unable to find the PageTable field. Doesn't seem to be installed by default, and cannot find it on the processwire.com modules page. I did find the PageTableExtended module, but installing that led to a php error about not being able to find the PageTable field module.

Not a big deal, I'm sure this will all get sorted out by the time 2.5 is officially released, but this is why I generally try to wait for official releases before learning about a new system that I'm not already familiar with

[adrian]

PageTable is in the core already - you just need to go to Modules > Core and scroll down to PageTable and install. Then it will appear from the list when creating a new field.

[jordanlev]

Derp... I forgot to checkout the dev branch after I cloned the repo. Will try again, thanks!

[jordanlev]

Okay, I've got the PageTableExtended fieldtype installed and working. I see a few things that make this not an ideal solution, although perhaps I need to configure it differently?

1) Every new "layout element" that is added to the PageTable field creates a new page in the sitemap. For my purposes, this is not ideal for several reasons:

 a) I don't want these "layout elements" to be accessible via a url... they are only intended to be a portion of content on the page I'm adding the field to

 b) The sitemap gets littered with these pages which are not really pages (well, I don't want the users to see them as pages, even if technically they are pages under-the-hood)

 c) The user is required to enter a title and url slug when adding them, which doesn't make sense in this context (because as far as the user is concerned, they're just adding content to a page, not creating new pages)

2) I want to create new templates for each of the "block types" that users can add as layout elements, but I do not want those templates to be choosable when they add new pages to the site. I *only* want them to be choosable in the context of this PageTable field. If I set the template to not be choosable for new pages, then they are unable to add them to the PageTable.

Any thoughts on if it's possible to overcome these issues using this technique?

Thanks!

[adrian]

1)

   a) I think the best approach is to store all the content pages under one hidden parent using the Details > Select a Parent for Items

   b) Not really an issue if you do a) 

   c) Make use of Input > Automatic Page Name Format, and then go to the template context settings for the title field and make it invisible and not required.

2) This can be handled by setting the allowed parents for these content block templates.

Hope that helps.

[jordanlev]

Thanks for the ideas, sounds promising. I'm unfortunately having trouble figuring out what you mean for 1c: "make use of Input > Automatic Page Name Format, and then go to the template context settings for the title field and make it invisible and not required". I am unable to find "Input > Automatic Page Name" setting anywhere. Is this something I need to install first? Is it a setting on the field? Or on the PageTable field? Or on the template? Or something else entirely?

[adrian]

It's on the Input tab of the PageTable field. I usually just name it contentblock or something along those lines and each new page that is created with have -n appended to it, e.g.: content block-1, contentblock-2, etc

[jordanlev]

Thanks for all your help. I am slowly making my way here.

My next problem is that I do not necessarily want a "title" field on these templates. I am unable to remove the "title" field from the template though because it appears that they system requires it on every template. How can I override this requirement so that I can remove the title field from some of these templates? Or if that's not possible, can I hide it from the user who is editing content and automatically populate it in the same way I'm auto-populating "page name" (url slug)?

Other little things I'd like to polish up are:

* hide the "Settings" tab when editing the fields

* hide the "Save + Keep Unpublished" button when adding a new layout element (and change the existing "Publish" button to just say "Save", like what you see when editing it after it has already been published)

Last but not least, does anyone know how compatible the PageTableExtended fieldtype is with the Fredi module? Should it "just work", or would modifications need to be made to one or the other?

Thanks again!

   -Jordan

[adrian]

My next problem is that I do not necessarily want a "title" field on these templates. I am unable to remove the "title" field from the template though because it appears that they system requires it on every template. How can I override this requirement so that I can remove the title field from some of these templates? Or if that's not possible, can I hide it from the user who is editing content and automatically populate it in the same way I'm auto-populating "page name" (url slug)?

No need to remove it from the template, just make it hidden and not required in the context of that template. I don't think there is really any need to populate it all in this case, but it would be possible via a hook if you really want to.

You could also remove the global flag for title so it is not in the template at all, but I think the former approach is better.

[jordanlev]

Ah, thank you. I didn't notice I could change settings on individual fields. That is perfect!

I also found the "Don't Allow Unpublished Pages" setting which cleans up the buttons like I wanted.

So the only thing left for achieving my ultimate vision here is somehow hiding the "Settings" tab (and ideally just hiding both tabs altogether... because if the user is only going to see the "Content" panel then there is no need to show the "Content" tab control at the top, because there should not be anything else available to switch to). Thoughts?

Thanks again (and again)... the helpfulness of this community is really great

[adrian]

So the only thing left for achieving my ultimate vision here is somehow hiding the "Settings" tab

Check out this helper module from Soma:

https://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/?p=31126

[jordanlev]

That gets me halfway there... that module only hides one of the settings under the "Settings" tab. I'd like to hide that tab altogether. I see that there is actually a template option called "noSettings" that is set on the user, role, and permissions templates. But this "noSettings" option does not appear to be exposed via the admin UI. Do you know how I could have a module that sets this on a per-template basis? Or do I just need to update the database manually to add this to the array of options in the "data" field of the "templates" table?

[bipster]

Where can I change settings on individual fields? I've checked all admin menus, with no success.

[jordanlev]

@Newbie, click on the field name to edit its settings (see attached screenshot). It took me a while to figure out too

[bipster]

Thanks jordanlev!