Wishlist: Group field for grouping fields

[steveooo]

Hello,

One thing that I really would like is a group fieldtype. This group fieldtype is just for grouping other fieldtypes. E.g.:

"dates" as group field has "dateStart" and "dateEnd" (both datetime fieldtype) as fields.

This would be a great feature!

Is something like this currently possible?

[cstevensjr]

I may not completely understand your requirements, however I believe you are maybe talking about the existing Fieldsetopen fieldtype.

https://processwire.com/talk/topic/176-fieldsetopen-fieldsettabopen-%E2%80%93-what-is-it/

[steveooo]

As I understand this, the Fieldsetopen field is only for grouping for entering content via backend. I am looking for a field that internally groups multiple fields. Like how you add fields to a repeater field, but without the repeating stuff

[SteveB]

You should look at the TextAreas in the ProFields ($) package. The catch is that all the grouped fields are the same type but datetime is one of the 20 or so types available. Very handy.

[horst]

Or do you mean Repeater? Here you can group (via Template) fields together and use them multiple times in one page.

[Juergen]

I can remember that this kind of field is also included in SEBLOD (Joomla) that I had used in earlier days. It was always a big easement because you had only to include one field which contains several other fields (fe. introtext, main article image and main text).

[LostKobrakai]

One could create a Fieldtype, which does kinda link to a set of fields, so one could use $page->group->name, while technically $page->name would also work. Is that what you're looking for? 

[steveooo]

Well. Not really. It would be nice for grouping multiple fields inside one, so I simply can embed 1 field on a template and not have to include multiple fields (via fieldset)... If your project is big and complex, it would be good to group them like told. 1 example of how this would simplify stuff:

You could create a field called "seo" and inside this seo field, you have all that seo-specific stuff like description, image, opengraph,... and then you only need to set this field to global and voila: SEO fields for every field!

[LostKobrakai]

That's just not how processwire does work. Templates do each have a dedicated fieldgroup. This fieldgroup can just hold fields and not groups. One could build a system around that, which does automatically update the fieldgroups of selected templates, but Ryan didn't seems to consider – in other topics about the same request – adding the ability to add groups as equal members of a template as fields. It just doesn't work that way in the internals. 

[kongondo]

Couldn't Profields Table accomplish this?

[LostKobrakai]

Table is for multiple instances of a group of fields, likewise are pagetables and repeaters. There's currently no fieldtype, which groups fields for only a single instance. Maybe a single-page field could be considered that, but I doubt people being pleased with that solution.

[bernhard]

basically i support this request. i've come across this problem several times and wished there was a better solution. it was also requested here: https://processwire.com/talk/topic/7347-grouping-fields-within-admin/ (and maybe more often...)

i think there are several cases where this could be very useful: SEO is one example, facebook could be another one:

assume you build a catalog of different content types (boat, car, tshirt, whatsoever...). all those content types are different templates and need different fields. ok, now what if you want to add some kind of facebook share info to each product? you need fields like "ogimage, ogtitle, ogdescription" and you would have to add those fields to EVERY template... the actions tab makes it a little bit easier for you, but if you want to put all of them in a fieldset you have to click around A LOT

you could put everything in one template and do some showif things, but that would lack access control and some other stuff (for example if you want edit access for user A only for products X, Y, Z and B for 1, 2, X)

what if facebook decides to add a new tag "fancynewtag"? you would have to do everything again. i think in such cases it would really be great to have kind of fieldgroups that you can add to your templates like single fields and that reflect such kind of "global" updates. now it would be as easy as:

• create field "newfancytag"
• add this field to your fieldgroup "ogtags"
• all your templates are updated automaticalle (in other words: are not changed, but the fields appear in the processpageedit interface)

hmmm... an idea coming to my mind: could this somehow be accomplished with the runtimemarkup fieldtype? similar to this: https://processwire.com/talk/topic/10804-module-runtimemarkup-fieldtype-inputfield/?p=114190

@steveooo

did i understand you correctly?

[LostKobrakai]

I can surely see the need / desire for such a feature, but conceptually groups aren't really the way to handle this in ProcessWire. We already have a way to group fields and have access control on them and stuff. They are called templates. To accomplish what you're asking for I'd rather suggest we need a page field, which would act kinda like a repeater and (automatically) create a new page with one-to-one mapping to the current. And it would need to simply add fields to the page edit UI like the repeater does, but without the actual repeating part. Just the "repeater-like" setup should be changed to be handled like it's done for pagetables by using "real" templates.

This way all existing tools/workflows and core handling can stay the same, but things like seo fields can still be shared with different pages.

[szabesz]

...but things like seo fields can still be shared with different pages.

We currently have the option to designate a field to be "Global". It might be possible to introduce the "not so global" option, meaning the filed to be configurable in the Template settings to be "disabled/not used". This might get a bit convoluted, but if we could somehow get an overview of what is actually used and where, it might work.

[bernhard]

for reference: adrian's template setup batcher can save you time

[adrian]

for reference: adrian's template setup batcher can save you time

