CCK fieldgroup will manage nested fieldgroup (see
Would be nice to be compatible with this feature.

#80 conditional-fields-nested-fieldgroups-650008-80.patch38.6 KBermannob
#74 conditional-fields-nested-fieldgroups-650008-74.patch39.92 KBpeterpoe
#68 conditional-fields-nested-fieldgroups-650008-68.patch39.35 KBpeterpoe
#67 conditional-fields-nested-fieldgroups-650008-67.patch39.2 KBpeterpoe
#59 conditional_fields-6.x-2.x-support_nested_fieldgroups-10.patch18.53 KBthekevinday
#59 conditional_fields-6.x-2.x-support_nested_fieldgroups-11.patch19.15 KBthekevinday
#55 conditional_fields-6.x-2.x-support_nested_fieldgroups-9.patch18.44 KBthekevinday
#53 conditional_fields-6.x-2.x-support_nested_fieldgroups-8.patch18.29 KBthekevinday
#47 conditional_fields-6.x-2.x-support_nested_fieldgroups-7.patch15.95 KBthekevinday
#43 conditional_fields-6.x-2.x-support_nested_fieldgroups-6.patch16.01 KBthekevinday
#37 conditional_fields.patch4.35 KBMarcElbichon
#38 conditional_fields.patch4.45 KBMarcElbichon
#32 managed_field_form.jpg42.17 KBMarcElbichon
#32 conditional_fields.module.rej_.txt851 bytesMarcElbichon
#26 conditional_fields-6.x-2.x-support_nested_fieldgroups-5.patch12.52 KBthekevinday
#25 conditional_fields-6.x-2.x-support_nested_fieldgroups-4.patch8.58 KBthekevinday
#16 conditional_fields-6.x-2.x-support_nested_fieldgroups-3.patch8.22 KBthekevinday
#14 conditional_fields-6.x-2.x-support_nested_fieldgroups-2.patch8.56 KBthekevinday
#13 cck_conditional1.png12.9 KBhumble
#13 cck_conditional2.png13.15 KBhumble
#12 conditional_fields-6.x-2.x-support_nested_fieldgroups-1.patch8.44 KBthekevinday
#6 conditional_fields-6.x-1.x-support_nested_fieldgroups-2.patch9.76 KBthekevinday
#5 conditional_fields-6.x-1.x-support_nested_fieldgroups-1.patch9.93 KBthekevinday



+1 subscribing


+1 subscribing

Version:6.x-2.x-dev» 6.x-1.x-dev
Status:Active» Needs review
new9.93 KB

I am interested in this as well.
Given that there is little or no activity, I did this myself.

Here is a patch that adds support to conditional fields for nested fieldgroups.

Please Review and confirm that there are no mistakes.

I am not using 2.x and this patch is against 1.x, so for the time being I am moving this to the 1.x-dev branch.

Version:6.x-1.x-dev» 6.x-2.x-dev
Status:Needs review» Active
new9.76 KB

I forgot to remove a debug statement.

I also update the added functions comment to explain itself more precisely.

Version:6.x-2.x-dev» 6.x-1.x-dev
Status:Active» Needs review

Interested in this too, although I'm running 6.x-3.x-dev

If I can find time (and work out how) I will try to test and review.

Is it working ok?

Version:6.x-1.x-dev» 6.x-2.x-dev

I seem to keep bouncing the version around for this. Mostly by accident? I don't remember.

Either way, I need to pay attention to the developers notes on the 2.x-dev version, which mentions adding support for nested fieldgroups.
In fact, this is mentioned as added and done.
See #4:

Does this mean that this bug report should be closed?

FYI: my patch is against the 1.x series.

#9: Nope. That note was referring to nested conditions not nested fieldgroups. Will review your patch as soon as possible (sorry for the lag).


I am now questioning my interpretation of the original post.
My patch fixes the problem where conditional fields do not work properly when used within nested fieldgroups.

What I am wondering now is should fieldgroups themselves be treated as a conditional field as a controlled field?
Alternatively, should the first level of fields in a fieldgroup be possible controlled fields?


Group 1
- Field A (Controlling Field)
- Field B (possible controlled field)
- Group 2 (possible controlled group)
- - Field C
- - Field D
- - Group 3
- - - Field E
- - - Field F

Example (alternative):

Group 1
- Field A (Controlling Field)
- Field B (possible controlled field)
- Group 2
- - Field C (possible controlled field)
- - Field D (possible controlled field)
- - Group 3
- - - Field E
- - - Field F

If that is the case, then my patch is only step 1 in adding nested fieldgroup support.

I decided to test out conditional fields 2.x-dev.

I still needed to patch conditional fields with this patch.
However, there were quite a number of differences so here is a brand new patch for the 2.x-dev series.

I have only just started testing this, so please review this 2.x-dev patch.

I have also confirmed that the 2.x-dev series is more stable when it comes to nested fieldgroups and fields within them.
One of the bugs I mentioned here: does not appear in the 2.x series (so far..).

new13.15 KB
new12.9 KB

I am experiencing display interaction problems between this module and the cck_select_other module ( ). This module produces a fieldset and the conditional action is not suppressing the display of the fieldset (see attached images that show the two conditions). It _may_ be the same problem that is happening here.

I'm using the latest dev versions of both and have applied the patch (above).

Also going to post it as a separate bug...

I fixed a bug with the fieldgroup where I was not checking to see if a given variable was en empty string or not before passing it to array_key_exists().


This resyncs the patch with the latest version: 2.0-beta1

Hello @thekevinday. Please can you confirm if this patch supports all the recent work you did for multigroup too? Thanks.

I can confirm #17 supports all of the recent work I have done for multigroup.
(However, I have not solved all of multigroups problems).

The patch applies fine, but for some reason, it does not find possible controlling fields.

Edit: My bad. I misconfigured my fields.

Patch works great for node editing. But untriggered fields are always shown is node view. Am i wrong ?

I do not know what the default behavior for conditional fields node view is.

I can imagine cases where I would want untriggered conditional fields to not show up as well as imagine cases where untriggered conditional fields should show up.

I can see that being a separate bug report (or feature request?) unless the patch I supplied here changes the default behavior of untriggered conditional field visibility in node views.

Standard behavior hides untriggered fields in node view (see Comment in the Conditional field settings fieldset), or try to create controlled fields outside a fieldgroup.

In the last case, fields outside a fieldgroup are not triggered in node editing.

+1 subscribing

I have been having problems with the Date field and conditional fields.
While looking around for existing posts, I found this:

After looking at the patch provided there I noticed that it is in a few important areas identical to my fix here.

The patch there does not apply cleanly to 2.x because it appears to have already been partially committed.
One of the parts that wasn't committed is pretty much what my patch here is doing.

There are still parts that were not committed and are not identical to my patch.

Looks like the problems #20 might be because of some typos.

Apparently, when copied some repeated code, I forgot to change controlling to controlled.
This updated patch fixes those problems and is highly recommended.

I am currently researching problems with conditional fields and required fields. (I am not certain if it is a problem with nested fieldgroups, normal conditional fields, or something with my patch.)

Please review and look for any mistakes in the patch.

Almost before my day ended I managed to get the required fields working under nested fields.
There are some additional problems I will need to discuss (including a bug report in drupal core), but this gets things working.
I will follow up with details on the core bug (by making and referencing a bug report) when I get the chance.

With this latest patch, I have made the following changes:
- during the content_add_more_js case for form_alter, nested fieldgroups were not being processed, so now it does
- fixed a problem where conditional_fields_custom_required_field was not being called in the conditional_fields_node_after_build function
- the conditional_fields_node_editing_form_validate function did not handle nested fieldgroups, so not it does.
- the conditional_fields_custom_required_field function was changed to explicitly check that the '#required' field was set
- the conditional_fields_custom_required_field was changed to only attempt to recurse into arrays

A bug report in core has been opened here:

This is to address an issue with drupal core that happens when a conditionally required radio button has no field set to it (because it is not being required because of the status of a controlled field)

#25 patch doesn't fix #20

Perhaps I am misunderstanding the problem with #20.

Are you saying that you expect the untriggered fields to be visible?

I believe the default behavior, as explained in #22, is to hide all untriggered fields during node view.

I have confirmed this with all three settings work properly:
- Don't use javascript. Fields are only hidden on node view.
- Hide untriggered fields.
- Disable untriggered fields.

I managed to reproduce exactly 1 case where untriggered conditional fields should display but do not.
When "Administrators see all fields" is enabled, the untriggered fields do not show when they should.

I will probably have to parse this variable somewhere during node view.

If this is not your problem then you need to be more descriptive in your situation.

I will get to solving this "Administrators see all fields" problem as soon as I can.

I want to hide untriggered fields during node view (default behavior) but this doesn't work when field is in a nested group.
Works if field is not in a fieldgroup during node viewing but in this case this doesn't work during node editing !

I've applied patch 5 to 2.0Beta1

Have you applied the latest patch for cck nested fields from here: ?

Is the field controlling field inside the nested group that the controlled field is in?
Please give a structured example like:

- [field_title]
- [group_1]
-- [group_2]
--- [controlling_field_1]
-- [group_3]
--- [controlled_field_1]

I have fields in nested groups that do hide when untriggered, so we will need to figure out what is different about your build that causes it to not work for you.

new851 bytes
new42.17 KB

I'm lost with all these patchs ! I 've had a reject when applying #26 on beta1 (see txt file)
My exemple (see image of managed field form):

- [field_title]
- [group_1]
-- [group_2]
--- [controlled_field_1]
-- [group_3]
--- [controlling_field (controlled_field_1 onvalue A, controlling_field on value B)]
- [controlled_field_2]

During node Editing :
controlled_field_1 is hidden/visible when value of controlling_field changed
controlled_field_2 is always visible

During node viewing :
controlled_field_1 is always visible
controlled_field_2 is hidden/visible according to controlling_field value

Thanks for your help

The patch is against the 2.x-dev and not the beta1.

I use the -dev version because it fixes an important bug:
" Correctly reset untriggered fields to their default values."

There is also the following fix:
" Avoid error in js if controlling field is present but there is no controlled field"

You can see a log here:
Everything after February 17, 2010 is probably what is in the -dev version

Your problem may already be solved in the latest version.

Try the 2.x-dev version with the patch and report if the problem goes away or not.

No changes. Sorry !

I use cck 2.x

In conditional_fields_item_in_form, field not in fieldgroup are not triggered during node editing.

I've replaced

if ($group) {
    if (
$haystack[$group][$item_name]) {
$items[$item_name] = $haystack[$group][$item_name];
    elseif (
$haystack[$group][$form['#field_info'][$item_name]['display_settings']['parent']][$item_name]) {
$items[$item_name] = $haystack[$group][$form['#field_info'][$item_name]['display_settings']['parent']][$item_name];
  else {
    if (
$haystack[$item_name]) {
$haystack[$item_name] = $haystack[$item_name];
    elseif (
$haystack[$form['#field_info'][$item_name]['display_settings']['parent']][$item_name]) {
$items[$item_name] = $haystack[$form['#field_info'][$item_name]['display_settings']['parent']][$item_name];


if ($group) {
    if (
$haystack[$group][$item_name]) {
$items[$item_name] = $haystack[$group][$item_name];
    elseif (
$haystack[$group][$form['#field_info'][$item_name]['display_settings']['parent']][$item_name]) {
$items[$item_name] = $haystack[$group][$form['#field_info'][$item_name]['display_settings']['parent']][$item_name];
  else {
// REPLACE HAYSTACK BY FORM because field in not in $FIELDSET
if ($form[$item_name]) {
$items[$item_name] = $form[$item_name];
    elseif (
$haystack[$form['#field_info'][$item_name]['display_settings']['parent']][$item_name]) {
$items[$item_name] = $haystack[$form['#field_info'][$item_name]['display_settings']['parent']][$item_name];

to make it working.

For problem in node viewing , i think line below in nodeapi hook only checks one fieldgroup and not nested fieldgroup

if ($controlled_group && !$node->content[$controlled_group]['group'][$field['field_name']]) {

So if i get everything right the situation is approximately like this.

Conditional Fields module:
version 6.x-1.1= this works with fields that are in the same group and that's all.
version 6.x-2.0beta1 = in this version the fields can be in different groups as long as they are in the same level of depth

So when you need groups to be nested and you install Nested Fieldgroups patch for the CCK module everything stop working.

My situation is like this (running CCK3 with Nested Fieldgroups patch + Conditional Fields 2.0beta1):


My "field1" should control the popping out of the entire GROUP 2 o 3 (so practically "field2" and "field3" or "field4" and "field5"). I tried to do this but it just doesn't work.

Should i try the 6.x-2.xdev version of these module and apply the patch-5 again??

EDIT: ok i didn't catch the part where it was stated that the patches are for the dev release and not the beta1; i'll procede trying with the dev version of Conditional Fields and let you know :)

EDIT2: it works...the controlled fields are properly triggering when i act on the controlling one. Though, in my specific case, the group doesn't disappear when every controlled fields in it are hidden because of the settings.

new4.35 KB

The patch would correct #20. It must be applied after #26

EDIT. Buggy patch. Do not use it. Use #38

new4.45 KB

Sorry. Bug in patch #37. Please this one

For the first solution in #35:

The following:

= $form;
  if (
$haystack = $fieldsets;
  if (
$group) {

Haystack already is $form in the event that the passed fieldsets is NULL..

Given what you said this means that group can be empty while fieldset is not NULL.

I am not sure how this happens because much of this is trial and error for me as well.

I think it may be better to to check to see if the given item_name is in the form haystack before the haystack gets switched to the fieldsets.

This would be the following:

= $form;
  if (
is_array($fieldsets) && !in_array($item_name, $haystack)){
$haystack = $fieldsets;
  if (empty(
$group)) {

Note: I also switched the if ($group) test to call the empty() function.

Do you happen to know if your patch solves the problem I discovered in #29?

Thanks for the patch, its good to know I am not the only one trying to solve this problem upstream.
I will be reviewing your patch for now.

Your code #39 works but i had to replace in_array() by array_key_exists().
Which version of PHP do you used ?
I'm using PHP 5.2.6.
In patch, i've replaced empty() function by $value[$field_key[0]] != "" because i have CCK fields with 0 as value which is considered as empty by the function.

#38 patch corrects #32 behavior
For "Administrators see all fields", this works during field viewing but not during field editing (normal way ???)

In the node view if a fieldset has all hidden fields because they are not triggered the fieldset is not shown.
Instead in the node edit the fieldset appears with the title but is empty.
I just found it out and, in my particular case, that's enough to have the fieldset not shown in the node view; it's not that much important for the node edit.

thanks for catching that accidental reverse logic with in_array and array_key_exists().

I use php 5.3.
Double checking the PHP docs:
I guess it will have to be an == "" test.

Thanks for the clarification.

I noticed some other spots where I added empty() in the pretense that "0" would not be considered an empty string.

Here is the latest patch with MarcElbichon's fixes.

Patch works fine for me.
Many thanks

Status:Needs review» Needs work

Patch won't apply with latest dev.

patching file ./conditional_fields.module
Hunk #6 succeeded at 647 (offset -1 lines).
Hunk #7 succeeded at 703 (offset -1 lines).
Hunk #8 succeeded at 717 (offset -1 lines).
Hunk #9 succeeded at 739 (offset -1 lines).
Hunk #10 succeeded at 769 (offset -1 lines).
Hunk #11 succeeded at 798 (offset -1 lines).
Hunk #12 succeeded at 820 (offset -1 lines).
Hunk #13 succeeded at 879 (offset -1 lines).
Hunk #14 succeeded at 934 (offset -1 lines).
Hunk #15 succeeded at 946 (offset -1 lines).
Hunk #16 FAILED at 958.
Hunk #17 succeeded at 1354 (offset -1 lines).
Hunk #18 succeeded at 1462 (offset 14 lines).
1 out of 18 hunks FAILED -- saving rejects to file ./conditional_fields.module.rej

I did apply the patch manually, but this doesn't seem to work with CCK 3.x-dev Multigroups. I have a field that I want to show or hide in the multigroup that isn't required, but conditional fields is saying that the field is required.

warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /mysite/sites/all/modules/conditional_fields/conditional_fields.module on line 825.

Status:Needs work» Needs review
new15.95 KB

The most recent version made some significant changes in the areas where this patch is applying.
What you are seeing may be a new bug introduced by the changes.

Here is the patch rediffed against the latest version.
Please test this and confirm whether or not your problem mentioned in #46.

Status:Needs review» Needs work

Patch applied ok, but I had to tell it which file to patch. I still have the same error on the node/add/* page with conditional field. I figured out though that my problem is a little different. The field that is throwing the error is a required conditional field but it is not part of the multigroup. It seems that the variable its looking for should be a string or integer but it is instead a boolean.

The field that is a part of the multigroup that is being controlled by another field is not getting any of the conditional field IDs or classes though and it isn't hiding/showing based on its controlling field. It seems as though that maybe the theme function or js is not working.

It does allow me to change the settings in fields under the multigroup and make them conditional, but there is no visible change on the node/add form.

Just so you know the code still works, but that warning happens. My guess is that since it isn't in a group there is a false there and the code isn't prepared for a false value.

So here is the issue at hand. Multigroups do not use the same structure as fieldgroups so the conditional_fields_item_in_form function doesn't find the form element since it is not in the root of the group. In fact it doesn't seem like the form element is even there at all. There are a couple places that it looks like it might be but it is slightly different than a regular form item in the $form element.

Sorry about the patch, I did my habitual way instead of the drupal way of generating the patch.
You will have to change to the conditional_fields folder and pass -p1 to the parameter. (ie: cd conditional_fields ; patch -p1 -i ../conditional_fields-6.x-2.x-support_nested_fieldgroups-7.patch)
I will try to correctly generate the patch on the next submit.

My patch adds the function conditional_fields_node_editing_form_get_fieldgroups().
It tries to walk through the form structure to find where the groups are and then puts them into a single depth array called fieldsets.

What may be happening is that some of the newer code released with beta2 added some things that need to be changed to check the fieldsets array instead of the form array directly.


I can confirm that this patch does allow a field to control fields inside of standard groups, but it is not working for CCK 3.x multigroup fields. I've been trying to figure it out but the best I can show right now is that the fields are not found because they are created differently. I don't know if this patch is intended to work with multigroups, but this is the closest issue I came across for it.

The attached patch helps improve multigroup support.

This patch is not a complete fix, it seems that the conditional fields javascript will need to be rewritten or altered to handle the unusual multigroup cases. If anybody is interesting in doing this, I can explain approximately what needs to be done.

Let me explain the changes in this patch.

1) I discovered that multigroups does not store its child fields in the same location as a normal fieldset.
- multigroups stores its children in the sub-array: '#group_fields'
- the code has been modified in a number of places to handle this case where found

2) apparently there is some sort of 'conditional group' support present but it does not look like it was completed.
- I am not entirely certain of this, but what I did notice is that the function conditional_fields_item_apply_theme() accepts a second argument that tells the theming engine to do a special conditional group theme capability
- The functionality is there, but is not being used as far as I noticed so I altered the code to pass the second argument if the conditional field is a group
- I do not know how to utilize or trigger this; however, the functionality is now present

Please review that this patch does not break anything.
Do not expect this patch to solve the multigroup problem as that one requires a change to the javascript at the very least.


Nested Fieldgroup support is now officially in cck-3.x.
There were significant changes in the code and a new patch is required.

You have to use this patch for the latest cck-3.x version as the -8 patch and previous are not compatible.

As a side note I am interested in finding out how much of this patch is still necessary.

Nice patch! I think it's very necessary, as it makes the user interface cleaner, and works with multigroups. There's a little change I'd make to it, though, which deals much better with nested fieldgroups where the controlling field is on the same level as a controlled fieldset / group, and that is to change

    if (!$in_group) {

    if (!$in_group || $in_group == $form['parent']['#default_value']) {

in conditional_fields_fieldgroup_group_edit_form. Once this is done, a set of radio buttons inside a fieldset can determine which sub-fieldset is displayed.


What is the patch in #55 supposed to apply against? The last dev release seems to be almost 2 years old ( and the patch fails against the latest 6.x-2.x code in git.

I patched the latest git code manually and it seems to work ok.

+1 for the addition in #56 as well.

I have tried to apply patch from #55 against Conditional Fields 6.x-2.0, but it fails:

[root@www conditional_fields]# patch --dry-run -p1 < conditional_fields-6.x-2.x-support_nested_fieldgroups-9.patch
patching file conditional_fields.module
Hunk #1 succeeded at 201 (offset -1 lines).
Hunk #3 succeeded at 232 (offset -1 lines).
Hunk #5 succeeded at 303 (offset -1 lines).
Hunk #6 succeeded at 649 (offset 2 lines).
Hunk #7 succeeded at 735 (offset 32 lines).
Hunk #8 succeeded at 719 (offset 2 lines).
Hunk #9 FAILED at 747.
Hunk #10 succeeded at 807 (offset 32 lines).
Hunk #11 succeeded at 808 (offset 2 lines).
Hunk #12 succeeded at 873 (offset 32 lines).
Hunk #13 FAILED at 938.
Hunk #14 succeeded at 951 (offset -13 lines).
Hunk #15 succeeded at 1008 (offset 32 lines).
Hunk #16 FAILED at 1023.
Hunk #17 succeeded at 1374 (offset -12 lines).
Hunk #18 succeeded at 1526 (offset 32 lines).
3 out of 18 hunks FAILED -- saving rejects to file conditional_fields.module.rej

Could you please update the patch to work with the latest 6.x-2.x? Thanks.

I don't have time to test this myself, so I made two versions.
The -10 is a straight-forward re-diff with no changes.
The -11 contains the change from #56.

Status:Needs review» Reviewed & tested by the community

Thank you very much thekevinday! Patch 11 from #59 applied fine to Conditional Fields 6.x-2.0 and is working fine for me so far.

Title:Compatibility with CCK nested fieldgroupCompatibility with nested fieldgroups (CCK 3)
Version:6.x-2.x-dev» 6.x-2.0

Status:Reviewed & tested by the community» Needs work

I have tested with latest CCK3 dev and yesterdays Git checkout patched with both patches in #59. It seems that neither do the trick for me. Marking, needs work. I tested in Garland and Rubik.

The latest CCK 3 D6 version is still 6.x-3.x-dev (2011-Aug-02). Controlled nested fieldsets from that version are working fine for me with the patch 11.

Status:Needs work» Reviewed & tested by the community

I have tested both patches in comment #59 and they both work. I am using the -11 patch as of this writing.

Drupal 6.22
Conditional Fields 6.x-2.0
CCK 6.x-3.x-dev (2011-Aug-02)

I did notice an error with a content type that I exported from one machine (CCK 6.x-3.0-alpha3) and imported as a new content type on another machine (CCK 2011-Aug-02) but i cannot reproduce it. The fields still worked as intended despite the error. Here is the error i got:

warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /srv/web/ssprod/sites/all/modules/conditional_fields/conditional_fields.module on line 842.

I did a var_dump() on $field['in_group'] right before line 842 and it output bool(false). It probably just has something to do with having different versions of CCK on the two machines.

I suppose you could change line 842 from this

if (array_key_exists($field['in_group'], $fieldsets) && is_array($fieldsets[$field['in_group']]) && array_key_exists($field['field'], $fieldsets[$field['in_group']])){

to this

if ($field['in_group'] && array_key_exists($field['in_group'], $fieldsets) && is_array($fieldsets[$field['in_group']]) && array_key_exists($field['field'], $fieldsets[$field['in_group']])){

...which would get rid of the error. Not sure what other impact there might be though. It's not a major concern for me.

I suggest taking the change from #65 and instead using isset() as follows:

if (isset($field['in_group']) && array_key_exists($field['in_group'], $fieldsets) && is_array($fieldsets[$field['in_group']]) && array_key_exists($field['field'], $fieldsets[$field['in_group']])){

Status:Reviewed & tested by the community» Needs review
new39.2 KB

Here is a new patch that takes thekevinday's approach and improves it:
- Using fieldgroup_get_parents() instead of searching for fieldgroups inside the form.
- Introducing conditional_fields_array_get_nested_value and conditional_fields_array_set_nested_value to handle variable depth arrays, which are straight backports from Drupal 7's respective functions, so they should be solid.
- Adding node validation logic for nested groups.

I also reordered/renamed some functions and rewrote many comments.

Since it's a BIG patch that affects most of the module's functionality, I'd like to have some thorough testing before committing it.

(btw, thanks to thekevinday for push this forward!)

New iteration: restored content_add_more_js integration and removed two stray "&"s.

is this patch for 6.x-2.0?

It is against 6.x-2.x-dev.

aha - thanks.

Version:6.x-2.0» 6.x-2.x-dev

Yes, roball's right.

#68 doesn't seem to be working within a multigroup with cck 6.x-3.0-alpha3 - is that expected?

#73: This is not about multigroups, it's about nested fieldgroups. I tested only cck 6.x-3.0-dev.

This new patch synchs with latest dev.

ah ok, just there was mention of multigroups in comments above. thanks

Patch in #74 doesn't appear to sync with latest dev any longer.

patching file conditional_fields.module
Hunk #4 succeeded at 634 (offset 13 lines).
Hunk #5 succeeded at 665 (offset 13 lines).
Hunk #6 succeeded at 785 (offset 13 lines).
Hunk #7 succeeded at 812 (offset 13 lines).
Hunk #8 succeeded at 921 (offset 13 lines).
Hunk #9 succeeded at 1185 (offset 13 lines).
Hunk #10 FAILED at 1458.
Hunk #11 succeeded at 1458 (offset -4 lines).
Hunk #12 succeeded at 1512 with fuzz 1 (offset 14 lines).
1 out of 12 hunks FAILED -- saving rejects to file conditional_fields.module.rej

Status:Needs review» Needs work

Setting to needs work being patch currently fails.

Priority:Normal» Major

I can confirm that peterpoe's latest patch from #74 cannot be applied to the latest 6.x-2.x-dev, which is 6.x-2.0+12-dev (2012-Aug-07), unfortunately. I am getting the following error:

[root@server conditional_fields]# patch --dry-run -p1 < conditional-fields-nested-fieldgroups-650008-74.patch
patching file conditional_fields.module
Hunk #4 succeeded at 640 (offset 19 lines).
Hunk #5 succeeded at 671 (offset 19 lines).
Hunk #6 succeeded at 791 (offset 19 lines).
Hunk #7 succeeded at 818 (offset 19 lines).
Hunk #8 FAILED at 908.
Hunk #9 succeeded at 1079 (offset 19 lines).
Hunk #10 FAILED at 1333.
Hunk #11 succeeded at 1372 (offset 2 lines).
Hunk #12 succeeded at 1426 with fuzz 1 (offset 20 lines).
2 out of 12 hunks FAILED -- saving rejects to file conditional_fields.module.rej

Can the patch please be updated to sync with the latest dev?

Any chance to get this working again with the current 6.x-2.x-dev?

Here it is.


Thank you ermannob for porting this urgently required patch to the current 6.x-2.x-dev. Now it applied cleanly. However, it did not solve the problem. What a never-ending pain!

Currently, the best working combination of the D6 version of this module is 6.x-2.0+12-dev with the patch #16 applied from #927558: Use hook_content_is_empty to determine if a required controlled field is empty.. Without that patch, the module won't work at all (no node with conditional fields could be saved - the module would always hit a false error).

However, the above mentioned working combination does not fix the bug described here - conditional fields within a nested fieldgroup that should not be displayed are actually getting displayed. Was hoping for many months that this would be getting fixed once. It already used to work some day, but got broken with a new dev. In order to apply the patch #80 from this bug report, the #927558: Use hook_content_is_empty to determine if a required controlled field is empty. patch must be removed first. But this patch is a huge thing with changes tons of non-related code, instead of just addressing the described problem. It seems to fix the critical bug which has also been fixed by the #927558: Use hook_content_is_empty to determine if a required controlled field is empty. patch, but it still does not solve the original problem reported here :-(

ermannob, do you have an idea how to really solve this problem?

I would suggest you to apply my patch, then reset all dependencies and start over (use the checkbox at the bottom in /admin/content/node-type/your-node-type-name/conditional to delete dependencies).
Or you could also try to disable and unistall this module. Then, activate and configure dependencies again.