Controlled-by fields inside a Paragraph don't work

I was able to reproduce an issue.

I was able to reproduce the issue - same settings works fine on the regular fields / content type, but doesn't work inside the paragraph.

I am having the same issue.
I have a dropdown list inside a paragraph where you can choose to upload an image or a video. I want to conditional hide / show the video field and image field.

Same Issue for me. I have a paragraph type with two fields, one boolean & one reference field to a content that I want to hide if the boolean field is checked. When I create a content including the paragraph type, if I check the boolean nothing happen.

If I do the same thing inside a content instead of a paragraph type, with the same settings, it works for the content type.

Same issue here. It would be great if this could work within paragraphs.

Updating title to distinguish it from #2851624: Conditionals don't work on dependent Paragraphs fields.

I was able to solve my problem but not by using the conditional fields module. Paragraphs are working on some new hooks that help you hook into paragraphs and use the field states API.
https://www.drupal.org/project/paragraphs/issues/2868155
Posted an example of conditionally showing a field based on a select field value.
https://www.drupal.org/project/paragraphs/issues/2868155#comment-12315429

This may be useful to people looking to build this feature (or just for workarounds) - http://agaric.com/blogs/conditional-fields-paragraphs-using-javascript-s...

I confirm.
It's very sad that conditional fields don't work with paragraphs at all.

I was seeing a similar problem when working with Form API States to hide a certain field based on the value of another field. I was able to track down the problem to the line $parContent.show(); in paragraphs.admin.js. As it turned out, the field was being hidden as expected, but the show() command immediately revealed the field again.

i can confirm this issue as well. as soon as you want to control fields inside of a paragraph it doesn't work. has nothing to do with the field config as it works as soon as you place the fields directly on a content type.

I confirm this error, i have the same problem...

Since #13, I posted a patch for the Paragraphs module in #2946856-3: Perspectives tabs break Form API #states. I have not tested it in combination with Conditional Fields module (only with Form API states added in a form alter) but it is possible that my patch solves the problem for Conditional Fields as well. You are invited to give it a try and post your feedback in that issue.

@marcvangend, I tried your patch, but it doesn't seem to fix this issue.
I have just started looking into this, but it looks like the fields inside the paragraph don't get any of the data atrributes that are needed to show or hide the fields.

Thanks for testing it Kevin, that's good to know. So it seems that more stuff needs to be done to get it to work. Perhaps Conditional Fields can add those data attributes by implementing hook_field_widget_paragraphs_form_alter() ?

@marcvangend yes that appears to be an option.

As far as I can tell from my initial review we either need to use 'hook_field_widget_paragraphs_form_alter' and append any conditions to the $dependencies array.

Or apply a recursive function in the 'conditional_fields_load_dependencies' function to move down any potential Paragraph trees.

Additionally, when it loops through the entity fields in the "conditional_fields_load_dependencies" function, it is looking for the "['third_party_settings']['conditional_fields']" array, but if the field is of type "entity_reference_paragraphs" we need to get the referenced paragraph node and get the conditional_fields array from there.

If that makes sense. To be honest I'm eyeballing it atm.

Will review this over the coming days.

You'd be my hero @benm1234

I confirm this error, i have the same problem too.

Or apply a recursive function in the 'conditional_fields_load_dependencies' function to move down any potential Paragraph trees.

Sounds more generic than using hook_field_widget_paragraphs_form_alter().

