Conditional fields not saving

Which kind of fields are your author/illustrator/publisher dependents?

Duplicate of #1542706: Conditional fields not saving.

This is marked as a duplicate of itself... sounds a bit recursive :D

Did you perhaps mean http://drupal.org/node/1191476 ?

No, there is a definite difference between the two. I was having the problem of saved data not showing, but now I am having the same problem as cherrybleach - I can't get the data in conditional fields to save. Are, perhaps, the view context settings affecting the edit context settings? I cannot, no matter what I try, have view-context visible data AND have the data saved...

Subscribing.

Dependent fields not saved for profile 2 module. But for simple node all Ok.

I patched conditional_fields.module. Just commented one string. I know, it's very bad style, but it work.

// drupal_array_set_nested_value($form_state['values'], $dependent['#field_parents'], $field_values_location);

I'm not sure for what that code. As a temporary solution, it's fine.

That solution is not, unfortunately, working for me. Also, neither dependent nor dependee field data is saving. The only fields for which data saves are the ones (or is the one) that is not being touched by the Conditional Fields module: Title.

I have not installed any new modules between when this was working and when it stopped, but I did make the data visible in the view context settings. The modules I have installed are:
Apache Solr Access
Apache Solr Framework
Apache Solr Search
Current Search Blocks
Custom Search Blocks
Custom Search Taxonomy
Devel
Devel generate
Devel node access
Drupal Ipsum
Facet API
Facet Slider
Feeds Admin UI
Save Draft
Variable
Variable Admin

Also, as hinted at in http://drupal.org/node/1721480 I have made sure that all the dependee fields are single-value, but still no love.
Please help!

Having same issue with dependent user fields not saving. Loac's solutuion in #8 fixes for me, but not sure what real issue is. Not sure of the logic behind these few lines before, but think it might be fixed there:

if (empty($field['reset'])) {
unset($field_values_location[$dependent['#field_name']]);
}
else {
$dependent_info = field_form_get_state($dependent['#field_parents'], $dependent['#field_name'], $dependent['#language'], $form_state);
$field_values_location[$dependent['#field_name']][$dependent['#language']] = field_get_default_value($dependent_info['instance']['entity_type'], NULL, $dependent_info['field'], $dependent_info['instance'], $dependent['#language']);
}

My dependent fields get to this point with $field['reset'] being empty, so the field_values_location is unset for that field and the subsequent drupal_array_set_nested_value call can't set that field because it isn't there anymore.

It was after an update several weeks ago that mine stopped saving fields.

Hopefully I have a site somewhere with an older version (I believe I do), if not I will go through the recent commits until I find one that works and find the difference.

I have exactly the same problem. if it helps ... my dependent field is a term ref, the dependant is yes/no checkbox. The dependency is a simple 'visible' if '0', I have no options selected in the dependency (now). Change the term ref, it looks OK, saves OK (or so it says) but nothing has actually been changed. Delete the dependency and everything then works OK. Reinstate the dependency and back to square 1 (cannot save edits).

Mentioned here: http://drupal.org/node/1325538#comment-6349994

Using the direct input method (e.g. "All these values" / "Any of these values") does make my other conditional fields work properly: show/hide and data being saved, but it still isn't working with HS (and possibly other field types). Tested using latest version of CF.

Still not working if I use "Is checked" or input value from widget but hey, awesome module is at least working on some level for now.

I do have to get it working for Hierarchical select so I will continue digging around.

It's also not working w/ file fields either. (even w/ the direct input method).

