Conditions work only in edit context

[simonphu]

I can't get conditions to work in view context under Backdrop 1.22.0. Basically, I want to make a field with a default value show if another field has a certain value. The condition works on the node edit form but seems to have no effect when the node is viewed, and the dependent field is always displayed with its default value. This worked fine with the Drupal 7 version of the module. Is it not possible in Backdrop? I've also read earlier comments about using fieldsets (Field Group module), which I have tried, but it didn't make a difference.

[laryn]

Hi @simonphu -- thanks for reporting! If it's possible to include step by step instructions and/or screenshots it might help when I (or somebody else) has a chance to review in more depth. I won't have time to look at this in the next few months but if nobody has gotten to it before then I'll try to look then.

[simonphu]

Thanks for the quick reply, @laryn . Here are the instructions to reproduce the issue.

• Create new content type 'Test content type'.
• Add new field 'Test field 1' (Tpye: List (text), Form element: Check boxes/radio buttons, Allowed values list: Option 1, Option 2, Option 3 (using custom keys))
  
• Add new field Test field 2 (Type: Text (short), Form element: Text field, Default value: This should only be displayed if Test field 1 value is Option 1.)
  
• Add a new dependency (Conditional field (dependent): Test field 2,Depends on (dependee): Test field 1)
  
  
• Test by creating content of type Test content type
• If Test field 1 value is Option 1, Test field 2 is displayed
  
• If Test field 1 value is not Option 1, Test field 2 is not displayed
  
• So the condition works as expected on the content edit form.
• But on the content view page, Test field 2 is always displayed with default value, even if Test field 1's value is not Option 1
  
  It would be great if you or someone could look into this.

[olafgrabienski]

The condition works on the node edit form but seems to have no effect when the node is viewed, and the dependent field is always displayed with its default value.

@simonphu - I've tried to reproduce the issue on a site where Conditional Fields work fine for me: The dependent field is only displayed on node view if the condition is met. However, on that site I don't use a default value for the dependent field. Now, after adding a default value to the dependent field and adding a new node, the dependent field is displayed in any case, as described by you.

A guess, what is happening: the default value is applied to the node form in any case, and gets hidden (via JavaScript?) according to the dependee value. So, you don't see it in the node form, but it's there and gets saved. You should be able to check it by toggling the dependee value in the node form and having a look at the unhidden field.

For the time being, it should however be possible to use your Conditional Fields configuration without a default value. Can you confirm this?

[simonphu]

@olafgrabienski -- Yes, I can confirm that the dependent field and its default value is applied in the node form, only it gets hidden when the condition is triggered. (You can see the style definition style="display: none;" applied to the given div if you look at the HTML source code.)

It would be possible to use Conditional Fields with dependent fields that don't have a default value, but my guess is that such fields will not show on node view pages not because they're hidden by the module but because they don't have a value. (Unfortunately, for the website I'm trying to upgrade from Drupal 7 to Backdrop, this is not an option.)

[simonphu]

@laryn, @olafgrabienski -- I've tested the Conditional Fields module on Drupal 7 and Drupal 9. On D7 it works as expected, but the D9 version has the same problem as the Backdrop version. The issue is discussed at this page on drupal.org: https://www.drupal.org/project/conditional_fields/issues/3009641

[olafgrabienski]

I've tested the Conditional Fields module on Drupal 7 and Drupal 9. On D7 it works as expected, but the D9 version has the same problem as the Backdrop version.

That's interesting, as the Backdrop version was ported from the Drupal 7 version of the module. Not that I'm an expert in code related questions, but I'm wondering if there might be an issue with regards to Backdrop core, which was forked in a very early stage of Drupal 8.

[simonphu]

@olafgrabienski I don't know, I'm not an expert either. I just thought it might be interesting for anyone willing to look into this problem to take a look at the D9 version of the module as well as the patch provided in the thread I linked to before.

[padprint]

I'm having the same issue here, I have a conditional field to determine whether to show a "last updated" field. Unfortunately if that field has a value, it is shown regardless of the conditional field settings. This means if at any point the "last updated" field was shown, you can't effectively disable it without manually deleting the value. Hopefully we can get this fixed? I'm lookin at the code, but I'm not going to be much use.

[laryn]

@simonphu @olafgrabienski @padprint Could you test this PR?
#24

[olafgrabienski]

Sure, happy to test - works for me √

First I've followed the steps from #22 (comment) on an unpatched site, resulting in the undesired behavior of showing the text field's default value in any case. After applying the PR to the site, the default value was only showed if supposed to be shown. Also, the test node was updated immediately, no cache clear necessary.

[padprint]

I tested against a site currently in production, and got the same results. If a conditional field has content, it will display regardless of the state of the trigger field. I’ll test on a clean install as soon as I can. regards, John Benjamin Creative Director Horizon Media Group a division of Paducah Printing Corp. 233 North 8th St. Paducah KY, 42001 Phone: 270.442.0428 Fax: 270.442.6141 http://horizonmediagroup.com/ Disclaimer All materials attached are for proofing only, and remain the property of Horizon Media Group. Images and Logos from third parties remain the property of their respective owners. You may not reproduce and/or distribute logos, graphics, animations, photos or other content without the express permission of the copyright holder. Final printed materials may differ in color from screen proofs.

…

On Aug 10, 2022, at 2:29 PM, Olaf Grabienski ***@***.***> wrote: Sure, happy to test - works for me √ First I've followed the steps from #22 (comment) <#22 (comment)> on an unpatched site, resulting in the undesired behavior of showing the text field's default value in any case. After applying the PR to my the site, the default value was only showed if supposed to be shown. Also, the test node was updated immediately, no cache clear necessary. — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCTA6GSDKYK2YEU4FQQNTVYP7ILANCNFSM5YJRWPHQ>. You are receiving this because you were mentioned.

[padprint]

OK,
On a fresh install of 1.22.2. I installed the PR and created two fields on the basic page. The fields are a boolean with values 1 (on) or 0 (off), and a date field.

Setting the boolean field as the 'dependent' and the date field as the 'dependee' I set the condition to Checked and tested. This resulted in the same issue as before. The date field would display regardless of the state of the boolean field, if there was a date set.

I then changed to the condition to Value and check the checkbox under 'Insert Value from widget...'

This worked, and correctly showed or hid the field based on the checkbox value.

Finally I went back to the boolean field and removed the "1" and "0" values to instead use the default values, this still worked as intended.

Longwinded way of saying there is still an issue when using the "Checked" option, but otherwise seems to work.

Thanks!