https://processwire.com/talk/topic/8406-set-multiple-templates-role-access/?p=81711

[bernhard]

oops, forgot the link thank you

[swissdoode]

Although this thread is somewhat «old», I'll add my two cents here from my experience as a new user:

Following a short tutorial that taught how to add Meta-Tags for every page, I found two things: how to make a FieldsetTab and now to make fields global. 
To my surprise, I was able to make the fields global, but not the FieldsetTab. 
Which results in one template having a nice Tab grouping the Meta-Tag fields together and on all other pages they just linger around somewhere.
This ain't a dealbreaker, but it surely isn't very handy either. All the suggested workarounds in this thread are just that: workarounds.
I totally agree with bernhard and his usecases that such a functionality would be great to have and in some circumstances is even a necessity.
And no, the template setup batcher isn't really an option, either, it's just another workaround that's unintuitive and cumbersome to use.

It already hit me when I was introduced to PW that for bigger projects one accumulates a ton of fields and it occured to me that it gets pretty messy pretty fast.
Grouping fields logically would be another great feature that would make the clusterf*** I witnessed on some of the projects that were showed to me much easier to handle.

I'm far from being an expert in PW but one of the things that I read over and over by all the PW evangelists is its flexibilty. A.k.a. if you need it you can build it.
But something that simple (and quite frankly very obvious) can't be built? I'm baffled, really...

[LostKobrakai]

I might repeat myself in parts, but we already have ways to handle similarly shaped recurring data. It's by using a dedicated Template and Pages. The only thing missing from my point of view is a nice way of creating and handling those pages, which is something present in repeaters as well as in pagetables. It's just not available for a one-to-one relationship, which it would be for example for seo settings.

Imagine your page could have a single, automatically created repeater page without the wrapping fieldset around it. I doubt anyone would ever notice that it's another page. But it would still have all the abilities you have for all other pages and nothing would need to change in the core of ProcessWire.

[bernhard]

ok i needed 5 reads of this and your old post and now i get what you are saying

that would be an awesome solution and would REALLY help in situations mentioned in this topic!

+1

[swissdoode]

@LostKobrakai
Unlike bernhard, I don't understand what you're aiming at. Would you mind to enlighten me?

Let's stick with my meta-tags example. I made a template called meta-tags and added the fields I made for this to it.
Then I also created a page for it using this template...
But: How do I add this template/page to other pages now?
How do I tell PW to add the page to all pages?

I'm confused... (sorry for the noob questions, btw).

[bernhard]

as far as i understood currently the workflow would be like this:

• create a template "metatags"
• add fields, "author", "description" and so on
• create a page holding all those meta-tags pages, eg "/metatags"
• add a page field "metatagpagefield" to all those templates where you want to save metatags, eg "templatea" and "templateb"
• create a page "demo template a" with template "templatea"
• now you have your field "metatagpagefield" and you can add a page there. if you setup everything correctly (auto-name and predefined parent) you could add your metatags via a modal window. your metatags would get stored somewhere like /metatags/automatically_created_pagename

now you could just edit the template "metatags" and all your templates with the field "metatagpagefield" would have those changes instantly.

at the moment this workflow looks kind of complicated, but i think what lostkobrakai is saying, is that if the presentation (the GUI) of the pagefield would be different (automatically creating the page /metatags/automatically_created_pagename in the example above) and showing the fields of this page directly in the edit-screen of page "demo template a" the editor would not even notice whats going on behind the scenes.

thats similar to repeaters and would be a great option imho!

it was not at all a noob question. welcome to the forum btw

@lostkobrakai - didn't want to beat you, just wanted to explain it in my words to see if i understood it correctly

[swissdoode]

Thanks for the mini-tutorial, bernhard

I was more or less able to re-create what you described. Right now, I am able to create a new meta-tags page from within the super-page - but I can't edit it from there (this might be just because my setup is wrong, though).

Although the functionality can be achieved like this, it is still cumbersome and kinda hard to maintain, not to mention that I'll have a separate page for just as little information as just meta-tags.
I still have to add the field to every template and can't just make it global and thus having it on every page/template.
I can't add it as a tab in the template like with the fieldset - the one thing I really like about fieldsets.

If the workflow were as described by you and lostkobrakai, it would be somewhat ok, but as long as this isn't the case, this approach doesn't make much sense to me.

To clarify things for me: even if I would, I couldn't create this kind of field-set-container whatever by creating a module or something?

[LostKobrakai]

4 minutes ago, swissdoode said:

not to mention that I'll have a separate page for just as little information as just meta-tags

It's exactly the same when you're using repeaters. They'll also create a page for each item. Even though it might only hold 2 or 3 fields.

[bernhard]

hi swissdoode,

that was kind of a theoretical tutorial  you would have to use this module to be able to directly edit the fields from the referenced page: 

but i know that this is NOT an ideal solution. as i said: i support the need of such kind of setups, but i'm with lostkobrakai that we should stay at the page/field/template setup

edit: maybe using a repeater and limiting the items to 1 would be a better solution?