They do save, but do not display. Unchecking "Hide the dependent if the dependee is not viewable by the user" makes it show up on display. (Note this is w/ UID 1 so it shouldn't be an issue)

I can confirm that the direct input method works for me too.

For me, this seems to be a problem that the dependee field can accept multiple options but I only want to require 1 to control the dependent. If I only select one option in the dependee field, then the dependent saves ok. If I select 2 options in the dependee field, it returns false at the following spot:

line 1080:
return array_values($dependency_values) == array_values($values);

It seems that when using the widget to select the dependency, it clearly states "The dependency is triggered when the field has exactly the same value(s) inserted in the widget below." So, it is marking this dependency as not triggered when I select 2 options in the dependee field because I am only requiring 1 in the set up. It would return true if I told it that I needed both values to require the dependency.

Seems like maybe if there were AND/OR options for the widget like the direct input method has, this would work as expected for me, but would require too much work I am guessing. Not sure if this is what is affecting others or not. Just thought I would share. Think we are going to have to use direct input method for now unless anyone has any other suggestions.

I have the same problem, but using solution suggested in #13 all works fine.

So my settings from:

• condition: value
• values input mode: insert value from widget (with an option selected)

Have to become (for making things working correctly):

• condition: value
• values input mode: all these values (AND) (and then manually insert the option value, e.g "135")

In particularly I have a text input field whose visibility depends on an option of a term reference field (a definite term in a the related taxonomy)

Please: resolve this!!!

+1

for me the solution seemed to be not using INVISIBLE

i had a few fields that were all controlled by state of a term ref:

tid options: 2, 3, or 4 (radios)

some fields have to be on if 3 is selected; some have to be invisible if 3 is selected.

the 2nd of these would not save. changing this to visible if any of 2, 4.. and it seems to work.

The solution on #8 worked for me... I don't really understand why though.
The values were not saved when the dependee was a dependent of another field in registration form.

For example:
Do you shave? (yes, no)
if yes, do you an electrical or mechanical rasor?
if mechanical , one blade, two blades, or three blades? <--- this one was not saved

Anyway thank you Loac , it's not a perfect solution, but you have saved my weekend.

So, through all the workarounds I was still either not having fields show/hide, or fields not saving.

However; I just tested using the "ADVANCED EDIT CONTEXT SETTINGS" option, and I put in the CSS ID of the 'dependee' (field that has to be xyz for this field to show) and it appears to be working great (hide/show AND saving values).

I put in the CSS selector just as it would be in your stylesheet, i.e.: #edit-field-category

This is also using a Taxonomy Heirarchial Select as the dependee, so double win! (Note it's still requiring to use "Any/All of these values" rather than 'select from widget' to work w/ THS).

Note, also have to UNSELECT these:

• Hide the dependent if the dependee is not in the form
• Hide the dependent if the dependee is not viewable by the user

Otherwise it doesn't display saved values.

I too found the problem to be arriving on hidden fields – note that I unchecked „clear fields when hidden“. Also the possibility of malfunction seemed to be higher on chained dependencies (i.e. a working hide/display on 1 dependent field, but not on 2).

#8 works for me

Not using "invisible" as form state works for me

For me the problem is only attached to a collection field.
When I use dependencies the collection field (all of them) are not saved.
If I remove dependencies the collection field is saved.
invisible or not, widget or specific value the problem is the same for me.

I'va just replace with old module and it works.
here it is

old module works, but comes with other issues.

What were the other issues? I'm just wondering which is best for now - I'm guessing using the older version, but want to be aware of the downsides.

Thanks.

Tried #8 - this has improved things for me. When I look at the saved data in the admin theme the fields are populated now, as opposed to showing up as blank before.

For some reason my dependee field (select list) stills show up blank, if I pick the correct value I submitted from it the fields mentioned above all appear as expected. Edit: this dependee field issue was due to some of my own javascript (I was preselecting the dropdown via a get parameter). This works fine as long as jQuery's disable() function is not called on the dependee field - it stops it the value from being saved.

@bkno: in my case, validation for required fields isnt triggered with older module.

I have the same problem, but using solution suggested in #8 works for me.

// drupal_array_set_nested_value($form_state['values'], $dependent['#field_parents'], $field_values_location);

is it correct to comment one line of code to resolved this issue?

Thanks

Hi everybody!

I'm having the same issue of above... however I noticed something that could help fixing this problem

My situation:

Dependent: Long text field
Dependee: Select list

The dependent should be visible when a certain value from the Dependee list is selected.
If I set the condition using insert value from widget, the dependent appears but nothing is saved... however if I set the condition using Set of values and writing directly the dependee values, it works perfectly.

I had this same issue. In my case, it occurred when I was using the same field in two different content types and using it as the dependent in both content types with the same dependee. I got around it by setting the condition on the second one using "set of values" rather than "insert value from widget" as suggested in several of the comments here. I was able to use "insert value from widget" for the first one though. I'm using the condition "the dependent field is visible when the dependee has value" for both.

Solution #8 seems to work fine for me! I hope this does not create other bugs though.
Thanks.

#32 did it for me... not sure why this hasnt been fixed.

#16 works for me.

Edit: #16 didn't fix the issue, #8 did.

Thanks for sharing.

#20/#21 is the only one that works for me. It solved both, fields not saving changes and not displaying on the node view page.

Hi,

#8 worked for me

Thanks!

Related backlink: http://www.webbykat.com/2013/04/conditional-fields-and-term-reference-tr...

Hallo, i have the same Problem: http://drupal.org/node/1982360

#8 fixed it for me..

Thanks a lot, it took me about 20 hours of work and more to get to this point..

#8 worked for me too

#8 worked for me as well

Happy Belated Birthday to this issue! :)

#8 seems ok here too. Thanks.

Let's say this issue needs review and is unassigned, it could bring the maintainer back...

#8 solves helps with saving the conditional fields, but they still don't display on view. Reporting here as http://drupal.org/node/1191476 has been marked as duplicate of this one.

needs review generally implies there's is a patch; perhaps one of you could create a patch file for review?

What seemed to work for me (validation and saving of values in a widget scenario) was the following update to the conditional_fields_evaluate_dependency function:

Instead of:

line 1080: return array_values($dependency_values) == array_values($values);

I used:

$valuesNew = array();
foreach ($values as $delta => $value) {
$valuesNew[] = $value['value'];
}
$values = $valuesNew;

$dependency_values = array_values($dependency_values);
$values = array_values($values);
$matches = array_intersect($dependency_values,$values);
return count($matches) > 0;

Could someone create a patch file including #8 for review? Thanks.

Both #8 and #32 worked for me..but then #32 is a better solution than tweaking the module itself

Fixing a bug in a module for everyone using a module > temporary fixes. I'm not experiencing this issue, just happened around it.

Can someone please post a patch of the fix so can be properly reviewed? Setting it back to active as there's not a patch.

#8 works... However, this breaks the module's ability to set the dependent field back to its default value if the dependency is not triggered.

Clearly there is a deeper issue at play here in the code.

Okay, first of: Conditional fields is a great little tool, right now I use it a *LOT* (unless you have a better idea how to get individual "Property fields" in a node to show up based on taxonomy...).

Anyways - for now it does exactly what I need, even with the little quirks we've all come across (looks at the comment thread...).

I *think* I found at least one thing that definitely causes the "do not save" problem: Other fields on the same node that use Ajax. Or at least certain of them:

In my case it's a rather large taxonomy list selection that I tried to display with the taxonomy hierarchical term widget or that other taxonomy tree one. You know - the ones where you can display only 1st level terms and users then can open them up to go "deeper"...

Whenever I have one of those on the same node as the conditional fields it f***s up the field save. Change the taxonomy selection to normal select field or radio buttons: Everything works fine.

So while you might chew on this I will, in the meantime, simply put the taxonomy selection (in whatever widget) on it's own page and then forward the user to the rest of the fields on the node edit (with the taxonomy selection being hidden there). Violà.

Can I have a wish now?Support fieldgroups please? ^^

Doesn't sound like you meant to change the issue title

Oh, sorry - I thought that was just the title for my post. ^^ My apologies.

Same issue, I cant save the fields in a custom content type that are under the control if Conditional fields. If I remove the field from Conditional fields then the field saves.

Would love to see a patch

#8 works for me too. Maintainers?

Sorry but there's no patch that definitively works for everyone. It still needs work.

I agree #8 worked for me regarding the original problem, but as I stated in #51

it breaks the module's ability to set the dependent field back to its default value if the dependency is not triggered.

So while it's solving one problem, it's creating at least one other problem.

In my case, I've tracked the problem down to conditional_fields_evaluate_dependency() returning the wrong result. Because multi-value fields can only use the input widget to test exact matches (which is almost never what you want), we have to use the raw value check, which ends up checking values against a $reference_values array created like this:

  $reference_values = array();
  foreach ((array) $values as $value) {
    // TODO: support multiple values.
    $reference_values[] = is_array($value) ? array_shift($value) : $value;
  }

This check works on two types of field value structures: flat arrays, and nested arrays where the first item is the value. Everything else fails the check. For a fix, I suggest breaking this out into a hook structure with separate functions for different field types, and using the current function as a fallback for any field types lacking their own checks. That would allow patches to be submitted against specific field types without concern over breaking the check for other field types. With the current one-size-fits-all approach, I don't even know where to start on patching this, but I could easily submit a patch for the specific field types that are failing for me.

I'm also willing to write the code to make this more modular, provided a project maintain can first approve this direction. I don't want to maintain this module, nor do I want to waste time writing code that isn't where the maintainers want to go with this. I'll ping peterpoe to ask about this.

#13 is a good quick fix for me - data is not saving if using 'insert value from widget' in value input mode of conditional fields.

Posted by drastik on August 15, 2012 at 5:04am
Mentioned here: http://drupal.org/node/1325538#comment-6349994

Using the direct input method (e.g. "All these values" / "Any of these values") does make my other conditional fields work properly: show/hide and data being saved,

@Alauddin

Look at #20 and #21:
https://drupal.org/node/1542706#comment-6501868

I had full functionality when doing it that way.

#32 worked for me

I can confirm that, when using 'Insert value from widget..." , ocassionally values will not save in dependant fields.

Using "Any of these values..." or "All of these values" and manually specifying the dependee values works fine. Conditionally hidden/invisible fields are now hiding/invisible when condition is met and values are being saved when conditions are not met.

I can also confirm that, when using 'Insert value from widget..." , ocassionally values will not save in dependant fields. I also had some that didnt work as expected when entered in as a regular expression.

#8 worked.

For us, we had some really extensive keys in our key|value pairings in our allowed values for a select list.
We had a select value that had the Allowed value: "Other – Please specify:|Other – Please specify:"
Then we had a field dependency on that value. If they checked this "Other" box, then a textbox was supposed to appear. And it did appear and disappear, but the values would not save.
What we discovered is that when we changed the key|value pair to be simpler (e.g. "other|Other - Please specify:"), then the data started saving.
I'm assuming that if the value you're keying on contains special characters or something like that then the pairing in the DB doesn't work so well. I cannot attest for the users above whether this would fix their issues, but I have a hunch it would.
If this is the case, we can release a patch to either make the key more robust, or we could validate the "Allowed Values" textbox on submission and check for keys that could break our world.
Can anyone confirm that this fixes their problem while using select lists?
Keep in mind that you will have to create a new Select list if you've got data in the field.

problem still exists... #8 works

problem still exists... #8 not works for collection field as dependent

Here's a "patch" from #8... just commenting it out and adding a TODO.

Well... things *saved* when I used the patch from #67 but they aren't rendering (i.e. when I edit then the values are there but when I view I don't see them... devel shows them).

Related: https://drupal.org/node/2114847

In my case the patch from #67 / #8 does not save the values correctly, as they do not show up in the view of an un/published node.

The solution with only using 'visible' and 'all of these values' seems to 'solve' the problem. This might be an issue that need to be solved.

Until then: thanks for all the tips here. Saved my day!

Here is a version of the patch from #67 that confirms to drupal standards and applies cleanly using git or drush make

Hi,

I also had problems with fields inside nodes that did not save the changes I made to them.
When I removed them from the conditional fields, the problem was solved.
I did not test test patch #72, I just removed the conditionals because there where not that important.

+1 for #8, #72. Fixes my problem using Conditional Fields and Commerce Pricing Options which gave an error:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /system/ajax
StatusText: OK
ResponseText: 
Fatal error:  Cannot unset string offsets in /home/test/public_html/modules/field/field.default.inc on line 41

You cannot set a nested value that is not there until selected.

+1 for #32 works for me for integer field type.

but I still have problem with float field type, value is stored, but not shown.

I have a few conditions:

DEPENDENT DEPENDEES
1. Daily (field_daily) Lease Term (field_lease_term) Daily is visible when Lease Term has value "85".
2. Monthly (field_monthly) Lease Term (field_lease_term) Monthly is visible when Lease Term has value "84".
3. Six months(field_sixmonths) Lease Term (field_lease_term) Six months is visible when Lease Term has value "86".

field_daily is integer - text and field_lease_term term reference - checkbox

The values ​​are saved, but not shown in the view. After #32 if i select "Set Value = All of these value" it start to work.

I had more problems with the display of the other dependent values. They persisted, but not displayed during playback. After unchecking "Hide the dependent if the dependee is not viewable by the user" all start working.

+1 for #72. Fixes my issues.

we have multiple dependencies - set visible if and set invisible if not for multiple fields... all of the displays on node edit work perfectly, and the values save accurately.... but not one of the fields in the conditional field area are visible on node view - any help appreciated

patch #72 does not fix this on our site

oh heck - got sick of it - used https://drupal.org/project/eva and displayed the output in views.... i think if we were doing it over though it might have been more expedient to use https://drupal.org/project/field_conditional_state - a bit more work, perhaps, but it looked like it might have worked as a replacement for conditional fields...

I can confirm that I was experiencing this bug too, and patch #72 seems to have fixed it.

I confirm too that patch #72 fix this problem

ok - i can confirm that it doesn't :) and happy valentine's day ;)

