Jump to content
steveooo

Wishlist: Group field for grouping fields

Recommended Posts

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?

  • Like 1

Share this post


Link to post
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 :)

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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). :)

Share this post


Link to post
Share on other sites

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? 

Share this post


Link to post
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!

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

@steveooo

did i understand you correctly?

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
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? 

 

Share this post


Link to post
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 Juergen
      Hello @ all,
      I am creating a new inputfield/fieldtype to store opening hours, but I am struggeling to save values from multiple dynamic created inputfields in 1 column of the database.
      Scenario:
      The user can enter one or more opening times per day in a UI.
      Fe:
      Monday open from 08:00 to 12:00 and from 14:00 to 17:00 Tuesday open from 08:00 to 12:00 and from 14:00 to 19:00 and so on
      Via a little JavaScript you can add as much opening times as you need per day - the additional inputfield will be created dynamically.
      After form submission all the values are in the POST array -> this works (see example below):
      ProcessWire\WireInputData Object ( [openinghours_mo-0-start] => 09:00 [openinghours_mo-0-finish] => 13:00 [openinghours_mo-1-start] => 14:00 [openinghours_mo-1-finish] => 18:00 [openinghours_mo-2-start] => 21:00 [openinghours_mo-2-finish] => 23:00 [openinghours_tu-0-start] => 09:00 [openinghours_tu-0-finish] => 13:00 [openinghours_tu-1-start] => 14:00 [openinghours_tu-1-finish] => 18:00 [openinghours_we-0-start] => 09:00 [openinghours_we-0-finish] => 13:00 [openinghours_we-1-start] => 14:00 [openinghours_we-1-finish] => 18:00 [openinghours_th-0-start] => 09:00 [openinghours_th-0-finish] => 13:00 [openinghours_th-1-start] => 14:00 [openinghours_th-1-finish] => 18:00 [openinghours_fr-0-start] => 09:00 [openinghours_fr-0-finish] => 13:00 [openinghours_fr-1-start] => 14:00 [openinghours_fr-1-finish] => 18:00 [openinghours_sa-0-start] => [openinghours_sa-0-finish] => [openinghours_so-0-start] => [openinghours_so-0-finish] => ) The property name is always the name attribute of the field 😉 . If the property is empty means closed on that day.
      Now I need to combine all those values into 1 array (or json array) and store it in the database in 1 column called 'hours' in my case (see screenshot below):

      In my ___processInput(WireInputData $input) method I have tried to make it work like this:
      public function ___processInput(WireInputData $input): self { $name = $this->attr('name'); $value = $this->attr('value'); //input object includes always every input on the page, so lets filter out only inputs from this field //we need to do this, because the number of values is variable - so extract only values that starts with $name.'_' $nameAttributes = []; foreach($input as $key=>$value){ if(substr($key, 0, strlen($name.'_')) === $name.'_'){ $nameAttributes[$key] = $value; } } // loop through all inputfields of this fieldtype $time_values = []; foreach($nameAttributes as $nameAttr => $value) { $time_values[$nameAttr] = $value; } } //save it in the database $input->set('hours', serialize($time_values)); return $this; } The only important part of this code is the last part with the serialize function.
      After saving it will create a record in the database, but the value is always NULL (default value) (see below).

      Checking $time_values returns all the values, but printing out "$this" shows me that the property "hours" inside the Openinghours object is empty (see below) - so the mistake must be there, but I dont know where?!?!?!?
      [title] => Home [openinghours] => ProcessWire\OpeningHours Object ( [data] => Array ( [hours] => ) ) If I check the sleepValue() method or the sanitizeValue() - they are also empty. So it seems that the values will not reach these methods. I havent found a clear documentation of whats going on behind the saving process of an inputfield.
      As far as I know the saving process starts with the form submission. The values are in the POST array and will be processed by the processInput() method. Before they will be saved in the database they will be sanitized by the sanitizeValue() mehtod and afterwards they will be prepared for storage in the sleepValue() method.  The last step is the storage itself.
      Has someone an idea what is missing by storing values from multiple fields into 1 database column or has someone a working example of such a scenario on github to help me out.
      A clear explanation of the storage process will be also helpful.
      Thanks and best regards
    • By Juergen
      Hello @ all!
      I want to share a simple fieldtype and inputfield to store address data with you.
      I have created this inputfield for learning purposes and it has no fancy functionality. It is simply for storing address data such as street, number, postalcode and so on in one table. As an addition you can store latitude and longitude too, so you can use them in maps.
      Here is a screenshot of what it looks like:

      You can select which fields are mandatory and you can choose if the inputs for longitude and latitude should be displayed. These settings can be configured in the field configuration.
      If you find this inputfield useful you can download it at https://github.com/juergenweb/FieldtypeSimpleAddress
      There you will find a detailed explanation. If you have an idea of an usefull feature that can be added or you have detected a bug, please report it in my github account.
       
    • By gebeer
      Hello all,
      sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: 
      a predefined folder in site/templates/ and/or a  page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully.
      UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version.
      Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference
      Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Read on for features and use cases.
      Features
      Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ?
      If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github.
      Here's how the input field looks like in the page editor:

      If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip
      Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance.
      Thanks to all who contributed their feedback and suggestions which made this module what it is now.
       
    • By gebeer
      EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons.
      I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules:
      Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield.
      Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children.
      And there also is a helper module that takes care of cleanup tasks.
      This module evolved out of a discussion about my other Module FieldtypeImagePicker.  It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield.
      When to use ?
      Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site.
      Suited for images that are used on multiple pages throughout the site (e.g. icons).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features
      Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup
      Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen:

      View of the field settings

      The module can be installed from this github repo. Some more info in the README there, too.
      In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory.
      My ideas for further improvement:
      - add ajax loading of thumbnails
      Happy to hear your feedback!
       
    • By Gadgetto
      Hi,
      for my GroupMailer module I've created a custom Fieldtype + Inputfield module which provides multi-column field values. The first field column is a visible text field and there are some other columns which are not presented to user (they are rendered as hidden form fields).

      This is the database schema:
      $schema['data'] = 'text NOT NULL'; // we're using 'data' to represent our 'subject' field $schema['sendstatus'] = 'tinyint NOT NULL DEFAULT 0'; // message send status $schema['recipients'] = "int(10) unsigned NOT NULL DEFAULT 0"; // recipients counter $schema['sent'] = "int(10) unsigned NOT NULL DEFAULT 0"; // sent counter $schema['started'] = "int(10) unsigned NOT NULL DEFAULT 0"; // message sending start $schema['finished'] = "int(10) unsigned NOT NULL DEFAULT 0"; // message sending finished This are the ___wakeupValue and ___sleepValue methods:
      Now I try to extend this Fieldtype/Inputfield to provide multi language features.
      Only the first value ("data" which represents the "subject" field) should be/needs to be multi language!
      I had a look at the built in Fieldtypes (e.g FieldtypeText & FieldtypeTextLanguage) which provides multi language support but I couldn't find a similar case (multi-value field with language support). All built in Fieldtypes are single-value fields.
      I know this is a very "general" question but maybe somebody could push me in the right direction?
×
×
  • Create New...