Jump to content

Wishlist: Group field for grouping fields


Recommended Posts


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?

  • Like 1
Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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). :)

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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


did i understand you correctly?

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 weeks later...
  • 3 months later...

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ;)

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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? 


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By HMCB
      Unlike the Integer input type, Decimal doesn’t allow for a default value. I’d love to see this added.
      I’m working on a mini project where this would come in really handy. The site admins would have all 7 fields pre-populated and they can then adjust as needed.
    • By Kiwi Chris
      ProcessWire is an excellent framework for building just about anything, with great tools for permissions, input fields, and creating data structures.
      With the Combo and Table profields, it's possible to handle just about any data.
      These fieldtypes show the potential of ProcessWire to handle SQL tables in a more 'traditional' SQL table format, which leads to one area I wonder might have potential for a new feature.
      In addition to ProcessWire, I also do some work with ASP.Net Core, and one of the nice features it has is the ability to work with existing SQL databases, so that you can either build your models in the framework, or use existing SQL Tables.
      While working with any SQL data is possible in ProcessWire, it's a lot more hands on, with less built-in support.
      InputFields and FieldTypes are separate, and there's no reason why an inputField can't be used for data input for any kind of data, and indeed there are some modules that use inputFields to edit custom table data.
      What would be an amazingly useful addition to ProcessWire would be a module that allows mapping of inputFields to fields in an arbitrary SQL table without modifying the structure of the table itself.
      This is something the open source Directus project does by using metadata tables to store data about to display input for existing SQL tables, without touching their structure, but documentation isn't great for that project.
      I think ProcessWire has all the plumbing in place to enable this kind of functionality, and the Combo fieldtype gets pretty close, but still requires the combo table records to be associated with a ProcessWire page.
      Obviously, existing SQL tables won't automatically map to pages, which means directly accessing them on the front-end via URL automatically isn't possible, but often this isn't required as they may be for backend use only, or for consumption within a ProcessWire page. The recent support for URL/Path hooks though, means that if there is a need to directly access existing SQL on the front end via URL, it should be possible to create a hook to do so.
      I think adding the ability to create backend data entry for existing SQL tables would fully complete the ProcessWire philosophy of getting out of your way and not making assumptions about your content.
      It's currently already best of class in terms of doing this regard to front end presentation, but it's still a bit opinionated about data structures at the back end. This is absolutely fine if you're building a web app from scratch, and works really well in most cases, but there are times where being able to quickly incorporate existing data structures would be useful.
      To be clear, this isn't a replacement for the existing pages model, as that would be a huge and unecessary task to completely re-engineer ProcessWire, but rather an enhancement that can sit alongside all the good stuff that's already in ProcessWire so that it's possible to get ProcessWire to handle existing SQL data tables on the backend as neatly as it already does with its own data.
    • By Neue Rituale
      or in the modules directory: https://processwire.com/modules/fieldtype-oembed/
    • By jploch
      Fieldtype Page Table Grid
      This is a sneak preview of a side project I've been working on for quite some time now. A lot of work and thought has gone into this, so I will most likely release this as a commercial module at some point in the near future. 

      As a designer (and developer) I get the appeal of a WYSIWYG editor. After playing around with some WYSIWYG page builder tools, I always felt something was wrong about them. So I decided to build my own PW version based on PageTable.

      Here is a small demo (using AdminThemeCanvas, but its working with other admin themes as well) :
      There is also a complete website that I built for a friend of mine using this module and some custom blocks.
      This fieldtype shares a lot of features with PageTableExtended: it's also an extension of PageTable and renders the block templates in the backend and frontend (native PW templates and fields). You can also add your own css via module settings.
      The difference is, this fieldtype also gives you the ability to rearrange and resize elements in a visual way as well as enable inline editing for text, ckeditor and file fields. Similar (and promising) attempts have been made, but I wanted something based on native CSS grid instead of a CSS framework...so I built my own version. Most CSS frameworks are based on flexbox, which is great for layouting elements horizontally. With CSS grid, you can place elements horizontally and vertically, allowing for layouts that were not previously possible with CSS. Similar to webflow, this fieldtype uses javascript (in the backend) to let you manipulate CSS grid in a visual way to design fully responsive websites (or parts of them). It should still be possible to include a CSS framework if you like (just add the classes to your block markup and include the CSS via module settings).
      The CSS grid layout manipulations are saved in a single field as a JSON array and used to generate a dynamic stylesheet that you simply include in your main template (no inline styles). The styles are saved within the breakpoint you select and cascade down to smaller breakpoints. That means you can specify just the basic breakpoint and adjust other breakpoints if needed. The exception is the mobile breakpoint which will display everything in one column as a default (you can change the layout here too).
      The fieldtype also comes with an optional style panel to manipulate some additional CSS properties directly on the page. You can customize the panel or disable it completely from the module settings (and just use a CSS file that you include via module settings). The style panel is based on inputfields (nothing is saved to the database). This means that you just have to install the module and all fields are available to all blocks automatically (this can be customized). It also has the benefit that your installation is not flooded with fields; this module only installs one field.
      Don't want to give your customer all that power? Design features can be disabled for certain roles. The grid editor role can just edit the content and use the inline editing feature to edit content quickly. You can then also grant access individually to the style panel, resize or drag functionality.
      Blocks are just pages Blocks are defined by native PW templates and fields Manipulate CSS grid in a visual way to design fully responsive websites (or parts of them) Design features can be disabled for certain roles Inline editing of text, ckeditor and file fields The layout is 100% CSS grid (very small css file size) Simply drag and resize to manipulate grid items directly inside the backend Manipulate grid columns and rows directly on the page (use any number of columns you want) All style manipulations are saved as JSON and used to generate a dynamic stylesheet that you just include in your main template (no inline styles) Nested groups/grids (child pages of nested blocks are created under group parent) Global blocks work with page reference field (changes on one page, changes all blocks on all pages) Manual and auto placement of grid items Define custom icons for your blocks via native template settings (template -> advanced -> icon) Option to load lazysizes in the backend to enable lazy loading of assets with class lazyload Works with all default and ui-kit based admin themes If you have any questions or feedback, let me know.
    • By franciccio-ITALIANO
      Hi everyone.
      I've created 12 templates that are the same but each with an extra bit of html code. 
      The piece of code is as follows:
      <div> <div class="box-pf"> <i class="fa fa-map-pin fa-2x fa-red faa-pulse animated"></i> <a href=""> <span class="uk-text-middle"><i>Sonchus oleraceus</i> 'Grespino degli Orti'</span></b> </a> </div> </div> On the third line we read "fa-red."
      I created 12 similar templates.
      The first template has only one box with fa-red, the last template has 12 boxes with icons of 12 different colors.
      So. is there any way to have only 1 template and add, if I want and when I want, a small or big, same or different piece of html code?
  • Create New...