Thanks #8 worked for me too!

thanks mrfelton
patch #72 fixed this me as well

Thanks, patch in #72 fixed it for me

I'm have this problem using collection field on a content type that use conditional fields. Unfortunately the patch doesn't work for me.

#72 working

Confirming that #72 saves the values of my user profile, but saved data is not outputted on default user profile page with fields having multiple dependencies. Fields with no single dependencies are outputted.

I found a solution to the "not saving problem"
take a look at the page: http://www.webbykat.com/2013/04/conditional-fields-and-term-reference-tr...

explained in short:

Dependent: field_dependent
Dependee: field_dependee

instead of using: Values input mode: Insert value from widget...[Check the box for "trigger value".]
use: Values input mode: All of these values (AND)...Set of values: id of the "trigger value"

I wanted to take a look at this.

Seems like the next steps here are to read through all the comments, and update the issue summary with the various situations (situation where the patch fixes, and *also* for where the patch does not), and steps to reproduce for them. https://drupal.org/contributor-tasks/write-issue-summary https://drupal.org/contributor-tasks/add-steps-to-reproduce

also, is needs work for an older patch failing. #72 wasn't set to needs review. doing that now.

@palamida's solution in #89 works, and seems a (more?) reliable solution particularly when in conjunction with Taxonomy based dependees. Thoughts?

