Field Dependency Fails When Exported with Features [#2193055]

When a field dependency is exported using the Features module, it does not work correctly when deployed to another Drupal site. Specifically, the value of a dependent field is not written to the database.

Steps to Reproduce

Create Drupal instance with 'Standard' install profile
Enable Features and Conditional Fields modules
Manage fields for 'Basic Page' content type
Add 'Selector' field of type boolean
Add 'Field A' field of type text
Add 'Field B' field of type text
Add field dependencies

Field Dependency 1

Dependent: Field A
Dependee: Selector
Condition: Value
Values input mode: Insert value from widget (set to 0)
Interaction with other dependencies: AND
Form state: Visible
Effect: Show/Hide
Hide the dependent if the dependee is not in the form: checked
Hide the dependent if the dependency is not triggered: checked
Hide the dependent if the dependee is not viewable by the user: checked

Field Dependency 2

Dependent: Field B
Dependee: Selector
Condition: Value
Values input mode: Insert value from widget (set to 0)
Interaction with other dependencies: AND
Form state: Visible
Effect: Show/Hide
Hide the dependent if the dependee is not in the form: checked
Hide the dependent if the dependency is not triggered: checked
Hide the dependent if the dependee is not viewable by the user: checked

In this configuration, Conditional Fields works as expected. The values of the dependent fields are written to the database.

Create a new feature
Conditional Fields

node:page

Features API

api:2

Field Bases

body
field_field_a
field_field_b
field_selector

Field Instances

node-page-body
node-page-field_field_a
node-page-field_field_b
node-page-field_selector

Content Types

page

When the feature is enabled on the same site, Conditional Fields continues to work as expected.

Create Drupal instance with 'Standard' install profile
Enable Features module
Enable the aforementioned feature

When the feature is enabled on a site other than the site on which it was created, then values entered in Field A and Field B are not written to the database when saving a node of type Basic Page.

Set issue priority to Major because this bug breaks deployment.

The featured I used in this test has been attached to this issue.

Set Up Details

Drupal 7.26
Conditional Fields 7.x-3.x-dev (revision 78ecb040828f8b9b38ca6e1c37a69782da8d9f86)
Features 7.x-2.0

Comment	File	Size	Author
#15	conditional_fields-features-export-2193055-15.patch	792 bytes	mibfire
#15	7.x-3.x: PHP 5.3 & MySQL 5.5, D7 5 pass
	test_feature-2.tar_.gz	1.81 KB	Chris Burge

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Chris Burge CreditAttribution: Chris Burge commented 11 February 2014 at 16:50

Issue summary:

View changes

Comment #2

Chris Burge CreditAttribution: Chris Burge commented 11 February 2014 at 16:54

The issue appears to be how values in the 'options' column of the 'conditional_fields' table are stored and exported. Numbers other than zero are stored as numeric strings; however, upon export with Features, these strings are converted into integers.

For example, the following would be stored as a serialized array prior to export:

      'element_view' => array(
        1 => '1',
        2 => '2',
        5 => 0,
        3 => 0,
        4 => 0,
      ),

Following export, this same array would be changed as is shown below:

      'element_view' => array(
        1 => 1,
        2 => 2,
        5 => 0,
        3 => 0,
        4 => 0,
      ),

This change breaks field dependencies as is described in the original issue. Manually changing the values back to numeric strings corrects the issue.

Looking in includes/conditional_fields.features.inc, I see on line 67 that the module is using the 'features_var_export' function to export the options array.

As a result, this issue may be related to #2034285: features_var_export() incorrectly converts numeric strings into integers or floats

Comment #3

Chris Burge CreditAttribution: Chris Burge commented 11 February 2014 at 19:31

Further testing has revealed a twist. In the options array, two values with a value of '0' are also converted from a numeric string to an integer upon export:

Example code from before export:

      'selector' => '',
      'values_set' => '1',
      'value_form' => '0',
      'value' => array(
        0 => array(
          'value' => '0',
        ),
      ),
      'values' => array(),

Example code from after export:

      'selector' => '',
      'values_set' => '1',
      'value_form' => 0,
      'value' => array(
        0 => array(
          'value' => 0,
        ),
      ),
      'values' => array(),

This change adversely affects field dependencies. In the case of the example from the original issue post, values entered into Field B will not be written to the database. Changing the values to numeric strings corrects the issue.

This may be a special case where a boolean field is used; however, it is a valid use case.

Comment #4

aniket.mohite88 CreditAttribution: aniket.mohite88 commented 24 September 2014 at 11:45

Thanks to kenorb's patch, available here
https://www.drupal.org/node/2210241

I was able to solve this.
Can export the conditional field settings (along with content-type & fields).
In my case the dependent is a Date field & dependee is a boolean field.

Conditional field 7.x-3.0-alpha1
features 7.x-2.2

Comment #5

bburg

he/him

Washington D.C.

CreditAttribution: bburg commented 31 December 2014 at 18:58

Not an ideal solution, but I've found that you can go into the dependent field settings form, and without changing anything, click save. And conditional fields will work in the new environment. This also will persist between feature reverts (possible only if you never change the dependent field component).

Comment #6

Leeteq CreditAttribution: Leeteq commented 4 January 2015 at 11:38

Comment #7

margyly CreditAttribution: margyly commented 11 March 2015 at 21:06

I have the same problem -- conditional fields not featurizing. One select field is dependent on another.

Comment #8

blainelang CreditAttribution: blainelang commented 3 September 2015 at 14:43

I can also confirm exporting conditional field settings via features does not work. The conditions are imported via features just fine but you have to edit/save each of them manually for them to work. If you delete a field condition and revert the feature, the same issue,

Comment #9

dzinkevich CreditAttribution: dzinkevich at Zivtech commented 18 April 2016 at 14:13

Also reverting the features with --force a second time makes the feature work. When I look at the order that features are run, conditional fields are imported before anything else (including field_base and field_instance), which means that conditional fields are being set on fields that don't exist yet. Here's the output of my `drush fr my_cool_module --force -y` command:

Reverted my_cool_module.conditional_fields. [ok]
Reverted my_cool_module.field_base. [ok]
Reverted my_cool_module.field_group. [ok]
Reverted my_cool_module.field_instance. [ok]
Reverted my_cool_module.node. [ok]
Reverted my_cool_module.variable. [ok]

Comment #10

kenorb CreditAttribution: kenorb commented 21 April 2016 at 10:34

Comment #11

ThomWilhelm CreditAttribution: ThomWilhelm commented 3 October 2017 at 04:16

Just ran into this issue, ouch! I needed to deploy many new conditional fields via features, and didn't want to have to edit every condition and click save on production to get this to work.

As has been mentioned above in regards to the root of the problem, when you export a conditional field using features, it converts a string value "1" into an integer 1 by dropping the quotation marks. It does this only if the string value passes the is_numeric PHP function.

So to work around this, for conditional fields where you need to check if a value is 1 or 0 (or any numeric value for that matter), use the Values input mode of "Regular expression" to match ^1$ or ^0$. Using a regular expression like this ensures when you do an export it doesn't get converted into an integer, and it deploys cleanly.

Hope that helps someone, if anyone has an easier solution let me know! :)

