Controlled-by fields inside a Paragraph don't work

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 🐛 "Controlled by" fields inside a Paragraph don't work Needs work worked for me. Read the comment #115 🐛 "Controlled by" fields inside a Paragraph don't work Needs work . Thanks.

Please check the comment #109,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.

Hi,
For the last version : 4.0.0-alpha2

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 🐛 "Controlled by" fields inside a Paragraph don't work Needs work 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.

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 🐛 Dependency using body as target results in "An invalid form control with name='body[0][value]' is not focusable." with ckeditor enabled Needs review

I just found out that this patch make dependencies on paragraphs work but it breaks the dependencies on nodes.

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. 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 #131.

@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 🐛 "Controlled by" fields inside a Paragraph don't work Needs work 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<code> problems with media fields inside your paragraphs.)

If you're running into the problems described in 
            
              
              
              🐛
              Hidden required field is still required
                Active
              
             & 
            
              
              
              📌
              Support field turning hidden by condition to loose its required status
                Needs work
              
            , where a field set to <code>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 my extra patch to mitigate this here (which gets applied on top of #138) in case it's useful to anyone else, and in case it 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).

This patch does not work if you set the form display for the paragraph field to Autocollapse = All

#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 🐛 Not working in layout_paragraphs Active

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 parameter type definition 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 #98 and after it 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 committed added array type definition into this line which has been removed in this patch history here again. I am not deep enough into it to know how to handle this, so I set it PMNMI with the hope that some of the ones who worked on the patches can clarify this for me.

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 make Conditional Fields stable as soon as possible as a newly added maintainer 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 I can merge this into the upcoming BETA release I plan, where most of the users in here can go on with then.

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 form switch 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.

Patch https://www.drupal.org/files/issues/2023-09-28/2902164-149.patch → and 4.0.0-alpha5 seemed to work for the most part except inside 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.

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 ✨ Support for Inline Entity Form Fixed , 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 ✨ Support for Inline Entity Form Fixed . It might be tricky to support both and then layout builder 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.