Is this similar to https://drupal.org/node/1549364?

I confirm that #72 worked fine.

Tested using 2 Dependents: Date field and text field.
Dependee is a taxonomy.

#72 didn't work on it's own, but #90 afterwards got it working. Thanks guys!

I had the exact same issue as #33, and the advice there has solved my headache. I am so pleased!

Can confirm that the patch in #72 fixed this as well as the procedure given in #89. This was with fields on a taxonomy term.

#72 Fixed issue partially for me. Field is saved but not displayed.

I can confirm that the patch in #72 fixes the issue for us. Hope this can be marked RTBC and added to the module.

The patch in 72 is simply commenting out one function call. It did not solve the issue completely for me.
Also this module looks extinct. I've moved to https://www.drupal.org/project/field_conditional_state which is simply an UI layer over an existing drupal api.

I'm pretty wary of the solution in #72 because it is just commenting out functionality that is there for a reason.

We need work from the module maintainer as to what kind of negative effects this may have.

If only there was a "Super critical" status :)

Not being able to use invisible cripples this module because it is not possible to work around all uses of invisible by changing other settings.
Because you can't "NOT" a condition and the use AND, or & XOR is not advanced enough (groups are always separated with AND) invisible is the only way to solve some problems.

I also used the solution recommended in #89 instead of applying a patch. Worked fine.