Comment #12

capysara CreditAttribution: capysara commented 5 April 2019 at 18:00

I’m having the same issue. I can see that the dependency number (e.g., 441 here …admin/structure/dependencies/edit/441) increases every time I revert the feature, so they have all have to be re-saved.

I checked out the related https://www.drupal.org/project/features/issues/2034285, and I’m not sure which is the better thread for this comment. There’s a proposed patch in the other issue, so I’ll leave my comment there, too. However, features is the

I tried this, but it didn’t help: https://www.drupal.org/project/conditional_fields/issues/2210241.

I haven't explored @ThomWhilhelm's workaround, but if there's interest I can take a look at creating a patch.

I’m using 7.x-3.0-alpha2. I tried the dev version, which includes https://www.drupal.org/node/2527430, but this did not resolve the issue for me either. After updating to dev, I recreated the feature. I also tried deleting all my conditional dependencies, then added one back in, and then recreated the feature. Every time I reverted the feature, the dependency stopped working unless I went back in and resaved.

Clarification/correction: I have a required field that is visible when a Select list has a value of "1." After reverting the feature, the visibility part of the conditional field works, but it's no longer required (it should be required once it's visible). When I resave the conditional dependency, the requirement works as expected. And it's only an issue when the dependent field is a select list. Text fields continue to be visible/required as expected.