Started fiddling with that - draft on how to go down the rabbit hole in conditional_fields_load_dependencies:

    $fields = $entity->getComponents();
    /** @var \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager */
    $entity_field_manager = \Drupal::service('entity_field.manager');
    $field_storage_definitions = $entity_field_manager->getFieldStorageDefinitions($entity_type);
    /** @var \Drupal\Core\Field\FieldTypePluginManager $field_type_manager */
    $field_type_manager = \Drupal::service('plugin.manager.field.field_type');
    foreach ($fields as $field_name => $field) {
      if (isset($field_storage_definitions[$field_name])) {
        $class = $field_type_manager->getPluginClass($field_storage_definitions[$field_name]->getType());
        // Deal with entity reference fields and descendants.
        if ($class == \Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::class || is_subclass_of($class, \Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::class)) {
          if (($target_entity_type = $field_storage_definitions[$field_name]->getSetting('target_type'))) {
            $target_entity_type_bundles = \Drupal::service('entity_type.bundle.info')->getBundleInfo($target_entity_type);
            foreach (array_keys($target_entity_type_bundles) as $target_entity_type_bundle) {
              // Recursive call - will update the static variable with the
              // dependencies.
              conditional_fields_load_dependencies($target_entity_type, $target_entity_type_bundle);
              if (!empty($dependencies[$target_entity_type][$target_entity_type_bundle])) {
                // Push sub-dependencies into parent.
                $dependencies[$entity_type][$bundle] = array_merge($dependencies[$entity_type][$bundle], $dependencies[$target_entity_type][$target_entity_type_bundle]);
              }
              //$dependencies = array_merge($dependencies, $dep);
            }
          }
        }
      }
      if (empty($field['third_party_settings']['conditional_fields'])) {
        continue;
      }

This is far from working. All it achieves is collecting dependencies of all referencable entity type / bundle configurations. However, correctly applying and handling this information is another story.

Generic is better, as I can also verify that this issue exists with blocks. Conditional fields work fine when editing directly on a block type, but if that block form is embedded into a node form (similar to a paragraph bundle), the block's settings for conditional fields do not carry over.

Paragraphs is based on Entity Reference Revisions, so probably Conditional Fields simply donnot work within entity references? So in case of @tjh this is probably Inline Entity References which embeds the block in the form.

Conditional fields works with entity references.

I can confirm this issue, conditional fields don't work with paragraphs (entity_reference_revisions)

Confirming this issue as well! Running D8.5.6

I confirm this issue too.
Running Drupal core 8.5.6, Conditional Fields 8.x-1.0-alpha4, Entity Reference Revisions 8.x-1.5, Paragraphs 8.x-1.3

Same issue.

Drupal core 8.5.6
Paragraphs 8.x-1.3
Entity Reference Revisions 8.x-1.5
Conditional Fields 8.x-1.0-alpha4 (tried 1.x-dev too)

Same issue.

Drupal core 8.6.0
Paragraphs 8.x-1.3
Conditional Fields 8.x-1.0-alpha4

This might be a manual workaround which I have not tried yet: http://agaric.com/blogs/conditional-fields-paragraphs-using-javascript-s...

The above link is broken :( -- was only broken in the emailed comment, sorry. Thanks for the link!

Same issue.

Drupal core 8.6.7
Paragraphs 8.x-1.5
Conditional Fields 8.x-1.x-dev

This issue is similar to issue number #2995827 which has patch.

So is this a duplicate or not? If not, please explain the difference.

#2995827 states that the settings form "Manage Dependencies" does not appear for non-node (content) entities. However, this is untrue. The Manage Dependencies form *does* appear for Paragraph entities, but does not seem to have any affect.

Unless the patch at #2995827 solves this problem as well (untested), I think these are separate problems -- at least semantically.

Makes sense. Patches still welcome, as usual.

Deleted

agudivad, regarding #39: The issue queue is a place where we work together on generic fixes and improvements. This is not the right place to request individual help with your project. Please post your question in the forum or at https://drupal.stackexchange.com/.

anyone can fix this issue ?
It's very sad that conditional fields don't work with paragraphs at all :(

#41: Comments like yours aren't helpful. If you'd like issues to progress, how about offering funding or patches? That's how we get things done.

#41 I disagree. I think letting folks know that this is important is valuable and brings attention to issues. Not everyone can help with funding or patches.

@M_Z yes I just tested with the current release 8.x-1.0-alpha6 and it does not work yet.

This should probably wait for #1161314: Add basic Field Group support for ANDing conditions. Lots of refactoring (for general type of groups) going on there.

I have this problem.

Drupal core 8.8.1
Conditional Fields 8.x-1.0-alpha6
Paragraphs 8.x-1.10

Please check below url
admin/structure/conditional_fields/paragraph

or you can manage conditional Fields with different entities using below url
admin/structure/conditional_fields

for more information please check attached image.

Dependencies can be configured at /admin/structure/conditional_fields/paragraph, but they don't apply the state changes.

The changes on Controlled by fields within paragraphs, don't trigger the JavaScript like they do for fields on content types.

If I set a field to become invisible based on a selected value, the code below is triggered when the field is updated on a content type, but the code below never triggers with the same settings on paragraph fields.

.bind('state:visible', function(e) { ....

I have the same issue.

Same issue here! and yes definitively we need a patch to fix this.

While a bunch of refactoring is going on in #1161314: Add basic Field Group support for ANDing conditions, @josephleon and myself are actively working on bringing this functionality to 8.x-1.x now.

Here's a test-only patch to describe the desired functionality. (this test should fail with the message "The target field select list does not contain the paragraph's text field.")

Oops, that patch errored out because of #3192790: Add paragraphs to test_dependencies in .info.yml

Test dependencies were added to 8.x-1.x in #3192790: Add paragraphs to test_dependencies in .info.yml, so let's rebase the patch in #53 onto the latest 8.x-1.x.

And also fix a TODO comment.

Should have added an interdiff; sorry.

I think we need #3206849: Make ConditionalFieldsFormHelper testable finished before I can continue with this patch, because I need to modify ConditionalFieldsFormHelper and want to make sure that I don't cause a regression.

Targeting the 4.x branch now that #3206849: Make ConditionalFieldsFormHelper testable has been committed there.

Back to "Needs Work" as well.

#59 Just wondering if there are any updates regarding your patch? Thanks.

@adstokoe, unfortunately not yet. There's a bunch of technical debt in the module that I need to address in the 4.x branch, before it is possible for me to write automated tests, which I need to do before I change the data model, and I need to change the data model so I can store data about fields inside paragraphs without machine-name collisions causing unintended behavior. That being said, I've recently been side-tracked by other projects and issues (and even when I have time to spend on this issue, it takes quite a while to get back into context and takes a bunch of cognitive load), so I've unassigned myself. If you'd like to take a shot at fixing the problem, go for it.

That's a bummer but makes sense @mparker17, this is definitely something we'd be interested in seeing move forward but unfortunately, I don't have the skillset to make this happen myself. Hopefully, someone else will be able to take a peak at this issue soon.

I'd gladly support doing review work for this, but lack the knowledge to actually do the patch right now.

Just checking on status of this and reporting my findings on updated versions of everything:

core: 9.2.8
paragraphs: 8.x-1.12
cond fields: 4.0.0-alpha1

The only patch i have for CF is: #2891276: checked, !checked don't work because states set on checkbox, radiobutton wrapper divs, not HTML input elements and none for Paragraphs. A bunch for core including this one: #2893740: Allow the sidebar for the node form to be used on other entity forms as well which was breaking the "add CF" config form until i fixed the patch.

I had tried out the patch from here: #2995827: Other entities work but without the additional manage display path like on node types but it doesn't apply to 4.0. It does apply to 8-1.2 but throws a ton of errors and doesnt work.

Should we change the title of this issue to simply: "Conditional Fields do not work with Paragraphs." or are there parts of this combination which do work?

---------

Forgot to include, what i see currently with the lineup listed above is that the CF config seems to work fine and there are no errors - it just doesnt do anything on the parent edit form.

flag :)

This patch is working for me.

I've tested it with simple scenarios.

I think it won't work with nested paragraphs.

This patch is against 4.0.0-alpha1.

After the automated tests run, I could spot a few more issues.

Here is the updated patch (for 4.0.0-alpha1).

#66 works fine, except if you have referenced fields(prtagraphs, terms ...)

The correct status is Needs work, since the patch failed to apply.

#66 works when the controlled by field is a select list.
It would be nice to be able to add the dependency on a "Manage Dependencies" tab like on a content type.
On a paragraph, I don't see that tab. So, I need to go to /admin/structure/conditional_fields/paragraph/
to add the dependency.

Correction: It works fine on the first paragraph. When I add the same paragraph 3 times, conditional fields only works on the first paragraph

Hi there, thanks very much for the work on this.

The patch in #66 does work for me for the simplest conditions in a paragraph, but if I try to add two conditions for one field (if both X and Y are V, then Z is visible), then the second condition isn't recognized.

I've tested it on just regular field in a content item, and it works as expected.

Thanks again!

I tried a patch from #66 and it worked partially (Drupal 9.3.5).
I couldn't see media fields, link fields...

(And I was accessing the UI for this to work by going to "/admin/structure/conditional_fields/" )

This patch works with multiple conditions (for 4.0.0-alpha1).

the patch in #74 worked well for the paragraphs but it stopped working for the content types, that was working previously without applying the patch

Thanks @rckstr_rohan would you please elaborate a simple scenario to replicate it? It is working well for me.

I replicated an issue related to paragraphs and then fixed it.
I'm uploading a patch (for 4.0.0-alpha1) to improve the bundle selection for the paragraph.
Please test and let me know.
Thanks!

Fixed an undefined variable scenario inside `conditional_fields_get_paragraph_bundle` from my previous patch. Sorry for the noise.

I had the issue mentioned above.

Scenario: I have a requirement of a top level Paragraph with two taxonomy reference fields both dependent on each other. If none had value, both show and both are marked as required. If either has a value, then the other is hidden and made optional.

This wasn't working and patch at #78 fixed it. No errors or warnings in the logs.

As an extra test, I created a wrapper paragraph that could contain Unlimited references to the Paragraph mentioned above. This also worked - I could add as many of the original Paragraphs to it and each hid/showed their respective fields without interfering with each other.

The last three patches failed to apply.

Hi all! I spotted an issue a few days ago with my recent patch.
The conditional fields array information on the form for paragraphs ($form['#conditional_fields']) was built incorrectly.
This patch fixes the mentioned issue and looks pretty solid to me.
I tested this patch with nested paragraphs (up to 5 or 6 levels) and multiple conditions.
I also ran the test suite and no warnings/notices.

As usual, this patch is for 4.0.0-alpha1.7
I will create a patch against dev later today.

I ran into the problem above.
But #82 doesn't work for me: when the control field is not selected, only part of the target field is hidden. For example, the File field only hides the Upload button, and the LInk field only hides the URL.
My environment:
Drupal: 9.3.12
PHP: 7.4
Paragraph: 8.x-1.12
Conditional fields: 4.0.0-alpha1

I also confirm that the patch from #82 works partially - if you have more complex form field with sub fields it doesn't hide them all.

Updating patch for Conditional fields 4.0.0-alpha1

This patch fixes a few issues I found a week ago.
It has been manually tested and works well with complex paragraphs and multiple elements added asynchronously.

Making the patch for the dev version was more complicated than I expected. Sorry.

#87 worked for me.

#87 worked for me using Drupal Core 9.3.12 and Paragraphs 8.x-1.12. Thank you BetoAveiga.

#87 also worked for me. I would change to RTBC, but @apaderno set it as "Needs Work." Can you please say what about it needs work?

@shelane The patch in comment #87 (the last provided patch) failed to apply.

OK, so it does apply to the 4.0.0-alpha1 release, but there has been quite a bit of commits since that time. I have composer patches applying this since I am still on the alpha1 release. I haven't tried to install the dev of the module to see if the issue still exists.

The patches are tested on the 4.x branch. They don't apply to the 4.x-dev development snapshot nor the 4.0.0-alpha1 release.

I had a few more hours to work on this patch, to move it to the dev 4x version.

Hopefully, this works for most of the scenarios with paragraphs.

This patch passes unit tests. It only has a few differences from the previous patch to ensure not using undefined keys (is_from_paragraph) in arrays.

Sorry for the noise.
The last patch, despite passing the existing Unit tests, introduced a few PHP warnings on our functional tests.
Here is another small update for the patch.
I think we need Unit tests to ensure the correct paragraph integration and also to fix the remaining bugs.

Patch is not working for required fields.

I have 2 fields
Field 1 image field
Field 2 List (text)

What I want to achieve is whenever Field 2 has a specific value I want to mark Field 1 as required, but when I do this the node page doesn't save for me.

Hello,

Thanks for the patch, it is working but not in all case.

I have a list text field with multiple options, this is control field, and the target can be any other field type.

If I set it to Unlimited, and the form widget is Checkbox/Radio buttons, the code does not find the checkboxes.

If i set it to Limeted = 1, and in form will shows up Radio buttons, the code is working.

Small fix added to patch from #103 since I was receiving an error "TypeError: Cannot access offset of type string on string in function" from line 731 of ConditionalFieldsFormHelper.

#106 is working in my relatively simple use case of the value of a List (text) field controlling a couple target fields' exclusive visibility (within a paragraph).

Thanks all, esp @BetoAveiga & @mparker17!

Hi, I got a similar error as reported at comment 104 and I found that this was introduced by a change on the way how the input state is retrieved from the field.

Is there a reason for such change? Such change doesn't seem relevant to make conditional fields to work inside paragraphs.

The patch fails with the latest ''drupal/conditional_fields:^4.0@alpha'' version. If we lock it to the previous dev version its causing issues with the other conditional fields.

The patch applies correctly but it doesn't seem to work. I have nested paragraphs though, so not the simplest usecase.

The case I tried:

Paragraph type 1
- field paragraph

Paragraph type 2
- field node type
- field taxonomy term

Condition on paragraph 2
field taxonomy term is visible when field node type has value "bundle1"

Just to note that the patch, https://www.drupal.org/files/issues/2022-06-29/support-for-inline-entity... (Support for Inline Entity Form), conflicts.

The patch is failing with the composer update. And when we try to use the paragraph type with conditional fields in a content type with other conditional fields, the fields are not working as it should be. Its listing all the fields regardless of the conditions added in the content type.

Hello,

patch #109 it seems it works for me, but I am using also additional module Paragraphs table and it does not hid the Label.

Is anyone can help ?

I tested the patch in #106 successfully, just like the tester in #108. I am using Drupal core 9.5.3, paragraphs 8.x-1.15 & entity_reference_revisions 8.x-1.10.

If there is anyone who can't get the patch to apply, please check you're not using 4.0.0-alpha1 of this module, you will first need to switch to the dev version, using `composer require 'drupal/conditional_fields:4.x-dev@dev'`.

I tested by creating a paragraph type and adding a List (text) field to it with 2 values. I then went to /admin/structure/conditional_fields/paragraph, selected the paragraph type and added dependencies to selectively show fields that were hidden depending on the value of the List (text) field.

Then finally, I added a paragraph field to a content type, and saw that the fields stopped being hidden and displayed based on my input for the List (text) field. I tested this successfully with the radio button & select form displays.

Thanks everyone for your assistance in getting this working.

For extra clarity on how I got this working, and because it can get a little tricky to use it for the first time, or after not using the interface for a while, I have also added screenshots.

As this is now working for a few of us, tests are passing and to make things easier for a wider set of new people stumbling across this issue, I would like to recommend that we get this committed and closed, then open new issues for more advanced/complex use cases to build on top of this great foundation. I hope that will be fine with everyone :)

Hi, patch #109 worked for me. Read the comment #115. Thanks.

Please check the comment #110,where I specifically mentioned that the patch is failing with the alpha version. We had to update the module as it was causing issues with the required field conditions, so we can't lock it to the dev version.

Include patch for issue #3106135

Both 118 and 109 apply to alpha2 However neither work. I noticed two issues:

#1 the manage dependencies tab is gone from paragraphs, I needed to go through /admin/structure/conditional_fields/paragraph/[bundle] in order to create the rules
#2 The conditions are not working when there is more than one condition. E.g. I have 2 fields controlled by a select list, one is visible if one value is selected, the other is visible if the other value is selected. If I have only one condition it works, but if I have both conditions neither condition works.

Nicxvan if there is more the one you need use XOR.

I'll try again, but I tried all three options.

I also have the same settings working on a content type that I copied it from that works as expected. That is on AND as well.

Using Drupal 10.0.3, Conditional fields 4.0.0-alpha2 and Paragraphs 8.x-1.15, patch #118 worked.

As regards the comment on #119 I never saw the manage dependencies tab even before applying the patch so I only went through 'structure/conditional_fields/paragraph/[bundle]' even before applying the patch. I controlled two fields with conditions from one select list and they both worked.

Thanks.

Patch #118 worked for me using Drupal 9.5.2, Conditional fields 4.0.0-alpha2 and Paragraphs 8.x-1.15.

I agree with @chike: It doesn't matter if you have applied the patch or not, the "Manage dependencies" tab doesn't show for paragraphs. So the patch has to be updated so the tab shows up.

@slayne40 Why include patch for #3106135?

I'm pretty sure the tab for manage dependencies was there in alpha1, it disappearing is unrelated to the patch. I think it was between alpha 1 and 2.

That's not critical since we can access them through the other pathway.

@nicxvan If you are using formatted fields (WYSIWYG), check out patch on #2988937: Dependency using body as target results in "An invalid form control with name='body[0][value]' is not focusable." with ckeditor enabled

I just found out that this patch make dependencies on paragraphs work but it breaks the dependencies on nodes. So I will check out #2995827: Other entities work but without the additional manage display path like on node types

I have the patch on and could set dependencies for paragraphs and users, haven't tried on nodes.

I am not using WYSIWIG for this, it's a select list controlling a text field and an image field.

The solution from patch #118 works well for me, but it generates two warnings.

Warning: Undefined array key "edit-field-prices-0-subform-field-unit-wrapper" in Drupal\conditional_fields\ConditionalFieldsFormHelper::dependentValidate() (line 476 of modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php).

Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::dependentValidate() (line 508 of modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php).

Therefore, I made a small modification to the #118 solution to resolve these warnings.

I'm also experiencing the issue @rcodina brings up, that while this fixes conditional fields within paragraphs, it actually breaks conditional fields on nodes.

That's the case with the patches in #109, #118, and #130.

@m.anoune: the last number in your patch filename should correspond to the number of the comment it's being posted within. Interdiffs (showing changes from previous patch) are also extremely helpful.

Aha. This fixes the issue with nodes. It's working for me for conditional fields in both paragraphs and nodes.

The bug with nodes would only manifest if dependent fields were processed in a certain order (a node-based one after a paragraph-based one), so not everyone may be experiencing the issue with node-based ones.

In processDependentFields(), $base_name was not being reset for non-paragraph fields, so if a paragraph-based dependent field had already been processed, $base_name's paragraph-related value remained and caused the node-based field to not be processed.

Thanks! Here's a version with the same + also adding the one line change at https://www.drupal.org/node/3193825 as these two patches conflict with each other.

I had tested the patch #134 and it's working good except for this:

1. When you assign a select field to be required, it allows the default (_none) as an accepted value and allows the submit (a solution would be to add _none value as not accepted.

2. When you assign a multiple autocomplete inputs as required, the form blocks the submit because it's asking for row weight value (for sort) for the first row that have a default weight of 0. The solution would be to accept 0 as the row weight value for the first row.

I do see the issue mentioned in the #135 regarding the required fields.

Re: #134 it'd be better to keep this patch constrained to what this issue is about. If people need multiple patches they can apply and resolve potential conflicts themselves. Otherwise the issue gets convoluted and harder to evaluate/review/commit. At the extreme logical extension, every issue patch contains every other issue patch.

In dropping dpm()s while debugging a problem with conditional_fields setting #required state, I found a couple issues with this patch in dependentValidate() where:

1. paragraphs within paragraphs weren't being treated quite right: array_search() was finding the first subform (top-level) instead of the one directly containing the field in question
2. $field_name was often not being computed correctly because it was using ['field_parents'] instead of ['array_parents'].

The only effect of these issues might be that certain validation messages don't show the correct name of the field... but it does appear to be a logical bug, and made debugging more complicated.

@scott_euser I don't mean to be a jerk about not including the other issue patch, but this issue is already really tangled.

Perfectly fine, I should have just stored the combined patch locally within private folder of my project in hindsight :)

Something of an edge case but nonetheless an issue:

(You shouldn't need this smaller, additional patch unless you're having required field problems with media fields inside your paragraphs.)

If you're running into the problems described in #2845855: Hidden required field is still required & #3344587: Support for field hidden by condition losing its required status, where a field set to required that's being hidden by conditional_fields is still incorrectly being required – and therefore causing form validation errors because it's empty...

and to solve this you instead make your fields optional and use conditional_fields to explicitly set them to required (with the same criteria that makes them visible)...

and one of those dependent fields is a core Media field with an image...

and it's in a paragraph...

then you might be running into the issue I am, which is that when that Media field is visible and required, even when an image has been chosen from the media library and so that field has a value, it's still being marked as empty.

It appears that the media_library_selection subfield of the media field is being caught as empty by conditional_fields in dependentValidate().

I don't see this happening with Media fields not in a paragraph, so I'm just including this additional patch (which should be applied on top of #138) in case it's useful to anyone else or helps illuminate anything else regarding this issue.

I could not get #140 to patch on 4.0.0-alpha3 or 4.x-dev. But #138 did successfully patch and fix my issue with paragraphs. Both from @jeffschuler. :) Thank you for sharing and for all the other people contributing to this.

Yes @eahonet, #140 is only to solve an additional issue and only applies on top of #138.

#138 is the patch you want for the primary issue here.

Sorry for any confusion and thanks for the review!

Patch from #138 seems to work well for me but I had two errors when having a File field as the "Controlled by" -field.

Error: Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array in Drupal\conditional_fields\ConditionalFieldsFormHelper::evaluateDependencies() (line 657 of /app/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php)

Error: Cannot use object of type Drupal\Core\StringTranslation\TranslatableMarkup as array in Drupal\conditional_fields\ConditionalFieldsFormHelper::evaluateDependency() (line 834 of /app/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php)

I simply fixed these by adding a check is_array in the corresponding lines so feel free to fix if there is a larger logic issue related. Attached updated patch from #138 with those array check added.

Hi
Thanks for the uploaded patch jeffschuler, I have been testing it patch #138 and the visibility functionality works fine when including a paragraph inside another one.
But I have found when in addition to visibility I add that the new paragraph is required it generates an error.
I will try to explain mi case,
I have a content type, inside that content type I have a paragraph, this also has another paragraph inside it.
The visibility conditions work fine. But if in the content type I also add that the field is required when it is visible, when saving, an error appears.

Notice: Undefined index: #title in Drupal\conditional_fields\ConditionalFieldsFormHelper::dependentValidate() (line 544 of modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php).
Drupal\conditional_fields\ConditionalFieldsFormHelper::dependentValidate(Array, Object, Array)

And I get an error message that the fields that are already filled are required, it marks them in red, and also asks me that the weight fields also have to be filled, which are also required when ordering it.
I hope I have explained the problem well, I know it sounds a bit confusing.

@thatguy: That makes sense. And it works properly with the file field as the controlled-by?

@TornatoreMDM:

For the Undefined index error, it's probably necessary to repeat the check from line 537: if (isset($element_to_set_error['#title'])) { before the statement a few lines down where you're getting the error: $title = $element_to_set_error['#title'];

As for the issue where it's complaining that fields that actually have values are still required, I suspect it may be something similar to what I dealt with in #140 with media fields. There was a sub-field of the media field that didn't have a value even though the field itself did, and that was triggering the error. It sounds like the dependent field (that you're displaying and requiring) is a paragraph (another complex field that has sub-fields)? – So there might be something more general we need to do for checking whether fields are set... I added a bunch of dpm() statements to see what was triggering the form error.

@jeffschuler unfortunately there has come up other problems with using the file field as the controlled-by but these issues seem to exist without this patch as well so I'm going through other issues and trying to find help from those.

Hi
I did not read all of this, but some general feedback about the proposed patch.

Imo, this is far too specific about paragraphs.
Instead, a generic approach should be done that works with custom entities with inline_entity_form and with paragraphs.

Instead of hooking into the entity form, the module could hook into the field widget.
This way, the "paragraph" no longer needs to be treated as a special case.

I have applied several of the patches provided in this issue and I am still having the issue with the "Controlled by" field not working in a paragraph type. I am running the 4.0.0-alpha3 version of the module in a Drupal 9.5.11 and PHP 8.1 environment. How is it that the patch works for some people and not others? Thanks to everyone who has helped on trying to solve this issue, but I don't know what else I can do to make this work in a paragraph type. If anyone has any idea as to what the issue might be I'd appreciate your feedback. Thanks.

re-roll for Drupal 10.1.x

After additional testing, I found that the provided patch for the "Controlled-by" field works as expected in paragraphs. The issue I am experiencing is probably caused by the fact that we are using Layout Paragraphs for adding paragraphs content rather than adding our paragraph types as an entity reference field within another entity (i.e. Content type).

#149 patch does not work if you set the form display for the paragraph field to Autocollapse = All, or Edit mode = Closed

#149 patch works for me with state visible but doesn't work with state empty.
I set conditional fields on a paragraph and both "target" and "controlled by" fields are located in the same paragraph bundle.
Paragraph are added with a field Entity reference revisions (Reference type: Paragraphe)

In the javascript file conditional_fields.js, "state:empty" bind function has a condition on e.effect value to emptying input.
In my case e.effect is always undefined so the target field is not emptying.

I think this is because of JS settings because when I observe drupalSettings.conditionalFields.effects, it doesn't contain a key with the id of my "controlled by" field.

using dev version ( cf#115) and patch #149 :
it work well when the visibility for the field is conditionned by a checked boolean or a value or a list field.

It does not work when the control field is a taxonomy entity ref field.

I have the same problem as mariohernandez #150, it doesn't seem to work in Layout Paragraphs

Patch #149 works for me and also fixed the error: TypeError: Drupal\conditional_fields\ConditionalFieldsFormHelper::evaluateDependencies(): Argument #1 ($dependent) must be of type array, null given, called in /code/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php on line 478 in Drupal\conditional_fields\ConditionalFieldsFormHelper::evaluateDependencies() (line 586 of /code/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php).

I created a new issue for conditional_fields not working inside layout_paragraphs.
Hoping we get some solution to it.
https://www.drupal.org/project/conditional_fields/issues/3390509

as the new issue is raised about this in layout_paragraphs here https://www.drupal.org/project/conditional_fields/issues/3390509 ok to review this one and eventually get this merged?

Changing this issue to 'Needs review'

There is a case when Content Entity Type constraints do add error messages during form validation. Those are keyed with empty string in form_state_errors array in comparison to field level errors, which are keyed by parents path to field. There is a case when $error_key can be calculated as an empty string, thus doing a collision and grabbing top level form error and assigning as an error for each $untriggered_dependents fields. Later on this throws all the remove\add back logic under the bus and dismisses the top level form errors as result.

My addition to patch #149 add a simple check for non emptiness of $error_key, as top level form errors should not be matched against any field.

Patch #159 solves the issue.

Thanks for all the hard work in here. +1 We need more reports here to set to RTBC and to commit.

With the new dev version it no longer applies.
Can it be re-rolled to apply?

I committed several issues today, so yes it is possible that this issue run out of queue (line numbers). A reroll is required.

This patch isn't perfect, but we could get a level of control in paragraphs.
Sometimes I would need to change from visible to !visible to make the rules work, but they worked.

It would be good to have it committed or, at least, re-rolled to the current dev.

Thanks :)

Yhea the 159 patch is working for me as well. Didnt work on the dev version but it does on the 4.0.0-alpha5 on Drupal 10.2.3

re-roll for latest dev version

have tested it for IEF and paragraphs.
still needs some in-depth testing

Patch https://www.drupal.org/files/issues/2024-03-20/2902164-166.patch applied cleanly for me on: Drupal core 10.2.4 and Conditional Fields 4.x-dev@dev. Thanks!

Thanks for all the reports, all the hard work and efforts in here. It seems we are close before committing but there are still some fishy nit picks to clarify:

In the first patches from #65 - #87

the function arguments type definitions in the line changes near 242/335 look like this:

 *   Note that you don't need to manually set all these options, since default
 *   settings are always provided.
 */
-function conditional_fields_attach_dependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0) {
+function conditional_fields_attach_dependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0, $paragraph_info = []) {

From patches starting at #98 and after this line change looks like this:

*   Note that you don't need to manually set all these options, since default
*   settings are always provided.
*/
-  public function attachDependency(array &$form, &$form_state, $dependee, $dependent, array $options, $id = 0) {
+  public function attachDependency(&$form, &$form_state, $dependee, $dependent, $options, $id = 0, $paragraph_info = []) {

Which indicates that another issue or patch which has been committed already somewhere else add a array typehint definition into this lines function arguments, which has been removed in this patch history here again. Maybe accidentally for historical reasons of the patches along the time? I am not deep enough into this issue here to know if this is problematic, so I set it to PMNMI with the hope that some of the ones who worked on the patches can clarify this for me. And I wasn't able to find the spot where this has been added in another issue. Would be great if we can find it.

After that I will go on reviewing and testing and discussing the commit with other maintainers.

EDIT: Oh and what about tests? Such a big addition needs tests. Anyone?

Awesome work in here +1!

I hope everyone doesn't mind. In attempting to answer @dqd's question I converted this to a merge request.

I find them significantly easier to review.

That line was changed in 3217413

I think this typehint change was in error, I will revert that.

I've also hidden all of the patches hoping we can collaborate on the MR and get this across the finish line soon!

Thanks for clarifying where it came from @nicxvan! +1

I am fine with MR or patches or both, what ever contributors prefer to help in the issue queue. I try to prepare another BETA release any time soon and I appreciate all help, because it was a huge attempt to clean up the issue queue over the last weeks.

While type hinting isn't a deal breaker I just think: Beside if you use autocomplete software like some IDEs, type hinting and writing the doc string aside from being a good practice for understandable code, will immensely help such tools to actually write the whole function almost itself. Writing good doc string and type hinting is doing all devs a favor. How often we have type error issues in all the issues queues ... countless. Great to see this clarified.

I do not want to turn down progress here but wouldn't it be great to have tests here on such a big addition? Anyone who could chime in here?

When applying the current state of the MR, I'm getting these warnings in a non-paragraphs context:

@#175: the latest MR only fixes the type hint nit pick mentioned before. So your issues probably indicates that the whole patch as-is from before has flaws and needs further testing or you run into something else mixed with this here. Please provide more backtrace or error report logs and how exactly you humbled into this.

I see what it is: $is_related_to_paragraph is set within an else statement so if that logic path was hit then the variable will not be defined.
I have added a default.

Do you have any pointers on writing tests for this patch for someone that is able to contribute: would ConditionalFieldEntityReferenceTest be a good place to start?

I'm not actually using this patch any more so I don't have an easy way to verify this patch is working, I'm just trying to unblock it a bit.

Hid additional patches: @andreasderijcke can you retest with the latest MR?

@nicxvan: Warnings are gone.
The context was conditional fields on block content entities.

Thanks @nicxvan! Very much appreciated that you still keep track on this. +1 . And I fully see your shared time issue. Same here. I try to help making Conditional Fields stable as soon as possible as a newly added maintainer in cooperation with the other maintainers while I am not using it at the moment. I run 3 Drupal test installs (9/10/11) for it on our servers. It is good to split efforts so that single contributors do not run out of time on it, so, we can try to find others to help on tests as long as you could keep track on that patch you provided. That would help me a lot in case of new reports coming in on this patch.

And thanks @all others for keeping up reporting. This is very important top move on. Just please try to make your reports understandable as much as possible so that any misunderstandings can be prevented and others who want to help can clearly follow your report.

Also - a comment to some previous contributions in here (a little bit longer ago) it is not helpful to post patches in here which fix individual user problems with certain versions or even worse with merged patches from other issues. Next contributors pick on this and run into confusion... Please let us work together on latest dev so that we can merge this into the upcoming BETA release, where most of the users in here can go on with.

Thanks at all! Keep it coming!

We are also experiencing this issue. While testing the current MR, 2902164-controlled-by-fields I noticed it also reorders the field's in the edit form when said field is inside of a details tab.
My paragraph had
field
field number 2
details tab
details tab number 2
embeded paragraph.

After applying the patch and trying to hide details tab number 2 with field number 2. The layout of the paragraph form switched to this.
field
field number 2
details tab
embeded paragraph.
details tab number 2

It did not hide the details tab number 2 but it did move it around.

My test was on
core: 10.2.5
paragraphs: 8.x-1.17
cond fields: 4.x-dev

Patch https://www.drupal.org/files/issues/2023-09-28/2902164-149.patch and 4.0.0-alpha5 seems to work for the most part except inside a group fields detail tabs, the parent and children would not hide even when the option was checked. However, I was able to hide regular paragraphs fields based another text list or drop down paragraph field.
This might be a good starting point to figure out why it broke on the new MR.

That said, the current MR does not seem to work with paragraphs. https://git.drupalcode.org/project/conditional_fields/-/merge_requests/4...
My assumption is that https://www.drupal.org/project/conditional_fields/issues/2856720, the work related to supporting inline entities stepped on this.
I tried to apply the changes from #149 to the current MR on DrupalPod and most of the code overlap and highlights are related to the inline entities MR changes. It might be tricky to support both plus layout builder and not step on each other as the code in here seems to be growing in complexity and has started to lose some of it separation of concerns. Maybe a good problem to have since that mean more community will get behind it but a tricky one.

I can experience this issue on Drupal 10.2.6 with Conditional Fields 4.x dev

Patch apply does not work:
https://www.drupal.org/files/issues/2024-02-21/2902164-159.patch (Conditional Fields)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2024-02-21/2902164-159.patch

Added a rule inside Paragraph bundle in /admin/structure/conditional_fields/paragraph/my_paragraph

Merge requests are against dev not the the most recent tagged release, that is likely why it is not applying.

I did just look at rebasing and it's up to date so it should work.

I downloaded the patch from the merge request, but unfortunately, it didn't work for me. I'm currently using version 4.0.0-alpha5 and I've attached the patch that worked for me in case it helps others

Hi jjose.quevedo
The comment #184 explains why it doesn't apply against any tagged release.

The issue still needs to be fixed in the latest dev version, the alpha5 version is already released so no chance to be fixed there.
It is quite useful to specify in the comment the version that your patch applies, thanks for that and the contribution.

Also if you're providing a patch for an issue with a merge request make sure you hide it so that work is focused in the merge request.

Hi rodrigoaguilera and nicxvan, thank you for letting me know. FYI: I've had to reupload the patch added in comment #185 due to an error I discovered. It should be working fine now.

The last patch added is not getting applied on the current version 4.x-alpha5, so reimplemented the patch.
There is one issue after applying this patch the required validation is not working for the media fields only the asterisk is visible.

Just wanted to give a heads up that the problem reported by riskogab in comment #105 is still an issue with the latest patch (comment #189). Using a List (text) field with unlimited allowed values using the checkboxes widget as a Controlled By field does not work inside a paragraph, though other field types do, and it does work on a node.

Was getting a warning regarding an array key with #189 so I updated the patch with that seemed to fix it for me.

Error in question:
Warning: Undefined array key "field_profiles" in Drupal\conditional_fields\ConditionalFieldsFormHelper::dependentValidate() (line 475 of /app/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php)

Please update the merge request.

Conditional_fields 4.x-dev
Drupal 10.3.2
php8.2
applied MR

There is not a 'Manage Dependency' tab on the paragraph type
When I goto admin/structure/conditional_fields/paragraph/my-paragraph I can select the fields for dependency
When I hit submit, there is a WSOD.
I can go back to the page
When I click edit, there is a WSOD

|Error: Call to a member function getFormObject() on null in Drupal\conditional_fields\ConditionalFieldsFormHelper->getState() (line 318 of drupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php).

https://mysite.com/admin/structure/conditional_fields/paragraph/myparagraph|1||Warning: Undefined property: Drupal\conditional_fields\ConditionalFieldsFormHelper::$form_state in Drupal\conditional_fields\ConditionalFieldsFormHelper->getState() (line 318 ofdrupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php)

#0drupal-10.3.x/html/core/includes/bootstrap.inc(166): _drupal_error_handler_real()
2024-08-14T03:33:55.278559-07:00 mysite.com:
#1drupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php(318): _drupal_error_handler()
2024-08-14T03:33:55.278636-07:00 mysite.com: #2drupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php(249): Drupal\conditional_fields\ConditionalFieldsFormHelper->getState()
2024-08-14T03:33:55.278695-07:00 mysite.com: #3drupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php(143): Drupal\conditional_fields\ConditionalFieldsFormHelper->processDependeeFields()
2024-08-14T03:33:55.278891-07:00 mysite.com: #4drupal-10.3.x/html/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php(97): Drupal\conditional_fields\ConditionalFieldsFormHelper->processDependentFields()
2024-08-14T03:33:55.279079-07:00 mysite.com: #5drupal-10.3.x/html/modules/contrib/conditional_fields/conditional_fields.module(210): Drupal\conditional_fields\ConditionalFieldsFormHelper->afterBuild()
2024-08-14T03:33:55.279128-07:00 mysite.com: #6 [internal function]: conditional_fields_form_after_build()
2024-08-14T03:33:55.279182-07:00 mysite.com: #7drupal-10.3.x/html/core/lib/Drupal/Core/Form/FormBuilder.php(1078): call_user_func_array()
2024-08-14T03:33:55.279218-07:00 mysite.com: #8drupal-10.3.x/html/core/lib/Drupal/Core/Form/FormBuilder.php(579): Drupal\Core\Form\FormBuilder->doBuildForm()
2024-08-14T03:33:55.279284-07:00 mysite.com: #9drupal-10.3.x/html/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm()
2024-08-14T03:33:55.279338-07:00 mysite.com: #10drupal-10.3.x/html/modules/contrib/conditional_fields/src/Form/ConditionalFieldEditForm.php(600): Drupal\Core\Form\FormBuilder->buildForm()
2024-08-14T03:33:55.279371-07:00 mysite.com: #11drupal-10.3.x/html/modules/contrib/conditional_fields/src/Form/ConditionalFieldEditForm.php(171): Drupal\conditional_fields\Form\ConditionalFieldEditForm->getDummyField()
2024-08-14T03:33:55.279406-07:00 mysite.com: #12 [internal function]: Drupal\conditional_fields\Form\ConditionalFieldEditForm->buildForm()
2024-08-14T03:33:55.279439-07:00 mysite.com: #13drupal-10.3.x/html/core/lib/Drupal/Core/Form/FormBuilder.php(536): call_user_func_array()
2024-08-14T03:33:55.279472-07:00 mysite.com: #14drupal-10.3.x/html/core/lib/Drupal/Core/Form/FormBuilder.php(284): Drupal\Core\Form\FormBuilder->retrieveForm()
2024-08-14T03:33:55.279521-07:00 mysite.com: #15drupal-10.3.x/html/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm()
2024-08-14T03:33:55.279558-07:00 mysite.com: #16 [internal function]: Drupal\Core\Controller\FormController->getContentResult()
2024-08-14T03:33:55.279603-07:00 mysite.com: #17drupal-10.3.x/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
2024-08-14T03:33:55.279641-07:00 mysite.com: #18drupal-10.3.x/html/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
2024-08-14T03:33:55.279674-07:00 mysite.com: #19drupal-10.3.x/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
2024-08-14T03:33:55.279710-07:00 mysite.com: #20drupal-10.3.x/html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
2024-08-14T03:33:55.279740-07:00 mysite.com: #21drupal-10.3.x/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
2024-08-14T03:33:55.279800-07:00 mysite.com: #22drupal-10.3.x/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
2024-08-14T03:33:55.279857-07:00 mysite.com: #23drupal-10.3.x/html/modules/contrib/simple_oauth/src/HttpMiddleware/BasicAuthSwap.php(54): Symfony\Component\HttpKernel\HttpKernel->handle()
2024-08-14T03:33:55.279886-07:00 mysite.com: #24drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle()
2024-08-14T03:33:55.279920-07:00 mysite.com: #25drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
2024-08-14T03:33:55.280356-07:00 mysite.com: #26drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
2024-08-14T03:33:55.280406-07:00 mysite.com: #27drupal-10.3.x/html/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
2024-08-14T03:33:55.280728-07:00 mysite.com: #28drupal-10.3.x/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
2024-08-14T03:33:55.280778-07:00 mysite.com: #29drupal-10.3.x/html/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
2024-08-14T03:33:55.280952-07:00 mysite.com: #30drupal-10.3.x/html/modules/contrib/webform_product/src/RedirectMiddleware.php(43): Drupal\page_cache\StackMiddleware\PageCache->handle()
2024-08-14T03:33:55.281029-07:00 mysite.com: #31drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\webform_product\RedirectMiddleware->handle()
2024-08-14T03:33:55.281083-07:00 mysite.com: #32drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
2024-08-14T03:33:55.281135-07:00 mysite.com: #33drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
2024-08-14T03:33:55.281212-07:00 mysite.com: #34drupal-10.3.x/html/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
2024-08-14T03:33:55.281306-07:00 mysite.com: #35drupal-10.3.x/html/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
2024-08-14T03:33:55.281368-07:00 mysite.com: #36drupal-10.3.x/html/index.php(19): Drupal\Core\DrupalKernel->handle()
2024-08-14T03:33:55.281418-07:00 mysite.com: #37 {main}.

**** Please test to see if this patch is needed anymore ****/

I just tried conditional_fields 4.x-dev without the patch
added a select list as a control in a paragraph and 2 entity reference fields in the same paragraph.
I went to the admin/conditonal_fields and added the condition.
I was able to edit it
And when I went back to the content type that referenced the paragraph and the conditional field it worked.

Can someone else please test this onthe latest dev to see if this patch is needed anymore

The above commit fixes the issue in #195 - and seems to function.
Still seeing an issue - when a field has a condition to be required, you can see the star, but the field can be submitted without actually filling out the field. Also, if the field is marked as required but not visible, the validation is still wanting that field to be filled out. So still in "needs work" but perhaps a little better.

... more on this ...
Seems to work when the target field is text. I was testing with a select list which is not required, but with that has the option '_none' => 'None', so I think it is treating that as an option?

@socialnicheguru i still needed the patch.

I checked MR44 in combination with 4x-dev and core 10.3.2 trying to set autocomplete reference field to be controlled (both visibility and required option) by another radio buttons field and it wasn't working. What worked for me was module version alpha5 and patch in #159.

We are on Drupal core10.3.3, I initially thought that there might be something wrong with the way I am setting the condition but with paragraphs embedded on the Content types the patch submitted by#159 worked great. Thanks a lot.

I have not tested thoroughly but at least the basic show/hide working.

Tested on:
Drupal 10.3.3
Conditional fields version: 4.0.0-alpha5

Patch worked with:

Single select
Multiselect
Even tested with widgets like (Chosen for select lists)

Hopefully, this can get tested and committed soon as every other site uses Paragraphs these days.

Thank you.

Found an issue inside paragraphs it is working for user-defined fields but not working for entity reference fields, I tried with the Taxonomy terms reference field and it did not work be it is not handled currently in patch #159.

But it would be extremely beneficial to have support for entity reference fields also.

I did some additional work to get the manage dependencies tab back, the routing and the task entries and the provider were missing.

I added those and the tab shows up.

There seems to be something where sometimes the paragraph entity type is paragraph and sometimes it expects paragraphs_type which is complicating issues, but I have the form showing up for paragraphs and you can edit save and delete.

They are not working yet, but I'm looking at that now.

I'm working on a test, I expect this to fail since I just started setup.

I'm adding a paragraph with the field.
I had to add composer.json so we can add paragraphs as a dev dependency.

Gitlab seems to be having some trouble at the moment, I'll come back later
I had forgotten to update the class name for the test.

I think we just need to update ConditionalFieldParagraphsTest so the selection criteria are correct and ensure I added the paragraph and reference fields properly.

I'll see what the test says once the run finishes.

I tried cleaning up the paragraphs routing, but it did not work.

I was missing a test trait, I also enabled concurrent to see if that speeds up the tests.

Well concurrent reduced the test time to 1 minute and 30 seconds which is nice.

We can't use that create entity reference test trait obviously because it's not an entity reference.

I need to create the paragraph reference field in the article node for testing. I think this is close.

FYI: The patch generated by the MR is not applying to the @alpha5 instance

Steps to reproduce:

• Save plain diff of MR locally
• composer update drupal/conditional_fields
• observe error

There are rejections in:

• conditional_fields.module
• src/Form/ConditionalFieldDeleteFormTab.php
• src/ConditionalFieldsElementAlterHelper.php.rej
• src/ConditionalFieldsFormHelper.php.rej

Patch #190 applies cleanly. I imagine its because the target branch is 4.x instead of the @alpha tag..

Yes, the MR is against the dev version of the branch which is where it would eventually merge into before release.

I'm working on the test so we can get this merged in, I need some help with why I'm getting an error that he paragraph plugin doesn't exist.

@markie and I figured out the plugin missing issue, now the test failures are actual test failures.

Unfortunately the tests are not running locally so I'm stuck pushing them up.

I think we may just need to update selectors now, I tried setting it so the paragraph is there by default.

Ok I think there are two remaining issue for the test.
1. The form display is not right for the paragraph field on the article content type because the css selector is not finding it even though it should be there.
2. One of the test is complaining that jQuery is not available.
I think once those are resolved the tests should pass and we can get a review.

I might tinker, but if anyone has experience with the tests that would be helpful.

You can have a look at my Drupal 11 MR where all the tests are passing fine:

https://www.drupal.org/project/conditional_fields/issues/3478862

I had to make a few fixes to the tests as far as I remember.

All of the tests are passing except the new one that I need help with.

I think there is something wrong with jquery, the first error is saying there is no jquery, then it can't find the selector.

the last test commit I removed the jquery call and that test passed.

I had that same jQuery error when the test was crashing with an error 500.

Could see the stack trace when checking the generated HTML pages...

If I wasn't clear I did check your mr and didn't see anything. The weird thing is that the other tests are passing.

Let me check the output, maybe there is something there.

Not sure how I missed that, it's right there, thanks!

Ok tests are passing, this is ready for review!

Thanks for the work on this! Figured I would give this a test drive, but I think the issue summary needs updating. At least I tried to do what it says in the issue summary with `2902164-controlled-by-fields` branch applied and at commit ID 9e8cc32fae17e55ba6b95139b0ee65557bfae47a and the conditional fields are not showing/hiding

My configuration (first value is set to 'Item one', second value is set to 'Item two'):

Yet both fields still show for me:

Am I doing something wrong?

Ah I think there is one caveat that doesn't work can you test one thing? If it is what I think it is I would propose merging this in and opening another issue to resolve that issue.

Are you using the insert value from widget?

Can you try the all of these values AND?

I did see that sometimes, but wasn't able to track it down.

Thanks for the tip! That helped me explore the MR a bit more. I spotted that there was some code messing with the value for paragraphs, I removed that code + updated the tests to ensure that it covers conditional fields with 'Insert value from widget' now working too.

(By the way, if it helps I use this https://github.com/ddev/ddev-contrib/blob/master/docker-compose-services... to run the functional JS tests as they don't run with just a clean install. It says obsolete and I haven't tried the replacement, but this does still work fine - I can then run ddev exec phpunit -c core/phpunit.xml modules/contrib/conditional_fields/tests/src/FunctionalJavascript/ConditionalFieldParagraphsTest.php locally)

I can't really RTBC it any more now that I have contributed to it, but FWIW the rest all seems to work fine, so perhaps if someone can do one more test on the 'Insert value from widget', we can shift it back to there to get it infront of maintainer's eyes.

Thank you so much! I'll check out that functional js test tip later!

So thankful to see progress on this! I reviewed and tested this patch... I can verify the code looks good, and the conditional fields worked as expected in my testing.

The work in here is simply overwhelming. +1 Special thanks to all who kept track on this. Especially on nicxvan, BetoAveiga, jeffschuler, scott_euser, mparker17

Only concern I still had lately was that comment #147 hasn't been addressed yet. After having a chat on Slack with @nicxvan today agreeing about that we will put this in a follow-up, I'll commit this awesome work in here now to get it (finally!) done.

Thanks to

• nicxvan
• BetoAveiga at Lullabot
• jeffschuler at Substrate Websoft for Cleveland Museum of Art
• scott_euser at Soapbox
• mparker17 at Consensus Enterprises for Health Canada - HPFB
• thatguy at Siili Solutions
• m.anoune
• jjose.quevedo at weKnow Inc, Phase2
• artis at Texas Creative
• pp.panatom
• rutiolma at iO
• spurlos at JAKALA (formerly FFW) for NBCUniversal
• andreastkdf at Soapbox
• scott_earnest
• slayne40
• beunerd
• sahilgidwani at Axelerant for Drupal India Association
• nkind at zu
• chandeepkhosa at 2Toucans
• andreasderijcke at Calibrate
• usman_ahmed
• avpaderno
• socialnicheguru
• colan at Colan Schwartz Consulting, Consensus Enterprises
• marcvangend at LimoenGroen
• M_Z
• irsar
• shelane
• rcodina
• mariohernandez
• bernardm28 at Vaultes
• andysipple
• sime at Australian Competition and Consumer Commission (ACCC)
• prashant.c at QED42 for Drupal India Association
• amaisano
• arthur.baghdasar
• mably at Bordeaux Metropole
• coaston
• sergiu stici at JAKALA (formerly FFW)
• sarathkm at Valuebound
• careboll72
• chike at Skillmatic Ace

Most of the patch providers have been added (credited) on the commit. Again, thanks at all for the hard work in here!

This change appears to have caused an interesting regression that breaks Inline Entity Form support when the inline entity form has a conditional date field and the parent node edit form also has conditional fields:

Uncaught PHP Exception TypeError: "Drupal\Component\Utility\NestedArray::getValue(): Argument #2 ($parents) must be of type array, null given, called in /app/web/modules/contrib/conditional_fields/src/ConditionalFieldsFormHelper.php on line 894" at /app/web/core/lib/Drupal/Component/Utility/NestedArray.php line 69

Steps to reproduce:
1. Create new Drupal 10 site with Standard profile
2. Enable modules: inline_entity_form:3.0.0-rc20 and conditional_fields:dev-4.x#962c0a83
3. Add new Content entity reference field to the Article content type: field_pages
4. Set field to unlimited cardinality and limit references to the "Basic page" content type
5. Edit Article form display, set field_pages to Inline Entity Form - Simple widget
6. Add new condition to the Article content type: field_image visible when title has value "test"
7. Add new Date (Date-only) field to the "Basic page" content type: field_date
8. Add new condition to the "Basic page" content type: field_date visible when title has value "test"
9. Go to create a new Article. Scroll to field_pages and add two blank entries. After attempting to add a 3rd entity under field_pages, you will start receiving the error. If you satisfy the condition by setting the title to "test", it lets you add another entity, but if the title is anything else, you will get an error.

Repeating the above steps on the prior commit 25ef661e, it works fine.

Interesting. Thanks for the report. Can you make sure that you did not fall into: #3489179: Referring the same entity multiple times breaks _referringItem or #2940605: Can only intentionally re-render an entity with references 20 times ? Otherwise we need more other reports on this since yours seem to be a very special steps chain to reproduce.

Can you open a new issue with that and post it related here?

It seems the conditional field is not working with the image field.

I have paragraph type as Test in that I have two fields, one is URL as a text-formated type and the second is Thumbnail as an image-type field with an Entity Browser widget.

I have added dependencies as making a thumbnail image is required when URL field is filled

I have added the Test paragraph in the Block as entity referenced.

While adding content in the Block Thumbnail field is getting required. However, in the DOM I can see this attributes [required="required" aria-required="true"] getting added based on the URL field value change.

On saving the block, the field required condition is getting passed here.

Hello, I could not apply patch #159 with latest version of Conditional Fields (4.0.0-alpha6). But it is ok with 4.0.0-alpha5.

I haven't had time to look yet to see if this patch can be easily remade.

This has been merged.

#235: please file a new issue.
#236: please read about issue workflows, patches, MR's, dev snapshots, commit and release policies. This issue is fixed and merged like nicxvan already explained. Follow ups should point against latest dev. All maintainers and contributors in the issues of CF here try to help to get a final release asap, if times allows us to work on it.

After upgrading the module from version 4.0.0-alpha5 to 4.0.0-alpha6, I encountered the warning and error detailed in issue #3495402: Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues().

Upon investigation, I discovered that three specific lines were removed by this issue's commit at line https://git.drupalcode.org/project/conditional_fields/-/commit/962c0a834....

To address the issue, I submitted a merge request in the same issue #3495402: Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues() to reinstate these lines.

Hi, I've installed the 4.x-dev version of the module, but the conditional field inside the paragraph doesn't work yet, any idea? I've tried the alpha-6 and the dev versions both, but not works.
I'm using also Drupal 10.3.10.

Thanks.