@kenorb could you please explain why you changed the status to "Needs work"?

Patch at #72 seems it doesn't fix the problem directly, it looks like workaround, as it is just commenting out the code which could be relevant and it's stating TODO. Based on #8 (saying it's bad), #78 and #100 it needs work as we removing something that it seems people doesn't understand why actually it's not working. Over 30 comments after the patch it seems nobody set it as 'Reviewed & tested', that means most people are not enough convinced that it's the right solution and some of them went with #13, #32, #99 or with #89 (including me). I could be wrong, but if anybody think differently and tested the patch and think it's the right approach, please change it to 'Reviewed & tested'.

I went with #99 and installed this module instead:

https://www.drupal.org/project/field_conditional_state

Easier to use and has active development.

Agree totally with #99 - seems to be the way forward

FWIW, this same issue appeared for me when setting a dependent field to "invisible" based on dependee value. #13 did not do it for me. The only thing that worked was re-jiggering my logic to set the form as "visible" based on value. Solved my problem today, but agree with #100 that this is a pretty critical bug that definitely limits this module's effectiveness.

BTW, I would *love* to use field_conditional_state instead, but it doesn't work with features, and that's kind of a deal-breaker for my current project.

I had the same issue and after a day of debugging I got to this solution.

The reason why that commented line in #72 is not working is because one of the parameters of that function has a faulty value. The problem is actually in conditional_fields_form_field_get_values function, where isset is used instead of !empty. That generates an empty $parents variable and an empty form_states['values'] array.

