"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.

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, 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 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.

There is not a 'Manage Dependency' tab on the parapgrah 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.

|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).

**** 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 smae 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 tet 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.

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 🐛 Controlled-by fields inside a Paragraph don't work Needs work 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, but 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 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 ✨ Drupal 11 compatibility fixes for conditional_fields Active

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!

scott_euser → changed the visibility of the branch 4.x to hidden.

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.

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 🐛 Controlled-by fields inside a Paragraph don't work Needs work 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
• dqd at MAROQQO studios
• 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 to the commit. Again, thanks at all for the hard work in here!

Automatically closed - issue fixed for 2 weeks with no activity.

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: 🐛 Referring the same entity multiple times breaks _referringItem Active or 🐛 Can only intentionally re-render an entity with references 20 times Needs work ? 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 described in issue 🐛 Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues() Active . Upon investigation, I found that three specific lines had been removed at https://git.drupalcode.org/project/conditional_fields/-/commit/962c0a834.... To resolve the issue, I submitted a merge request in issue 🐛 Warning: Trying to access array offset on value of type null in Drupal\conditional_fields\ConditionalFieldsFormHelper::formFieldGetValues() Active to restore these lines.