Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Original report
I would like to be able to show/hide a group of fields (according to the documentation it's supposed to work).
I've created a fieldset with all fields that will be dependent but this group field is not in the list of dependent. How can a dependee affect a group of dependent fields ?
Thanks!
Remaining tasks
Support for ANDing (#195)Support nested groups (#226)Get tests working again.(See #3134183: Functional JavaScript tests are failing.)Statically cache DependencyHelper for different entity types / bundles. (#235)This can be done in #2856720: Support for Inline Entity Form.
Follow-up issues
Please create new tickets for these (unless they already exist), and add links to them from here. Thanks!
- Support for ORing (#217)
- Support control field in a different tree branch at another level (#227)
- "Show label" on "HTML Element" shows when the rest of the field group is hidden (#230)
- #2856720: Support for Inline Entity Form
Comment | File | Size | Author |
---|---|---|---|
#253 | Tab_without_data-drupal-states.png | 33.39 KB | ethanbb |
#253 | Element_with_data-drupal-states.png | 64.05 KB | ethanbb |
Issue fork conditional_fields-1161314
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
peterpoe CreditAttribution: peterpoe commentedThis functionality is still missing from Conditional Fields 7.x-3.x. Please follow this issue for announcements when it will be implemented.
Comment #3
pgorecki CreditAttribution: pgorecki commentedsubscribe
Comment #4
Martin Mayer CreditAttribution: Martin Mayer commentedsubscribe
Comment #5
Shadlington CreditAttribution: Shadlington commentedSubbing
Comment #6
MrPhilbert CreditAttribution: MrPhilbert commentedSubbing too.
Comment #7
clashar CreditAttribution: clashar commented+1
Comment #8
stevebab CreditAttribution: stevebab commentedsubscribe
Comment #9
thomasLausZ CreditAttribution: thomasLausZ commentedsubscribe
Comment #10
Shadlington CreditAttribution: Shadlington commentedI don't think you meant to assign it to you - unless you intend to fix this yourself?
Comment #11
thomasLausZ CreditAttribution: thomasLausZ commentedNo, you are right, but can't change it back.
Comment #12
Shadlington CreditAttribution: Shadlington commentedThat's because I fixed it for you :)
Comment #13
jackbravo CreditAttribution: jackbravo commentedsubscribe
Comment #14
jackbravo CreditAttribution: jackbravo commentedI was taking a shot at implementing this and found that under current implementation this seems almost impossible. The conditional_fields table saves only the field id, which is a number. Based on this number there is no way of knowing whether it is a regular field or a group field.
What I think is that in order to implement this the conditional_fields table should change to store the field name instead. Or add another column that specifies if this is a field or a group field.
What do you think?
Also, this only would apply to the dependent field, as no dependee can be a field group.
Comment #15
AtomicTangerine CreditAttribution: AtomicTangerine commentedsub!!!
Comment #16
Fanaile CreditAttribution: Fanaile commentedSubscribing;
Comment #17
chalee CreditAttribution: chalee commented+1 subscribing
Comment #18
restyler CreditAttribution: restyler commentedsubscribing
Comment #19
drupov CreditAttribution: drupov commentedsubscribe
Comment #20
misxooo CreditAttribution: misxooo commentedsubscribe
Comment #21
Coupon Code Swap CreditAttribution: Coupon Code Swap commented+1
this would be very useful.
Comment #22
peterpoe CreditAttribution: peterpoe commentedField group support is not a small task, it will probably take some time. In the meantime, consider using the Field collection module, which already works (almost) perfectly with Conditional fields.
#14: You're right, it would be necessary to change the schema by adding a 'dependent_type' or 'dependent_module' column that identifies the type of dependent (field or fieldgroup).
Comment #23
jackbravo CreditAttribution: jackbravo commentedWow! I didn't know about field_collection. But looks pretty nice. Hope to try it soon.
Comment #24
vasikesubscribe.
Field collection it's a good tool, but why should we build new entities when just some grouped fields are needed.
I think this is a very needed feature and more than nice to have.
Comment #25
jaxpax CreditAttribution: jaxpax commented+1
Comment #26
Tobias Englert CreditAttribution: Tobias Englert commentedsub
Comment #27
that0n3guy CreditAttribution: that0n3guy commentedsub
Comment #28
JordanMagnuson CreditAttribution: JordanMagnuson commented+1 For this.
Comment #29
jackbravo CreditAttribution: jackbravo commented@davidlerin there is now a follow button at the top you know =)
Comment #30
-ds- CreditAttribution: -ds- commentedThis feature would be great!
I have a huge form with 100+ fields that are dependent on each other and I would really like to display them using tabs split into their categories etc rather than on one massive long page as not all fields are needed depending on the initial selection.
Comment #31
Rontero CreditAttribution: Rontero commentedI found that Conditional Fields module does actually work with Fieldgroup module. I use vertical tabs for sorting all my fields. Unless both dependent and dependee are in the same tab, dependencies work.
Comment #32
mrfelton CreditAttribution: mrfelton commented@Rontero - what do you mean 'it works'? Im using Accordion groups to group fields, and these accordion groups not available for selection by conditional fields. Accordian are much the same as vertical tabs in terms of the implementation - it's just a different widget on the fieldgroup. How exactly re you using vertical tabs with conditional fields?
Comment #33
Rontero CreditAttribution: Rontero commented@mrfelton I'm using conditions on fields not on accordions etc. As long as yoour dependent and dependee are in the same group, Conditional Fields module works.
Example from my site:
I have Drupla Commerce installed for adding products to my site.
Case: Select the appropriate country (the manufacturer is based in) after user selects maker's name.
First field is dependee and second is dependent.
After constructing such a form, in manage dependencies tab i made proper dependent/dependee selections and as a rule used fields with a value / has value.
I hope this helps.
Comment #34
Fanaile CreditAttribution: Fanaile commented@Rontero;
True, even if the two fields are not in the same field group the dependencies work. For example, one client's site has registrants choose individual or group registration type. If they choose individual several conditional fields will be shown and vice versa if you choose group.
But what he wants and what I'm trying to get working again is that the entire field group will be shown or hidden pending the choice. Otherwise even if I set each field to show or hide pending the choice, the field group still shows - with the label for it - just none of the individual fields do.
Comment #35
bryancasler CreditAttribution: bryancasler commentedI'm looking for the same solution as Fanaile
Comment #36
Golem07 CreditAttribution: Golem07 commented@Fanaile: This is exactly what I am in need of, too. Please let us know in case you solve this in any way.
Comment #37
rwilson0429 CreditAttribution: rwilson0429 commentedYes, getting the
would be a great feature that's needed.
Comment #38
carlmcdade CreditAttribution: carlmcdade commentedIn D7: It would be better to use a parent/child situation. A new field that is the field id of the field_group table as the parent_id. start gathering the children and see if they all have the same parent. if so then show the parent.
Comment #39
Tony Finlay CreditAttribution: Tony Finlay commentedVery interested too, has there been any movement on this or will there even be any attempt to implement the feature?
Comment #40
yannickooOh, no activity here ;(
Comment #41
sgurlt CreditAttribution: sgurlt commentedsub
Comment #42
warmth CreditAttribution: warmth commentedAny way to display or not an entire group using CF?
Comment #43
funkytraffic CreditAttribution: funkytraffic commented+1 subscribing
Comment #44
bitcookie CreditAttribution: bitcookie commentedFor now you can kinda do this with javascript. We haven't tested this too much, but have it running on one of our sites.
First, make a javascript/jquery function to hide empty fieldsets
Then, bind a change event to every form widget in your node form to fire the cleanup function
Comment #45
friera CreditAttribution: friera commented+1
Comment #46
aze2010 CreditAttribution: aze2010 commentedsubscribing
Comment #47
mahyarsbt CreditAttribution: mahyarsbt commentedsubscribe
i test "field collection" and "fields group" modules with conditional field on profile 2.
but not works
Please support fieldset feature.
Comment #48
miccelito CreditAttribution: miccelito commented@Fanaile #34:
I have just tested these modules together
Conditional Fields 7.x-3.x-dev
Field collection 7.x-1.0-beta5
in purpose to see if it solves the issue mentioned in this thread with still showing labels for fieldgroups with hidden fields.
And as far I can see from my test, it works!
I did try with fields at admin/config/people/accounts/fields
Comment #49
nevergone CreditAttribution: nevergone commentedAnd since then?
Comment #50
vlooivlerke CreditAttribution: vlooivlerke commentedWould it not be better to have conditions for field groups?
Then you can show/hide entire field groups and its fields with 1 simple field condition.
If the field has value then show field group
Maybe this will have to be an add-on module
EDIT:
Wait, I want to hide an empty fieldset if the fields in the fieldset are not visable due to the field condition.
Comment #51
Shiraz Dindarhey folks, if you want to show/hide a whole fieldgroup conditionally:
Courtesy of bobylapointe over at stackpoint.
Works well.
Perhaps conditional fields would implement it as such.
Comment #52
pmichelazzoThis code didn't work for me. Also I receive this message:
Notice: Undefined index: #id in drupal_process_states() (line 4664 of /Users/me/Sites/tests/includes/common.inc).
Comment #53
ryantollefson CreditAttribution: ryantollefson commentedI finally got this working - similar to #51 & http://drupal.stackexchange.com/questions/14635/hide-a-cck-fieldgroup-us... (but with added if statement to prevent errors I was getting with other modules.
Comment #54
vlooivlerke CreditAttribution: vlooivlerke commentedBefore I try this code, just a stupid question.
Does this code show/hide the fieldgroup using JavaScript in real-time or only after a node save?
And settings like speed and fade options would be a bit more complicated I guess.
Comment #55
ryantollefson CreditAttribution: ryantollefson commentedThis shows/hides in real time, but doesn't use javascript, though I'm sure it could be done... perhaps look at: https://drupal.org/node/304255 or http://drupal.stackexchange.com/questions/6960/how-to-add-jquery-plugin-...
Comment #56
arthitst CreditAttribution: arthitst commented+1 subscribing
Comment #57
akolahi CreditAttribution: akolahi commentedI'm willing to pay for development of this functionality. Send me a note if interested.
Thanks.
Comment #58
gintass CreditAttribution: gintass commentedHere is one workaround for this problem that might help someone. I just tested and it worked.
As stated above conditional fields module supports field collections created by Field Collection module, but not field groups created by Field Group module.
Instead of adding field group with a bunch of fields directly to the content type you can add it to a field collection. Then you can apply conditions to that field collection and control visibility of all the field groups and fields inside this field collection.
Comment #59
mastoll CreditAttribution: mastoll commented@gd1008, moving fields from a field group to a field collection does not work if you are using Display Suite for node display. The conditional aspect of the node edit form works fine. The field collection doesn't display in the node view. Have looked at Display Suite and Conditional fields for a solution - none. I don't know where it's easier to address: Field Group, Field Collection, Conditional Fields, or Display Suite. It's a convoluted and interesting interplay between the modules.
Comment #60
rollingnet CreditAttribution: rollingnet commentedI tried to apply the #51 and #53 patches, but without success.
Can someone confirm that they work and how?
Comment #61
ryantollefson CreditAttribution: ryantollefson commentedThese aren't patches, but are meant to be used as a custom module. It's really a work around, but yes it does work just fine.
You should be able to paste the code into "your_module.module". Next rename the field_group and field_name parts to match your actual fields. Then just create "your_module.info", put it all in a folder in your modules directory and enable it.
Either use the code from #51 or #53 (not both).
Comment #62
mauzeh CreditAttribution: mauzeh commented#44 does not work for the case of horizontal or vertical tabs. If you want to hide a tab instead of a field group, use this Javascript snippet:
Comment #63
apmsooner CreditAttribution: apmsooner commentedI tried some of the jquery examples above and couldn't get them working for me so I came up with my own implementation that does work and additionally adds prev/next links to navigate through the tabs to combine multi-page functionality with vertical tabs. I still consider myself a jquery novice so I'd sure appreciate any feedback to the below code as if there are ways for better optimization. Functionally... it works quite well though.
Anyone can try this out by pasting the entire script into a .js file loaded in your theme or module or you could just paste it into a rule with the js injector module. I hope someone finds it useful and willing to make it better as it took alot of time for me to research how to do this.
FYI: The main reason why some of the example scripts above weren't working for me is because they were counting .form-wrapper with display:block. This led to inaccurate count for me because .form-wrapper wouldn't be explicitly set with display:block unless conditional fields triggered it so my method is to do a total count of .form-wrapper and compare it to a count of .form-wrapper with display:none. I also had to explicitly look for the first level of .form-wrapper only because in the case of using field collections, there would be several divs within that also had class of .form-wrapper which would totally screw up my count.
Comment #64
apmsooner CreditAttribution: apmsooner commentedCorrected pasted code in #63 as i had an extra unnecessary div in the selector.
Comment #65
AnybodySadly this important feature is still missing. Is there any work in progress?
Comment #66
apmsooner CreditAttribution: apmsooner commented@Anybody,
I think its a little complicated to provide as a fieldset setting as hiding tabs would have to react to field change events and i don't know if a setting like that can account for the specific change events to trigger the function to hide fields unless it provided a field to input selectors that got passed to the javascript. Even so, while my script in #63 works for me, i only accounted for vertical tabs and in my case i only have one level of vertical tabs. If someone put fieldgroups within fieldgroups, i think that could add alot more complexity to try to figure out how to loop through and find hidden fields... and additionally performance could be an issue as number of fields and fieldgroups grow. In the meantime, you could certainly adapt my script above to your needs and get the functionality you need now.
Comment #67
apmsooner CreditAttribution: apmsooner commentedTechnically someone could add a checkbox to the fieldset settings form labeled "Hide hidden fields" that would render a class for the fieldset that could be evaluated in script similar to what i posted but really.... thats not even completely necessary as you can already specify classes to your fieldsets now so you could just change .vertical-tabs-pane in my script to something more generic and that would probably work wouldn't it? You could certainly take out all the navigation stuff from my script and just hide/show fieldgroups on the change events. It actually now makes better sense for me to make my class in the script more generic as there are certain vertical tab groups that i know will always have fields that aren't hidden so no use running the script for nothing.
Comment #68
NancyDruThe code in #51 and #53 does not work for me (7.28). As a matter of fact, if there is no ID defined in the field settings, it causes several problems.
This would be a great feature to have, but I leave here in 3.5 weeks, so I suspect I'll never see it.
Comment #69
apmsooner CreditAttribution: apmsooner commented@NancyDru, why not just do it in jquery? #63 could be modified with conditions to check the type of fieldgroup it is and thus not be specific to vertical tabs. Maybe i'm missing something but i'm not sure i understand the dire need to have it in a module. Just curious.
Comment #70
NancyDruA) I am not a javascript person.
B) There is already some code similar to this in their custom module. It just doesn't work.
Comment #71
GrimreaperThanks for code in #63.
Comment #72
imclean CreditAttribution: imclean commented#51 looks to be on the right track. See also: #1053174: hook_form_alter form state problems
There's some good example code in that other issue. You shouldn't have to write a line of javascript to get this working.
Comment #73
imclean CreditAttribution: imclean commentedFor #51 to work and not get the error in #52:
Once the above 2 tasks have been completed, you can use something like this example code:
Comment #74
NancyDruIan, a fieldset already has "form-wrapper" and an id. Maybe my problem is that I am triggering on a two-value radio, not a checkbox.
Comment #75
imclean CreditAttribution: imclean commentedNancyDru, maybe it's the base theme we use but our fieldsets don't have an ID or necessary class. Radios should work but you need to use the "value" condition instead of "checked". We use the below method:
For multiple options (OR):
https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...
Comment #76
imclean CreditAttribution: imclean commentedOk I see the potential problem with Conditional Fields.
Multipage Fieldgroup states appear to override the custom states set above. Related fieldgroup issue was marked as a duplicate of this one: #1518026: Support for "Conditional Fields" module, field group remains visible when fields have been hidden using drupal form states.
Comment #77
dnlmzw CreditAttribution: dnlmzw commentedRewrote some of the code found in example #63, to make it work with horizontal panels. Paste the code into a .js file and load it in your project to make it work. Not well tested, but works for me.
Comment #78
benmmc CreditAttribution: benmmc commentedI tried others here, but none of them worked, so I wrote this very generic JS that basically looks inside each fieldset for form-item class elements, and determines whether they have been hidden or not. If a fieldset has any non-hidden items, it shows the group. Otherwise, it hides it.
The :not() selector is necessary because some widgets have the form-item class for individual choices, as opposed to one element with the form-item class for each field. I may have missed some widgets, but this selector covered all the widgets I was using.
Comment #79
eMuse_be CreditAttribution: eMuse_be commentedsubscribe
Comment #80
milos.kroulik CreditAttribution: milos.kroulik commentedI tried to apply solution from #78, but it didn't work. Maybe I've done something wrong - is there anyone, who tried it?
Comment #81
tomvv CreditAttribution: tomvv commented#63 is great for hiding of empty tabs, thanks.
Comment #82
System Lord CreditAttribution: System Lord commented+1
Comment #83
eMuse_be CreditAttribution: eMuse_be commented+1
Comment #84
Parkes Design CreditAttribution: Parkes Design commented+1
Comment #85
axe312 CreditAttribution: axe312 at Wunder commentedPlease do not write "+1" to the issue, instead use the "Follow" button on the right upper area of the issue.
Since this issue is needed by so many people, it might be smart to fund some money to fix it? https://www.drupalfund.us/
Comment #86
kitzinger CreditAttribution: kitzinger commented+1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1
!!!!!!!!
Comment #87
System Lord CreditAttribution: System Lord commentedI have to agree with ktzinger. The "Follow" feature doesn't tell anybody that I'm having similar issue. Maintainers react to volume of concern (issue comments) not to who's following. What if someone commented "I'm having the same issue." Would you tell them to stop posting that and use "Follow" ? In my mind "following" could simply mean a member is curious about a topic and don't have an issue or comment. Which to me means if everyone used "Follow" the maintainers would not have any indication that there is bigger issue than it appears.
I've been wanting to say that for months! :) Thank kitzinger!
Comment #88
apmsooner CreditAttribution: apmsooner commentedIf someone wants to try to create a patch that includes settings that would implement code similar to #63 as a setting.... that would be a big plus and would push this closer to an actual addition to the module. It would of course need to accommodate other types of tabs rather than just vertical but it seems as though it could be a setting added within each field group parent container to hide/show child tabs if fields are hidden.
Otherwise, feel free to use/modify that code for your needs as a workaround. There are several confirmations that it works...
Comment #89
kitzinger CreditAttribution: kitzinger commented@apmsooner - yes yes yes we get it, we have read the posts about the code, we can see the code above, but that is not a resolution and not why we are posting. :D We are posting to keep the thread alive so that, hopefully, some day soon, the maintainer or a possible contributor will see our outcries and maybe devote some highly appreciated time to help. Of course they are not obliged, and there is a code posted above, but it would be lovely if the feature was available in the bare module! ... just being a bit cheeky, but nonetheless.....
Hope you are not offended in any way, that is certainly not the intention! Of course I am still very grateful for the module
Comment #90
jlbellidoSubscribed
Comment #91
bgilhome CreditAttribution: bgilhome commentedI've implemented an approach to add fieldgroups as a dependent. In the conditional_fields_element_after_build function, as well as any field that is saved as a dependent, any field that is a child of a fieldgroup saved as a dependent also gets the dependency attached. NB currently only includes first-level children.
Tested with 'visible' state but in theory could use other states eg. 'required'.
Also in conditional_fields.js I've added the js from #51/#53 above to hide empty fieldsets on load and form input/select click. Currently only works with field_group display types that output a fieldset tag. This should probably also be extended to bind to input change events, eg. text inputs.
As is, this would probably break if there were field_groups with the same numerical ID as any field IDs. Maybe the 'dependent' column in the conditional_fields table could be changed to VARCHAR and any field group IDs prepended with eg. 'group_'?
The patch also includes the start of another approach using hook_field_group_pre_render_alter that could be used to add states to the fieldset itself (instead of the child elements).
Comment #92
apmsooner CreditAttribution: apmsooner commented@bgilhome,
One thing i see with your javascript in that patch is that like some of the other code submitted here:
This assumes the style exists for display:block to get the count however, if there are fields within the fieldset that are not affected by conditional fields, they will not be explicitly set with display:block so your countShownSubFields variable won't include those and thus render the fieldset hidden when it shouldn't be. My code in #63 does a count on hidden and compares to total count to determine if group should hide/show. Also, in cases like field collections, .form-wrapper may exist multiple times within the field so again, my jquery targets with specificity to only count the first instance, otherwise, again your count could get thrown off. Just my $0.02.
Comment #93
bgilhome CreditAttribution: bgilhome commented@apmsooner, sure, that js is a little janky - it might be best to use the hook_field_group_pre_render_alter in the patch to add some #states rather than trying to bind to input click/changes and count fields.
Comment #94
bgilhome CreditAttribution: bgilhome commentedSmall fix to set $groups as an empty array if none present in conditional_fields_dependency_add_form.
Comment #95
djween CreditAttribution: djween commentedHi,
Thanks for the patch in #94. I received this after I patched...
Notice: Undefined index: dependent in conditional_fields_element_after_build() (line 312 of /xxxx/xxxx/xxxx/xxxx/sites/all/modules/conditional_fields/conditional_fields.module).
Thanks
Comment #96
davidczadilek CreditAttribution: davidczadilek as a volunteer commented@djween
just patched it myself today and it works just fine
i have a rather complex set up of dependencies by now, so i suppose you either made some mistake while patching or you had a different base
@bgilhome
thanks for the patch. does not work right though
I'm still trying to figure out an alternative way - trying to see how the module shows/hides single fields in the first place - but I havent quite figured it out yet (have only worked with drupal for a few days so far). But if i find a better solution - i'll surely post it.
Comment #97
jrb@pmichelazzo
@NancyDru
I was having the same problem as in #52. It wasn't working, and I was getting this notice:
Notice: Undefined index: #id in drupal_process_states() (line 4664 of /includes/common.inc).
The key to fixing it was here:
https://www.drupal.org/node/1053174#comment-9153819
You need to add the #id directly to the fieldgroup array, not as an attribute. Once I did this, it worked as expected.
My function ended up like this:
Comment #98
davidczadilek CreditAttribution: davidczadilek as a volunteer commentedFound another Problem - third-level and higher field groups are not hidden (programmatically).
There's already a ticket in the field-group module, but I think it's this module's part to handle this.
I'll leave it for now - maybe using a workaround to have only second level conditional fields, as I currently have no time to look into it more closely.
Some info that's interesting as well - the fields within that displayed third level group (actually all fields from that form) are all hidden per user role/permissions on the path the problem occurs on.
Comment #99
bgilhome CreditAttribution: bgilhome commentedI've implemented this a different way, patch attached. Instead of showing/hiding empty fieldgroups via JS, I've used the hook_field_group_build_pre_render_alter (which runs after form's after_build is done) to manually call conditional_fields_element_after_build() for any fieldgroup elements and fieldgroup children elements, and conditional_fields_form_after_build() after that.
This way, #states can get appended to the fieldgroup elements themselves, as well as children of fieldgroups. For fieldgroup dependents using visible/hidden states, the #states gets appended to the fieldgroup element. For fieldgroups dependents with other states, the #states get appended to each (first-level) child of the group.
Although the correct #states are appended, currently the show/hide functionality is not working on the fieldgroup element. Not sure if some js needs to be re-attached or something.
This patch relies on a patch to the field_group module to correctly update the #array_parents for each child of a fieldgroup, to include the fieldgroup parent/s: https://www.drupal.org/files/issues/field_group-update_array_parents-249... in https://www.drupal.org/node/2494385
It uses the updated #array_parents when reprocessing elements with conditional_fields_element_after_build() to get the nested form field in conditional_fields_form_after_build(). NB in conditional_fields_attach_dependency() I've set the 'field_parents' and 'parents' keys to #array_parents if available, I couldn't see any reason not to, perhaps someone can tell me!
Comment #100
bgilhome CreditAttribution: bgilhome commentedComment #101
bgilhome CreditAttribution: bgilhome commentedSome more progress, now the element validate callback is called for each fieldgroup dependent and the form, so that states js is attached to the new dependent fieldgroup elements. Fieldset fieldgroups are shown/hidden fine but plain divs are not - elements of type '#markup' don't get processed for states.
Patch and interdiff from patch in #99 attached.
EDIT: sorry, patch/interdiff should be numbered 101. This patch relies on field_group patch https://www.drupal.org/files/issues/field_group-update_array_parents-249... to update #array_parents & #field_parents on form elements nested in fieldgroups.
Comment #102
bgilhome CreditAttribution: bgilhome commentedComment #111
bgilhome CreditAttribution: bgilhome commentedPrevious patch doesn't apply to current 7.x-3.x head, updated patch attached.
Comment #112
bgilhome CreditAttribution: bgilhome commentedComment #114
david.czinege CreditAttribution: david.czinege as a volunteer commentedI applied the #111 patch, but it cause a fatal error on the node add form:
Notice: Undefined property: stdClass::$array_parents in conditional_fields_field_group_build_pre_render_alter() (line 244 of /.../conditional_fields/conditional_fields.module).
Warning: array_merge(): Argument #1 is not an array in conditional_fields_field_group_build_pre_render_alter() (line 244 of /.../conditional_fields/conditional_fields.module).
Recoverable fatal error: Argument 2 passed to drupal_array_get_nested_value() must be of the type array, null given, called in /.../conditional_fields/conditional_fields.module on line 245 and defined in drupal_array_get_nested_value() (line 6771 of /.../includes/common.inc).
Comment #115
bgilhome CreditAttribution: bgilhome commentedHi @david.czinege, you'll need to also apply the field_group patch https://www.drupal.org/files/issues/field_group-update_array_parents-249... which provides the array_parents property on the group.
Comment #116
alejandrovaquero CreditAttribution: alejandrovaquero commentedPatch #111 does not work for me when using with Inline Entity Form module:
Notice: Undefined index: #form_state in conditional_fields_field_group_build_pre_render_alter() (line 221 of /var/www/html/sites/all/modules/contrib/conditional_fields/conditional_fields.module).
Comment #117
Fingerlinck CreditAttribution: Fingerlinck commentedGod! The issue was started on May 18, 2011.
Comment #118
Nique CreditAttribution: Nique commentedWhile it would be convenient to be able to show/hide an entire fieldset through one dependency, at this point I would be quite content if I could just make the fieldset label not show up unless and until at least one of the fields within that fieldset is made visible.
I am willing to create a separate dependency for each field within the fieldset, but I really don't want a whole bunch of childless fieldset labels cluttering up my node/add form ... spreading confusion and alarm amongst my content creators.
Comment #119
shevgeny+1 subscribe
very necessary!
Comment #120
Syntapse CreditAttribution: Syntapse as a volunteer commentedsubscribing. is there a definitive solution to this issue pending and are there plans to update the module?
Comment #121
milos.kroulik CreditAttribution: milos.kroulik commentedThe patch mentioned in #115 doesn't apply to the latest dev, neither applies the latest patch from the corresponding issue: https://www.drupal.org/node/2494385
EDIT: #97 works fine as a workaround, if anybody needs it
Comment #122
jproctorPatch in #111 doesn't find nested field groups. In my case it was possible to move the inner group outside its parent, set it as the dependent on a conditional, then move it back in.
Comment #123
jproctorMy problem in #121 wasn't actually the nestedness, it was that the field group was created by a feature and was never in the database: it didn't meet the conditions that Field Group module felt was necessary to create a row in the field_group table, and CTools was capable of faking it with the code in the feature. However, CF assumes a numeric dependent id, so patch #111 (and its predecessors) tries to use the id of the row in the field_group table. Loading the featurized conditional field into a clean db failed because the feature stores the correct identifier of the group, but there was no db entry for it so the CF table had a record with a dependent id of 0.
I rerolled #111 against current 3.x-dev and added code to conditional_fields_features_rebuild() to force creation of a field_group row so we can properly create the dependency.
This patch still needs work. Field groups without rows in the db (true in my case whenever there's only one field group in the content type and it was created by a feature) still can't be dependents: the loop that creates the
$fieldgroups
variable in conditional_fields.admin.inc (lines 233-236 in patched current 3.x-dev) still blindly assumes there's an id field, so can only show one field group (possible to have more than one on the content type if they're nested, but both field groups' id are null so the second overwrites the first) and ends up outputting a select option with a null value in the config form. Probably the thing to do is change that to key on the group identifier and then update conditional_fields_dependency_add_form_submit to recognize when it gets a group identifier and force a save like my hook_features_rebuild() code does.Wouldn't be a terrible idea to write some tests for all this stuff, too, and add a little "
if (module_exists('field_group'))
" to keep it from breaking the current tests.Comment #124
jproctorI just had a "how did this ever work" moment with #123 (and its predecessors): on a non-field-group element before the patch, it was finding
array('field_foo')
as the$dependent_location
and worked correctly; after the patch, it was gettingarray('field_foo', 'und')
, which wasn't working. Possibly something else changed in the new version of Field Group module?Attached patch removes the proposed change to line 514. It still works for me (in my dev environment, anyway) for field-group and non-field-group dependents alike.
Comment #125
AnybodyComment #128
giupenni CreditAttribution: giupenni commented#124 patch breaks user/NID/edit page.
Comment #129
anrikun CreditAttribution: anrikun commentedYou may also review patch at #1903226: When hiding all fields in a fieldset, the fieldset remains, but is empty. it should be hidden too. that hides fieldsets unless one of their fields is visible.
Comment #130
anrikun CreditAttribution: anrikun commentedThis is the continuation of patch at #1903226: When hiding all fields in a fieldset, the fieldset remains, but is empty. it should be hidden too. as that issue was just marked as duplicate.
This new version should work with nested fieldsets too.
Comment #131
anrikun CreditAttribution: anrikun commentedSorry, there was a useless part.
New version here.
Comment #132
sketman CreditAttribution: sketman commentedPatch #131 is working for me, thanks!
Comment #133
sketman CreditAttribution: sketman commentedComment #134
graytoby CreditAttribution: graytoby commentedPatch #131 is incomplete. It only covers the single case when fieldgroup type is set to fieldset. This has to work for all types.
Comment #135
forestmars CreditAttribution: forestmars commentedPatch in #131 is not working for me using 7.x-3.0-alpha2 or 7.x-3.0-dev.
Not sure why, if it was working per #132/#133.
Field group is of type fieldset. No errors in console.
Comment #136
SerkanB CreditAttribution: SerkanB at Bright Solutions GmbH commented#131 works for me using 7.x-3.0-alpha2, but indeed doesn't work with groups other than fieldsets.
But if you just have fieldsets... it's great :D thx.
Comment #137
danthorne#131 didn't seem to work for me. I ended up just writting a bit of jQuery to target exactly what I wanted to hide:
Comment #138
dodozhang21 CreditAttribution: dodozhang21 commentedSub...
Comment #139
MatthijsG CreditAttribution: MatthijsG as a volunteer commented#131 works, but not with -dev
If the fieldset has an description & is open, description and title is showed.
When collapsible, the fieldset react as expected.
Question, why only fieldset? I use mostly Div.
-edit: this patch is not in the latest -dev. I needed the latest dev, because the date-module gave some trouble (theme hook not found etc etc). Updating from Recommendend to -dev helped. But when installing the latest dev, the patch isn't working anymore .. argh
Comment #140
MatthijsG CreditAttribution: MatthijsG as a volunteer commentedWhen the patch 131 is installed, it breaks the CSS from TAC (and maybe CSS from other modules). See this issue (closed) https://www.drupal.org/node/2816543Wait, what .. now it's working good with the patch :-( I'm confused right now .. apparentely it's not breaking the CSS and i was wrong.
- edit 2 : however, patch #131 removes the date-field
Comment #141
igonzalez CreditAttribution: igonzalez commented+1
Comment #142
sdsheridan+1 on this for sure.
I was reviewing the patch in #124, and thought we needed a bit more regarding separating groups. The problem with the patch as I see it is there is a potential collision between field instance IDs and group IDs (i.e., a field instance and a group can have the same ID). So, we still need to differentiate between field and group dependents for this to work properly.
Without adding a column to the table, there is a way to use an attribute in options to do it. I've attached a patch against the latest dev (which includes the portions of the patch in #124, including the ones I had to do manually - the .module ones). This patch:
conditional_fields_load_dependencies
to explicitly separate the fetching of the dependent items and determine if they are field instances or groups, appropriately populating the correct one;conditional_fields_entity_view_alter
to hide entire groups upon display; andconditional_fields_hide_group
and_conditional_fields_get_all_progeny
to aid the hiding.The hiding on display works, but for some reason, I can't yet get the form to show and hide groups based on a dependee. Has anyone else got that to work?
Shawn
Comment #143
sdsheridanWhoops... left out a column in
conditional_fields_load_dependencies
. The attached fixes that. Also, was getting an undefined field_name error, so changed functionconditional_fields_form_after_build
to avoid that. However, still not getting my show-hide behaviour on the form... :(Shawn
Comment #144
guidot CreditAttribution: guidot commentedChanging to "needs review" to feed testbot.
Comment #146
TechNikh CreditAttribution: TechNikh commentedThe patch "conditional_fields-fieldgroup_support-1161314-143.patch" resulted in below error as reported by Drulenium visual regression test. Complete report at http://drulenium.org/projects/drupal-module-conditionalfields-7x-3x-desk...
Comment #147
sdsheridanOK, let's try this one...
Comment #148
sdsheridanComment #150
hkdorama CreditAttribution: hkdorama commentedWould be great if somebody got it working. This module really needs this feature...
Comment #151
yogeshmpawarComment #152
yogeshmpawarThanks @hkdorama, I have worked on this patch to get apply to latest 7.x-3.x branch.
Used #147 for reroll the patch.
Comment #154
iurisampaio CreditAttribution: iurisampaio commentedYogesh,
Your path doesn't work successfully.
It would be great if we have the feature/conditional as following:
if hide/show the group field, then all elements must inherit hide/show property.
Best wishes
Comment #155
roflcopterDorrie CreditAttribution: roflcopterDorrie commentedPatch #153 applies nicely to dev however it is throwing fatal errors for me.
Notice: Undefined property: stdClass::$array_parents in conditional_fields_field_group_build_pre_render_alter() (line 238 of conditional_fields/conditional_fields.module).
I looked through the arrays and group doesn't have an array_parents property in my case.
$parents = array_merge($group->array_parents, array($field_name));
The structure of my fields are:
- Vertical tabs group
- Vertical tab
- Field
Hope that helps to debug it
Comment #156
jordanddisch CreditAttribution: jordanddisch commentedApplied patch #152 to 7.x-3.x-dev. I was only able to apply the dependent to a horizontal tab with one tab. After applying the field was not recognised inside as a dependent and showed "()".
Upon editing a node with the field, the edit page gave me an error "The website encountered an unexpected error. Please try again later."
Comment #157
jordanddisch CreditAttribution: jordanddisch as a volunteer commentedComment #158
joelstein CreditAttribution: joelstein as a volunteer commentedI had the same "array_parents" error, but reading a bit further up, it looks like this patch depends on a patch to Field Group: #2494385-11: Should #array_parents be updated in field_group_fields_nest()?
Comment #159
AnybodyPatch #131 works good as quickfix, but sadly it hides hidden date fields (which have fieldsets as parents).
I solved that problem by adding a check for .field-group-fieldset:
Comment #160
AnybodyPatch #160 based on #131 as quickfix attached.
Comment #161
AnybodySORRY #160 is broken due to a git mistake I made. Correct quickfix version based on #131 concerning problem in #159 attached.
Comment #162
AnybodyI need holidays...
Comment #164
delacosta456 CreditAttribution: delacosta456 commentedhi the patch failed for me too
Comment #166
yogeshmpawarUpdated patch because #162 failed to apply on 7.x-3.x branch.
Comment #167
delacosta456 CreditAttribution: delacosta456 commentedhi @yogesh-pawar, i just apply the patch and it successfully applied .. however i can't see any of my fieldset group in both dependent and dependee list ?
Comment #168
AaronMcHale#166 works for me, thanks for the patch :)
Comment #169
AaronMcHaleIf a field group fieldset is collapsed by default on a form, even if it has visible elements inside it this patch will cause it the fieldset to be hidden from the form.
Comment #170
delacosta456 CreditAttribution: delacosta456 commentedhi @AaronMcH yes .. trully..
A work arround that worked for me , was to also set a kind of "visible" visibility rule for those field ,,, and so they stay visible with the fieldset while others a hidden...
Comment #171
Fool2 CreditAttribution: Fool2 commentedMy standard node form is messed up from applying only #166... Fieldset with standard node fields is automatically hidden when I open the page. This might be because there are no dependencies set on any of those fields.
Comment #172
totolearn CreditAttribution: totolearn commentedSame situation as #167, applied the patch #166 but not fieldgroup listed neither dependant nor dependee
Comment #173
yazzou CreditAttribution: yazzou commentedSame for me...it appears nowhere
Comment #174
mocasalter CreditAttribution: mocasalter as a volunteer commentedSame. Applied the patch from #166, still not seeing fieldgroups.
Edit: Or maybe the patch does kind of work? Fieldgroups aren't listed in the Dependency dropdowns, but if all of a group's fields are hidden by conditionals, then the group itself is also hidden. Without the patch, the group title and container still show even if its fields are all hidden.
Comment #175
karltud123 CreditAttribution: karltud123 commentedsubscribing
Comment #176
djdevinYes, that's what the patch in #166 does.
So if you set all your fieldgroup's fields to be conditional, the fieldgroup will disappear if there are no visible fields inside. Seems to work very well here!
Comment #177
oschuetze CreditAttribution: oschuetze commentedCould you please also add similar code for grouping via "div"? Something like
Comment #178
museumboy CreditAttribution: museumboy commentedPatch #166 worked for me however I needed to change
$wrapper = $wrapper.closest('fieldset.field-group-fieldset')
to
$wrapper = $wrapper.closest('fieldset.form-wrapper')
There is no 'field-group-fieldset' class called on my fieldset for some reason. Look at your html to see if the class exists.
Of course I could leave this code as-is and just add 'field-group-fieldset' as a class to anything I wanted hidden.
Comment #179
museumboy CreditAttribution: museumboy commentedIs there a nice way to rehide the fieldset if the child field is no longer checked?
Comment #180
museumboy CreditAttribution: museumboy commentedI've encountered two issues with #166.
1. This doesn't work if you're using a multipage group form. That is because the multipage is itself a fieldset. To better select the correct fieldset in #166 I've added changed:
var $wrapper = $(e.target).closest('.fieldset-wrapper');
to
var $wrapper = $(e.target).closest('fieldset.hideme .fieldset-wrapper');
I additionally have to include the fieldset.hideme class in the lower line:
$wrapper = $wrapper.closest('fieldset.hideme').toggle($wrapper.children('.form-wrapper:visible').length > 0).closest('.fieldset-wrapper');
This will only work if you add the class hideme to the fieldset in manage fields.
2. The fieldset will only disappear when you uncheck your dependant field if the Effect is set to show/hide. It will not disappear if you've selected fade in/Fade Out.
If you want the fieldset to fadein change this line:
$wrapper.parents('fieldset').show();
to
I hope this helps anyone troubleshooting.
Comment #181
shenzhuxi CreditAttribution: shenzhuxi commentedWith current conditional_fields module, If DEPENDENT is a required field, it can be skipped if it's not visible by DEPENDEE (https://www.drupal.org/project/conditional_fields/issues/1561272).
With patch #152, if DEPENDENT is a field group with required fields in it, the form will not pass the validation if the fields are not visible.
To make patch #152 pass the test, you need to put field_group module to conditional_fields.test file
parent::setUp('conditional_fields_test', 'list', 'text', 'number', 'taxonomy', 'image', 'field_group');
Comment #182
TLWatsonHere is a patch along the lines of #166. The way I wrote it:
It is written for the fieldset group type, dependent on the 'field-group-fieldset' class (which is on fieldsets by default, but you are able to remove). Unfortunately there is no catch-all element or class that will work for every fieldgroup or setting.
Comment #183
miksha CreditAttribution: miksha commented@TLHenriksen I have applied only your patch and the behavior I get is next: When I have few fields under fieldset, and e.g. one of them is hidden based on field condition that is outside of the fieldset, whole fieldset is not shown at initial form view. Then when I check option that triggers the hidden field to be shown, the fieldset and the rest of the field are shown. Choosing another option then hides only field that should be hidden from within the fieldset, and fieldset and the rest of the fields that should always be visible, remain visible as they should.
Comment #184
yzan CreditAttribution: yzan commentedHello,
+1
This module will become bigger the day of adding this feature ...
Good work!
Comment #185
calefilm CreditAttribution: calefilm as a volunteer commentedhello @miksha,
It would be helpful if you were more precise in your setup... with actual field labels and fieldgroup labels and outcome of each input. Thanks
Comment #186
W01F CreditAttribution: W01F commented+1 for D8 support for the same
Comment #187
Publishing Future CreditAttribution: Publishing Future commented+1 for D8 support for the same
Comment #188
PanchoWhy is this feature request still in the D7 branch anyway?
Comment #189
tim-dielsLatest patch (#182) is working but you need to make sure the class 'field-group-fieldset' is present on the fieldgroup. I had to add them myself trough the view display, as latest version of fieldgroup does not prints out the class or this is project specific. So not sure if the patch is 100% correct, but working for me.
Comment #190
geefin CreditAttribution: geefin commentedIs this working with Vertical Tabs? I've done all the patches and sub-patches and I receive no errors, no console errors and can set the dependencies. However, it doesn't show/hide the vertical tabs, only fieldsets and individual items.
Comment #191
coreteamvn CreditAttribution: coreteamvn commented#51 and 53 didnt work, but the suggestion in #97 (adding the id) finally worked
Comment #192
justcaldwell#182 worked great for me (thanks @TLHenriksen!), and applied to -alpha5 just fine. (I couldn't replicate the problem described by @miksha in #183)
I'm using field_group-8.x-3.0-beta1. Seems like that version does output the
field-group-fieldset
class by default, because I didn't have to add it (re: #189).Comment #193
marieAscomedia CreditAttribution: marieAscomedia commentedI'm using field_group-8.x-3.0-rc1 and conditional_fields-8.x-1.0-alpha5 and I'm not able to see any group in the 'target field' on the page 'manage dependencies' of my content type.
I have tried to adapt patch #152 but it doesn't change anything.
How do you achive that ?
Comment #194
Andrew Answer CreditAttribution: Andrew Answer as a volunteer commentedRe-rolled patch #182 to the last version of module and tested it with field_group-8.x-3.0-beta1. Important note: if you use "required" fieldset you have class "field-group-fieldset", but if you disable "required" checkbox, you need to add that class in Extra CSS classes.
Comment #195
colanThis behaviour isn't very intuitive, having to select each field group's children in the "Add new dependency" field. It also gets very complicated with nested field groups.
Can we redo this to actually list the field group names for selection in the "Add new dependency" field?
If this should really be done in the other module, then let's add any missing hooks that would be needed.
Comment #196
agudivad CreditAttribution: agudivad as a volunteer and commentedUploaded patch for alpha6 version.
Comment #197
agudivad CreditAttribution: agudivad as a volunteer and commentedComment #198
ergonlogicOn complex entity forms, the Conditional Fields configuration can quickly get unwieldy. To @colan's point, it's unintuitive to have to set conditions on each field inside of a field group, to achieve what should be fairly straight-forward. Does the Form States API not work with field groups, or something?
At least when it comes to visibility, it seems to me that we should be able to just set the desired states on field group fields. If this doesn't achieve the goal of also controlling the visibility of child elements, we should be able to iterate over those elements in
ConditionalFieldsFormHelper::afterBuild()
and apply the same state to the field group's children.I guess the first step would be to confirm the behaviour of the Form States API when trying to set the visibility of a field group.
Comment #199
ergonlogicIn the attached patch, we basically just add groups to the list of fields available in the "Target field" and "Control field" lists. We also had to tweak the validation callback a bit, since group objects aren't full fields, and thus don't have an
isRequired()
method.Comment #200
colanComment #201
ergonlogicSince the tests for #199 pass on the D8 stable release, and fail similarly for a JS-only patch (#197), I'm pretty sure those failing tests are not directly related to anything in this patch.
In a offline discussion w/ @colan, we agreed that it'd be worthwhile to try to implement some form of "inheritance" for fields inside of field groups. Basically, the way this would work is as follows:
field_group
elements cannot be selected as either a "target" or a "control" field.field_group
elements can be selected as either a "target" or a "control" field.field_group
element is selected, provide a checkbox with something like "This element contains other fields. Apply these settings to the contained fields instead of this one."field_group
elements (usingmodule_exists()
), turn that into a hook that'll allow any module to register new type of "target" and/or "control" fields.Comment #202
ergonlogicI added #3099051: Conditional Fields support for the hook implementations in field_group that'll be needed for the re-factoring mentioned in #201.
Comment #203
ergonlogicThis patch moves the generation of the list of fields into a hook, and then implements the hook on behalf of the core Fields module. This will allow a similar patch in #3099051: Conditional Fields support to do likewise for
field_group
.Comment #204
colanCode looks good; here are some minor formatting notes:
Would be good to add a line break before the `@return`.
Let's break this up; one per line.
Comment #205
ergonlogic@colan I've fixed the style issues, per your comment.
Currently that behaviour remains mostly unchanged from #199. That is, instance of group fields can be selected as both dependent and dependee in conditional field relationships.
The only visible change since then is the addition of an "Inheritance" field on conditional fields config forms. This is basically just a checkbox labeled "Propagate settings to fields contained within this one.". Its description reads "This element contains other fields. Apply the settings in this form to the contained fields instead of this one."
That said, under the covers, I've refactored how dependencies are resolved to be OOP, while maintaining identical behaviour and data structures. With that now in place, we'll finally be able to move on to implementing the behaviour that the new setting promises.
The last patch, from #203, failed to apply, since it builds on the patch in #3077803: Make ConditionalFieldsFormHelper class instantiable. As such, the patch attached here includes those changes, until such time as that's merged into the 8.x-1.x branch.
For those following along at home, you can use the issue-3099051 branch from our fork of field_group, along with the issue-1161314 branch from our fork of conditional_fields, to test the new behaviour.
Comment #206
ergonlogicThis patch (finally) introduces the inheritance of Conditional Field settings to fields contained within Field Groups. It introduces 2 hooks useful for enabling this functionality (along with their corresponding
_alter()
hooks):I'll upload a patch to #3099051: Conditional Fields support shortly that implement these.
Next steps are to get some testing/feedback, and add a couple enhancements that I've noted as
@TODO
s in the code:Comment #207
ergonlogicThis patch resolves the remaining TODOs listed in #206. That is fleshing out inheritance behaviour.
I also traced how and when dependencies are resolved, and determined that the we currently always call this with a bundle. As such, I was able to simplify the code somewhat. The legacy code implied that we'd sometimes be returning all dependencies for an entity type, or even all dependencies across all entity types and bundles. Should we ever need this functionality, we can now build it up by iterating over individual bundles,
Comment #208
ergonlogicI re-rolled this patch to apply atop the one in #3077803: Make ConditionalFieldsFormHelper class instantiable, as that should be merged soon. The inderdiff I've uploaded here compares the current patch against the one in #203.
Comment #210
colanThe other issue is now in, and this one now passes tests. This still needs manual testing, but here's a code review.
Typo.
"children" -> "child"
Shouldn't these be boolean?
Dependency injection would be nice, but let's save that for a follow-up.
Comment #211
ergonlogicFixed typos (#1 & #2).
Re. #3, No, 'string' is correct there. I know it's counter-intuitive, and this had me scratching my head for a while. But values of checkboxes are an array of strings, where 'checked' is represented by the key name, and unchecked is 0.
Re. #4, agreed, it'd be nice, but can come later.
Comment #212
liquidcms CreditAttribution: liquidcms commentedThis sounds awesome guys; but can someone suggest what is all required here? I assumed the forks of both modules pointed to in #205 is updated with all the patches. Using these i had expected to see my Field Groups listed under Manage Dependencies -> Target Field.. but no luck.
Is there some other combination of forks/patches required here?
Comment #213
colanissue-1161314
branch instead.Those forks aren't necessary anymore as @ergonlogic is now a maintainer and can push branches.
Comment #214
liquidcms CreditAttribution: liquidcms commentedThanks Colan, yes, getting -dev for both and applying latest patch to each, does work. :)
Getting 2 forked versions doesn't work.
Comment #215
liquidcms CreditAttribution: liquidcms commentedPerhaps i spoke too soon. I was just happy to see the Field Group listed in the Targets; but when adding a dependency i get:
Notice: Undefined index: group_additional_coverages in Drupal\conditional_fields\Form\ConditionalFieldForm->validateForm() (line 170 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php).
but does seem to be working. :)Comment #216
liquidcms CreditAttribution: liquidcms commentedI am now seeing this Notice on the main Manage Dependencies page, the dependency setting page as well as the node entity form.
Notice: Undefined index: 9f8deb7c-f0df-422f-a95c-4f8fcc478a2c in Drupal\conditional_fields\DependencyHelper->getInheritingFields() (line 144 of modules/contrib/conditional_fields/src/DependencyHelper.php).
Comment #217
liquidcms CreditAttribution: liquidcms commentedalso, this doesn't work for ORed fields.
2 different Control fields (checkboxes) set to show a field group as visible; but only 1 of the set of checkboxes shows the field group.
Comment #218
liquidcms CreditAttribution: liquidcms commentedComment #219
Kris77 CreditAttribution: Kris77 commentedThis is what I did:
As well as @liquidcms, when adding a dependency I get this Warning/error:
"Undefined index: group_xxxxxx in Drupal\conditional_fields\Form\ConditionalFieldForm->validateForm() (line 170 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php)."
but it still works.
Comment #221
colanThis latest patch fixes #215/#219.
Things seem to work well in my tests, but we're not using OR (#217).
Temporarily setting to Needs Review to trigger the testbot, but this needs to go back to Needs Work afterwards.
As this now works for our purposes, we won't be doing any more on this right now. So, anyone else, feel free to continue the work here for fixing #217 (or anything else that may not be working yet).
As this refactoring lays the groundwork for handling other types of groups (e.g. Paragraphs), we should postpone those other issues on this one. I'll do that for the ones I can find, but please do so for any others I've missed.
Comment #222
colanAdded "Remaining tasks" to IS.
Comment #223
kreatIL CreditAttribution: kreatIL as a volunteer commentedFinally got the patches working, which is the latest patch from #3099051: Conditional Fields support and the latest patch from this issue.
Now I see the Fieldgroup elements of the form display in the list for the target field. But the Fieldgroup elements of the frontend displays are still missing. In Drupal 7 there was no separation between edit form and frontend displays. But the functionality of this module was there for Fieldgroups also on the frontend side.
@colan, @liquidcms, @ergonlogic, @all:
What else would have to be done to be able to address the Fieldgroup elements on the frontend displays as well?
Comment #224
colan-
Comment #225
colan#223: When you say "frontend displays", are you talking about what shows up on the content View tab (not the Edit tab), that which is controlled by the Manage Display tab in Structure -> Content types?
If so, that's a separate issue: #3009641: Fields that are hidden on node form show up on node display.
Comment #226
colanHere's a reroll for the latest HEAD (and today's new alpha release). Sorry; there's no interdiff as the different baselines are causing the command to fail.
As I started working with nested field groups, I ran into this, which you may notice if you're doing the same thing. This was happening in the previous patch as well:
I'll dig into it shortly.
Comment #227
nuezI've tested this and with the two patches mentioned above for both modules it seems to work correctly with field groups in just one level.
However it doesn't seem to work entirely when there are multiple levels of groups, e.g:
- Tabs
-- Tab A
--- Control field 'test' (select list with Yes/no)
-- Tab B
--- Target field
I create one dependency with target field 'Tab B' and the control field 'test'. I check all the boxes for propagating the settings to the fields contained within the tab.
After selecting the right option in the control field, the target fields appear in the field group 'Tab A'
I hope the screenshot helps.
Comment #228
colanUpdated remaining tasks in the IS.
Comment #229
colanThis should fix #226.
Comment #230
nuezThanks for the work on this!
I've also found that when you create a target field group of type 'HTML Element' with 'Show label' set to TRUE (H3 element) that the label always shows, even though the rest of the field group is hidden.
Comment #231
colan#230: Please add that to the issue summary (IS).
However, it's starting to look like there are a lot of edge cases and this issue is already quite long. Maybe we should rename it to "Add basic Field Group support", commit the above patch (assuming there are no major problems and someone other than me RTBCs it), and then we create a follow-up meta issue for everything else? Thoughts? Otherwise, we're never going to get this in.
Comment #232
Squiggles CreditAttribution: Squiggles commentedThis feature is a Godsend! Thank you, and looking forward to the stable release.
Comment #233
delacosta456 CreditAttribution: delacosta456 commentedhi @colan
i agree with your idea.
Comment #234
colanThanks for the feedback.
Please create new tickets for the follow-ups I've listed in the IS. I've narrowed the scope here.
Let's see if we can get tests working, and then we can commit. There are some failures related to this issue (I may have used some too-recent PHP features), but the branch is also failing. See #3134183: Functional JavaScript tests are failing for details; help from front-end folks would be greatly appreciated.
See https://www.drupal.org/pift-ci-job/1676469 for what's left to fix here.
Comment #235
nuezI don't understand enough of the patch provided in #229 to really properly review it, but I've found the following:
This assumes that the only one DependencyHelper for one entity type and bundle is needed per request.
If we are to support inline_entity_form we need to change this so it's statically cached for different entity types / bundles.
See https://www.drupal.org/project/conditional_fields/issues/2856720#comment...
ConditionalFieldTextTextareaTest::testVisibleValueXor() fails in the testbot but not locally. I doubt if it's related.
Comment #236
colanThanks for the review. Updated IS.
Comment #237
nuezComment #238
mparker17I've re-rolled the patch from #229; but haven't made any other changes, so there is no interdiff.
Comment #239
DesignWork CreditAttribution: DesignWork as a volunteer commentedI can help with the testing, what is needed?
Is this patch already applied to dev?
Cheers
Dirk
Comment #240
colanPlease test and review the code. Once successful, then we can commit it. Thanks!
Comment #241
mparker17Looks like Testbot is running with Drupal core's minimum system requirements (as of 8.7.0), i.e.: PHP 7.0, which doesn't support nullable argument specifiers, e.g.
?string
So here's a patch that is compatible with 7.0. I added a docblock to the function so development environments will know the argument must be
null|string
.Anyone who wants to help, please read / review the patch and provide feedback, and also test the patch and report if it works. If it passes your code review and tests seem to indicate it is working, then you can mark it as RTBC and the module maintainer(s) can commit it.
Comment #242
mparker17Not exactly how I got that wrong; but here's the patch from #241 re-rolled onto commit
1d4c7ac
Since this is a re-roll with no changes, there is no interdiff.
Comment #243
sassafrass CreditAttribution: sassafrass commentedThank-you to all for contributing! Very much appreciated!
I am testing using the following:
Drupal core 8.9.8
Field Group 8.x-3.1
In my composer.json:
"drupal/conditional_fields": "1.x-dev@dev"
Comment #244
josephleon CreditAttribution: josephleon at Consensus Enterprises for Health Canada - HPFB commentedI tested the patch from #242 and everything worked. I had a field group of type "Details" which had 2 "Controlled by" fields. One was a select list and the other was a text field, both pointing to the field group using the AND condition. When I select the proper value and input data to the text field the field group will show. Initially the field group is hidden.
Comment #245
josephleon CreditAttribution: josephleon at Consensus Enterprises for Health Canada - HPFB commented@sassafras I see you are using a dev version of conditional fields. In my composer.json I am using "drupal/conditional_fields": "^1.0" and it works. Also my patch is setup differently from yours:
Also have you updated composer?
Comment #246
josephleon CreditAttribution: josephleon at Consensus Enterprises for Health Canada - HPFB commentedComment #248
colanThanks all!
I'm fine with moving that final future-proofing subtask to #2856720: Support for Inline Entity Form, as that's where it's actually needed. Comment added over there.
Comment #250
welly CreditAttribution: welly commentedI'm wondering if this only works on certain field group types because the "Detail" field groups I'm using doesn't display in the "target" select list.
I think I must be misunderstanding what this patch does but I was under the impression that the "target" drop down would list field groups as well as fields and you could trigger the visibility of the group based on another field?
Comment #251
Kris77 CreditAttribution: Kris77 commented@welly you have to apply this patch for field_group module: https://www.drupal.org/project/field_group/issues/3099051
Comment #253
ethanbb CreditAttribution: ethanbb as a volunteer commentedIs this still a problem for some field group widgets, specifically tabs?
I'm using Conditional Fields 4.0.0-alpha1 and Field Group 3.2.0. I selected a group displayed as tab as the dependent and a field from another tab as the dependee, and under inheritance I have "Propagate settings to fields contained within this one" and "Apply these settings to the this (parent) field also" selected.
This is what I see in the inspector - content of the tab is hidden with the data-drupal-states attribute (first image). But the tab itself has no such attribute (second image).