After I modified that, I faced the situation where, my information was being saved, but the required fields that were hidden were still generating error messages. That's where the second fix comes in, adding the fields that are hidden to the untriggered_dependents_errors array which represents the errors that will be removed from the form.

#110 Works for me

#110 Me Too.

My dependency was setup to make a Boolean field inactive if a certain option was set on another field, field should be defaulted to active otherwise with no dependency set. The Boolean field was not saving any changes while active, but it is now.

[EDIT] spammy post I was referring to has now been deleted.

#110 Works for me.+1

Great work, let's get this committed to dev! :)

I can confirm RTBC. This is a critical problem and #110 fixed it perfectly.

Please release a new DEV release ASAP and a new stable release soon.

Thanks a lot for your hard work @all!

The patch also works for me, thanks!

#110 worked for me as well. Thanks, vdanielpop!

Please commit #110. This issue is critical.

I converted all invisible rules to visible and now everything works fine without any patch.

Had this issue applied patch from #110 which worked for nodes but not Profile2. Profile2 did work when using #8.

Would like to see 110 committed. I used the direct input method instead and that did work for me.

#110 is working for me too.

I consider this issue critical, too.
Please commit #110 ASAP.

I can confirm that the patch works.

Maybe someone can open a co-maintainership issue for this module so this situation doesn't happen again.

Thanks a lot for the fix! What do you think about a new alpha2 which contains this fix in some days, if there are no problems with this in dev?

#32 worked for me. In my case the dependee is a list of taxonomy terms and so I had to specify the taxonomy term id in the set of values.

@Bhuvana_Indukuri
You should be using the latest dev.. this issue is Closed (fixed)

This issue is closed and marked as fixed. Thanks everyone for your hard work. However per the last comment, I wanted to note that the latest dev version still warns against using on production sites. I personally applied the patch in #110 to 7.x-3.0-alpha1. Though, as others have noted, it'd be great to have an alpha2 recommended release with the patch. I'll submit a separate support request for that.

@tracyt10

I wanted to note that the latest dev version still warns against using on production sites.

What? Where? If you mean the notice on the project page, that warns against using ANY 3.x version on production sites.
Use common sense, never blindly trust anything, always test stuff before using it in production, and if possible, review the code.

@rv0 - I'm referring to the release notes here: https://www.drupal.org/node/1137614

You should absolutely use common sense, never trust anything blindly, and always test it before using!

I have tested 7.x-3.0-alpha1 with the patch noted above and have not tested the latest dev yet or had the chance to review all of the updates included in the dev. My note was simply to ensure that others saw the warning before use on production sites and followed best practices (review notes, test, review code, etc). :)

@tracyt10
Release notes for a dev release of a branch that exists for years wont ever make sense because the dev always contains latest code. It's simply what the maintainer wrote when he first pushed the code to drupal.org and enabled the release, April 25, 2011, 180 commits (!!) have been done ever since..
You are using an alpha release dated 2013-Nov-18. This module should have had a new release by now, because in this case (and in my experience) the dev is currently a lot more stable than the "stable" alpha release, hence my recommendation.

There's https://www.drupal.org/list-changes/conditional_fields exactly for that

I've found most D7 modules to be stuck in dev and more stable, whereas with D6 one would rarely use the dev release.

latest alpha2 solved the issue for me

Anyone still having issues with this? I'm still loosing data every 10 or so nodes sent.

#32 for the win!!!!

Seems that 7.x-3.0-alpha2 let this issue appear on my project, it was not an issue with the alpha version before. It just was a problem with multiple checkbox as dependee and a simple text field as dependent. The same setting was no problem with radios as dependee. #32 solved the problem