[Discussion] FieldtypeGroup

[Youbility]

Hello everyone,

I'm currently working on my first ProcessWire project and read a lot in the forums lately. I also came across the following thread and thought about a way this could be neatly solved. However as I am new to Processwire I don't know if my proposed solution 

a) makes sense at all
b) is possible to implement
c) is an improvement over what Processwire currently offers

Therefore I would like to discuss the idea a bit and get some honest feedback.

The Problem
We have a group of input fields that belong to one part of a page. Those input fields should be visually connected so the user knows they are related to one another. Every page can (and probably will) have different values in those fields.

Example:
We have a couple of settings for a sidebar on a page. 

• show a sidebar on this page (checkbox)
• sidebar title (text)
• sidebar subtitle (text)
• some other options (for example what content should be shown) (select or checkbox)

 

The way to achieve that now
The way I see it (again, I'm new to Processwire and so sorry if I missed another option) the way to do something like that is to use a fieldset_open fieldtype or fieldset_tab_open. However that feels a bit cumbersome, at least for me. You have to choose where the fieldset should start, where it ends, don't really see it when you're adding new fields, etc. It just didn't feel as elegant as the rest of Processwire.

 

The proposed improvement [updated]
Now what I was thinking is if there could be something like a FieldtypeTemplate FieldtypeGroup. For our sidebar problem our workflow would then become:

• we create the fields we want to use, but do not assign them to a template
• next we create a field "sidebar" of our new FieldtypeGroup,  select the fields we created and add that field to our page template.

That way we could later simply add more sidebar related fields to our sidebar field and automatically all templates using the sidebar field would have the new option.
The workflow is really similar to what the repeater fields currently does, just without the actual repeating part.

 

Now I'd like to know, does the idea make sense and would it be possible to achieve with Processwires architecture?

 

Thank you for reading through
Alex

[Macrura]

I think what you are proposing might be doable now with a repeater field, somehow set to a maximum of 1 item... seem to recall this being discussed not too long ago...

i do agree that if you did have some common set of fields you wanted on a lot of templates, there could be some way of improving things to allow for it.
One example that comes to mind is that on almost all recent projects I have done, we have had a set of fields that allow users to flag pages (with stuff like statuses/issues) and these fields include around 3-4 fields that all need to be on the template and have certain conditional visibility settings common to them. I do recall that it was a pain to add those same fields to all of the templates that needed them...

[LostKobrakai]

That sounds quite like what I was proposing in the topic you linked. 

[szabesz]

4 hours ago, LostKobrakai said:

That sounds quite like what I was proposing in the topic you linked. 

Yeah, this is what we've been discussing for a while in different topics. And there have been various proposals to move forward in this area, like yours.

5 hours ago, Macrura said:

doable now with a repeater field, somehow set to a maximum of 1 item... seem to recall this being discussed not too long ago...

eg: 

 

[Youbility]

On 9.9.2016 at 6:34 AM, LostKobrakai said:

That sounds quite like what I was proposing in the topic you linked. 

Indeed, I somehow missed that the first time I read through the topic.

So the repeater field type pretty much does already what we need, and would just need some behavioral changes (pick a template, don't repeat), is that right?

Apart from that it seems the repeater field is not that popular. @tpr for example said, he would not mind getting rid of the field altogether. (https://processwire.com/talk/topic/13112-the-possibility-to-specify-a-maximum-item-limit-for-a-repeater-field/?do=findComment&comment=118691) As far as I have read that is because it does not scale so well. Would that still be a proplem if we only have a 1-to-1 mapping?

 

 

[adrian]

Repeaters have had a major overhaul since that comment by @tpr

https://processwire.com/blog/posts/processwire-3.0.4-repeaters-revisited-preview-of-profields-matrix/#major-upgrades-to-repeater-fields

https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/#repeater-upgrades-continued-in-pw-3.0.5

and there is also the new Repeater Matrix fieldtype:

https://processwire.com/blog/posts/processwire-3.0.4-repeaters-revisited-preview-of-profields-matrix/#new-profields-repeater-matrix-field

[Macrura]

Quote

So the repeater field type pretty much does already what we need, and would just need some behavioral changes (pick a template, don't repeat), is that right?

no pick a template - the repeater field itself becomes the sub-fieldgroup ('template");
you probably just need to use ACF to do some CSS and JS adjustments to disable/hide the "add new item"

[Robin S]

While we're imagining how this group field might work, my two cents is that I don't think a limited repeater is the way to go.

One likely use case for a group field is for SEO fields that would be added to nearly every template, so using a repeater-based group field would effectively double the number of pages in your site. I know that pages are designed to scale up nearly indefinitely but adding all these extra pages just seems unnecessary when there will only be one group field per page.

The way I would like to see it is that the individual fields within the group are added directly to the template like normal fields are, but they would have a property that identifies them as belonging to a group. Having such a property would allow:

1. The group field to appear in the template field list as a single item, so it's easy to move the grouped fields as one. Likewise it could be added to / removed from a template like a single field via the API.
2. The group field settings would allow adding/removing/sorting fields to the group "pseudo-template" - as per a Repeater field, but a normal PW template would not be involved.

This would require core changes of course, so would only happen if @ryan can see the value in having a group field in PW.

[szabesz]

@Robin S Of course, a dedicated solution to this problem would be welcome, however, limiting the number of repeater items has its own advantages too. A "limited repeater" can be a tool for more general issues, such as maximum number of slides in a slider, maximum number of widgets in a sidebar, etc... and in the meantime (i.e.: while we are waiting for the above described "grouped fields" ) implementing a limit for the number of repeater items seems to be a lot less work too.

13 hours ago, Macrura said:

you probably just need to use ACF to do some CSS and JS adjustments to disable/hide the "add new item"

It is a valid hack to impose a limit of one item per repeater, and we can probably extend it so that it checks the number of repeater items and removes the button when the limit is reached, but this is still more of a hack than a straightforward solution. So I'm still for a core support for "limited repeaters"

[LostKobrakai]

9 hours ago, Robin S said:

One likely use case for a group field is for SEO fields that would be added to nearly every template, so using a repeater-based group field would effectively double the number of pages in your site.

That's true, but that's really not a problem. There are people with millions of pages in their processwire installation, so even ~1000 pages for seo field won't matter and that's already a big website. Ryan did already "kinda" mark this path as the way to go as he did develop the repeater field the same way, with it also potentially holding a lot of small pages even for only 2 to 3 fields. There's just no need to introduce new systems into the core, when everything needed is already possible. 

Contrary to the raw data-model implementation the field can certainly be refined in terms of handling in the backend UI, so for example that group subfields are populated to the template fields and are kinda marked as group. But that are mostly UI conveniences. Like I said in the other wishlist topic: Nobody does need to necessarily know that those grouped fields are saved in separate pages. 

[Youbility]

I just tried the repeater solution but as you always have to add at least one item to see the input fields it's really not a solution. It's just not easy enough for the end users as they do not see the field immediately.

In my opinion we would need something that looks like the fieldset-type (maybe even with an option to show it as seperate tab instead of fieldset) and behaves like the repeater (one field, that contains several other fields). Would it in your opinion make sense to replace the FieldtypeFieldset with a new FieldtypeGroup?

 

[szabesz]

3 hours ago, Alexander Selle said:

you always have to add at least one item to see the input fields

You can also automate it by using a hooks, however, a repeater is clearly not a straightforward solution to this problem, it can be just be used as a workaround when also implementing those additional hooks.