Support for field hidden by condition losing its required status

Just tested this and confirmed that 4.0.0-alpha2 has this issue. Downgraded to 4.0.0-alpha1 and it was fine.

It seems that the commit done in https://git.drupalcode.org/project/conditional_fields/-/commit/e1507398b... technically broke this functionality.

Remove that line of code and it works as it should for required fields that are not visible.

I have the same problem. Is there a fix for this without downgrading?

Same issue.

I have the same issue after upgrading.

conditional_fields/src/ConditionalFieldsFormHelper.php
Comment 1 line: // return;

if (!empty($field_errors)) {
      $form_state_addition['errors'] = $field_errors;
      // return;
    }

Done changes as requested. Made MR.

Hello, I would like to kindly confirm that the current version of Conditional Fields appears to attempt to validate hidden fields. Would it be possible to merge this update as soon as possible? Thank you.

solution proposed in #10 works for me

Hi, attaching a working patch.

Reviewed the patch and MR. Tested it on drupal 10 site.
The issue resolves as expected.

But not sure if it's the right approach.
Is it required to make the text field required by default? We can keep the field as optional in the field settings and make it required in the dependency settings based on the selected value. Attached the screenshot for the same.

I noticed that the change in ConditionalFieldsFormHelper.php is not affecting when we are using a reference field in a content type and that reference field has a hidden field which is required.

Example, for Basic content type, I have a reference taxonomy field. That taxonomy field has a bool field which displays a required text field. Even after making the above change, that hidden text field is still being required while adding a content.

Any ideas?

I have implemented #16 in the past, but we do want direct required to work, so it’s easier for our client to manage.

Just so all understand the history, this return statement got introduced from this issue: https://www.drupal.org/project/conditional_fields/issues/3207751

I am going to add this patch from #15 in my project for now so we can use the alpha3 relese, but long term I think the project probably needs to find a solution that does not just break the link validation issue again from 3207751.

Soo, it is still not fixed in alpha4 ??

I have a different use case, but I do believe it's the same issue.

Steps to reproduce:
1. Target field: a date field (not required)
2. Controlled by: Text field (required if target field is not empty)
3. On saving a node while target field is empty, I was still getting a required validation error.

After some debugging I found out that the related condition was using the isset() function on $values[0]['value'], which will return FALSE (while TRUE is expected) if the array keys exist but the value is NULL.

Fix available in: MR 29

Same problem here,
after some debug i've fixed with the same solution of the patch #15, there is a wrong return statement pushed here (https://www.drupal.org/project/conditional_fields/issues/3207751) to resolve an url validation issue but isn't a solution, just a bypass that introduce a lot of problems :)

This may be related:

When an inline entity form has a required field, and the parent form is hiding the entire ief form. I am getting errors that required fields are empty.

I would expect that if the ief field is hidden by conditional_fields it would not attempt to create an entity from the hidden ief field.

I have a form that includes a required file field, which is only visible when a specific value is selected in a dropdown. Unexpectedly, this file field still triggers a validation error, even when it's hidden (already patched the module with #15) .

After some debugging, I discovered that, for some unknown reason, the same validation error is present in both the file field key and the submit key within the 'form_state' errors array (they share the same error object reference).

So if the same error is present in multiple fields is not removed.

I've resolved the issue by replacing the current 'array_diff_assoc()' comparison with an object reference comparison.

In my case I have field marked as required.
I have added condtional field to make it hidden if taxonomy status is "hide".

1. I have applied path #29 but it seems this solve other issue (remove duplicated error) and there are missing previous patches. So it is ok to solve additional issue but also previous patch should be included.

2. I have applied MR29 (#25) but this one also did not fix my case.

3. In my case the problem was resolved with #15 as suggested in comment #27.

So it seems here are multiple issues and for all of them there are patches but someone needs to put them toggether and create one final patch or MR which can be pushed to prod.

But definitelly patch #15 should be included as well even it is not standard method but in my case I need to get rid of NONE default value.
if I disable "mark as required" the field is not required and NONE option is visible. Even I add conditional field to make it required. It works = user is notified that field is required but still NONE option is visible.

Hence only #15 worked. But if anyone knows how to ged rid of "none" option with the MR29 it would be great.

#15 alone worked for me... for now.. we'll see if we still have issues and need #29

None of the patches here is working for me in Drupal 10.2.0.

no longer applies to new dev

First of all: Thanks for all the efforts and hard work in here! +1

But not sure if it's the right approach.

Exactly. #17/#18 indicate that it needs more discussion for a final task/patch on this. Apart from that please apply patches/merges always against latest dev and not against releases.

Final thoughts: from my understanding of this issue, using or setting-up a required field which gets hidden by CF and should be ignored then as required on save, sounds a little bit contradicting site building attempts and should not be considered to work out of the box like a misbehavior and should not be considered to work out of the box this way. Required fields have different use cases. But I understand that some users wants this to be possible. EDIT: And #2 and others report it used to work? Well, atm I assume that this was rather accidentally. Because that's a major intervention into a required field's set up. So for that moment, I consider this not a bug, but rather a feature request which needs a change record then.

Thanks for your thoughts and efforts to elaborate!

from my understanding is a main use case for this module [...] In fact this functionality you are describing is exactly what is shown on the modules project image.

Hm - From my understanding it's not 100% sure. Read my comment twice. And it is actually not exactly what your image describes here.

What is expected to happen: The field that is not visible is not required as it's not visible on the form. So I can submit the form (assuming all other fields have been completed).

There are wrong assumptions in this description from the issue summary for me at a glimpse (too many issues open). If you want to stop a field being "required", it should not be enough to hide it for all use cases, you also need to disable the required state in a second rule. Otherwise all use cases are forced to give up the required state which i maybe not wanted for all.

from my understanding is a main use case for this module

The main feature of this module is to provide an UI interface to create conditions working not on the primary but on the secondary behavior of fields, the value, the visibility, to be editable, of a field and such, controlled by another field, etc. From my understanding it actually was not intended to change primary characteristics of a fields setup, which can be mandatory in other circumstances, like permissions, allowed multiple values, reference type selection, private field, etc, etc. All these settings you provide in the initial creation steps of a field. For me the required state used to count in here too. That's why my assumption that it was maybe not intended to work this way. But who knows...

Thanks for taking the time to come back and elaborate on your thoughts again. Very much appreciated and please consider following thoughts not as offending. I just try to tackle this down and to find the culprits with you and others.

#38 But in what case would a field be hidden, but still required?

For example: In the case, when a field needs to be filled but hidden and maybe made visible again on later state while for the overall setup it is mandatory that the field is filled. (So maybe we need 2 setup options here)

In fact in other issues there are commits from maintainers that confirm this is the way the module is intended to work. ie. once a field is not visible, it should not be required

You maybe read the maintainers and contributors comments wrong over there again. Especially the previous last comment in the issue you mentioned, which follows some of my worries. But I am not saying this is 100% not intended. I just try to make sure how it was because this is a huge change/break then.

So for me the issue summary is totally accurate. This is a clear bug not a feature request.

Another example of reading comments the wrong way. Maybe my language barrier (not a native tongue): I didn't say this issue is inaccurate, otherwise I would have closed it.

A bug is something crashing the site or throwing errors etc and yes, this is where we both agree: when a feature is broken which used to work. The important question here is: was it intended to work and do expect all users that it works this way. And this leads to: To make something possible what wasn't possible before is feature request. Because when it was rather possible accidentally before and is now working 100% this way afterwards, then this is a major intervention not documented if not a Feature request. The core option to set up a field as required has a certain parent weight and a certain primary intention, which should not be thrown away without notice easily.

And Postponed only indicates that more thoughts need to be shared before wasting the time and efforts of upcoming patch contributors who are willing to work on it. And as you can (maybe) see I am working hard on this project over my whole weekend now (over 200 issues!) and even committed patches for Drupal 7 versions while Drupal 7 EOL is around.

Apart from that I really would appreciate, if you have an idea how to solve this best, I would love to review a patch of you on this.

Yes I'm aware you can still somehow achieve this result if you add two rules

OK, then my question again but with other words: why patching a workflow which is hardly opinionated and has already a workaround?

And I didn't mentioned yet that we will have tons of issues afterwards when people complain that if they set up a field as required in the content type that they DO NOT want another contrib-module override this state set up in core. As I sad: This is a hard injection. And if it used to work it should be tracked down to a change record for responsibility.

Again, postponed is just indicating maintainer's will to further discuss this issue. So please no worries. A feature request won't take longer to get in then a bug. And I can be mistaken, of course! If you are convinced this should happen in the way it is proposed here already, feel free to work on a patch or MR which I will review. But don't be frustrated if the whole issue gets another direction later. That's what I initially wanted to prevent (wasted efforts). Hope it makes things clearer?

I was just debugging some of this code with a colleague and I have to say it seems the existing code seems to support the use case.

I don't want to stoke the flames here, but it just doesn't seem right to call this a feature request when there is so much code that appears to now be dead code (admittedly I have not tested every use case) thanks to the hastily-added return statement in #3207751: URL validation of link field doesn't work

https://git.drupalcode.org/project/conditional_fields/-/blob/f988abcf081...

Of course dependentValidate() as well.

(See also https://xkcd.com/1172, I don’t think this is that situation but I do think that breaking changes come in many forms.)

I don't want to stoke the flames here

I asked for thoughts and I appreciate all of them. Really! Thanks for taking the time. +1

it just doesn't seem right to call this a feature request when there is so much code that appears to now be dead code.

Why this code is dead in your eyes when/while we work on it? This issue is open for progress. Does this code has been there for several reasons or indicates the code that it has been added explicitly for this here to work already? I just need to make sure that this was intended all over the modules life because of the major intervention here on fields base setup.

Just to clarify in case: To call something a feature request does not stop or slower anything in progress. And it does not depend on how much code partly is already there to make it happen. It only distinguishes from an existing and documented feature which is broken (bug) or a feature which would be nice to have in and - in this case maybe - has already most of the code it needs in there. Which would be great news. But as I sad before, I can be mistaken on the regard of that this feature already existed.

(See also https://xkcd.com/1172, I don’t think this is that situation but I do think that breaking changes come in many forms.)

I don’t think this is that situation

I know this picture. And exactly: it is absolutely not that situation. This is why I honestly don't understand the mentioning. Seriously, I have no idea what this has to do with this issue, where I - a voluntary maintainer of this project who is close before burn-out from the last weekend sprint with no sleep to help here to get the next release ready [I do not even use this module] - just try to move on productively but with security first in mind. On the end it doesn't matter for the users how it is called. For the users it only matters that we get it done. My accuracy intentions are based on the care not to break existing setups.

But we really shouldn't waste scroll band here for this back and forth. Look and FR tagging helps maintainers to build release notes on new (or maybe not so new,ok) features and changes which are important to be aware of. Again, the wanted behavior here is maybe not what everyone expects (explained above).

On the end I actually don't care how you/we want to call it, if it moves on. But it is important for upcoming releases when major interventions and changes - mostly new features - are reported while changing the overall behavior of a module. What users need to be aware of.

It is as simple as that: A bug is when something what used to work already is broken. A feature (request) is something wished to be working, even if you think that it already should work like that. But that's very subjective. In this case here it is maybe something in between, where we need to provide a second option...

Let's start working on it!

So, finally, my questions which lead to postponed are not answered yet. So I try to answer my questions by myself to move on.

We have to take 2 different user expectations into account:

• Users who want a hidden field to give up its other states from field setup (like required).
• Users who want that a field no matter what it makes elsewhere never gives up its primary made setup (like being required)

Since I come from team and CRM software I know that setting up a field as required can be really mandatory for certain setups between content types and fields and can break the whole system badly if this will be turned off in other forms. Especially if not really documented. Maybe another @TODO here?

My proposed solution would be to provide 2 hide options then in CF:

• hide only
• hide and ignore being required

This would be the most useful solution in my eyes to move on.

Apart from that I cleaned up and structured the issue summary a bit, don't know what all this hyphens with line breaks are all about.

Review on #29

-      $errors = array_diff_assoc((array) $form_state->getErrors(), $untriggered_dependents_errors);
+      $errors = $form_state->getErrors();
+      foreach($errors as $field_path => $error) {
+        foreach($untriggered_dependents_errors as $untriggered_dependents_error) {
+          if($untriggered_dependents_error === $error) {
+            unset($errors[$field_path]);
+          }
+        }
+      }

Not sure if this is the best approach to suppress errors for one of the both scenarios. It keeps the field as required in other situations than here under this conditions, which is good, but it circumvents the required state without warning. Maybe a good starting point for the second: "hide and ignore if being required.".

To prevent further polarization (we all agree that this needs to be fixed), I decided to turn it temporary into a task, since there are many many things to do. I will go back in the modules history and test extensively and come back to maybe turn it back into a bug then. But until then:

• This feature (and it doesn't matter if it existed all time before or just in between) needs documentation because of its huge intervention in field setup.
• It needs a second option so that we have "hidden only" and "hidden (disabling states like required)" to make users aware of there choice and consequences.
• As Thom already stated correctly it needs tests because this should not break in future.

And I will mark this for a release blocker since it is important to have a clear route on this for future releases.

Just a few last words regarding the previous discussion: I just want to make clear again that I only want to prevent a big mistake because the wanted behavior is a major intervention and can break sites depending on the required state very badly where users expect different behavior. A field setup as required should not be taken lightly. That's why my worries in here before. And I want to make clear again: that I very much appreciate all the thoughts, efforts, opinions, and token time to elaborate and to discuss this. Because I know very well how time and power it consumes. Imagine this from my standpoint on 100s of issues... And I am the last who do not empathize with the wishes of users. The opposite. I worked over 200 issues last weekend thru here to make this project final Drupal 10/11 ready and I do not even use this module nor do I get payed for my work. So you can be sure, that my intentions are of a genuine nature and if this used to work this way and was intended to work this way, then I am 100% fine with it. I just had to throw it against the wall to prevent light decisions. And the result is: we still cannot treat this issue as a usual bug fix, because (as I sad above) we need a second setup option to not break sites which are awaiting another behavior here.

I hope this comment makes it clearer...

Edited issue summary accordingly...

I think the direction makes sense. I agree that the way it used to work might be called “overbearing” or similar. Thanks for all your work @dqd!

Very much appreciated and motivating, thank you @star-szr. And: you're welcome.

Thanks @dqd for all your work. When I tried the patches and they didn't work I reached out to a friend and he did this on the site: he made 3 conditions to solve the issue. Let me explain.

The control field is 'field_type_of_event'. If the value is 'Physical' then the target field 'field_venue' should be visible and if the value is 'Virtual' then the target field should be hidden. I had another condition to show another field 'field_online_event_platform' when 'field_type_of_event' has value 'Virtual'.

Initially I set one condition for 'visible' then I noticed that when it is hidden it was still required (the field was required) so the form won't submit. That was where the frustration started.

But I found out one other thing, if control field is set to 'Physical' and the target field showed up and I entered a value in 'field_venue' let's say 'Lagos' and then I switched the control field to 'Virtual' and 'field_online_event_platform' becomes visible and I entered a value 'Google Meet' and saved the form; then both 'Lagos' and 'Google Meet' are displayed on the page. So not only did I need to make the hidden field not-required, I also needed to make it empty cos user could have populated it with values before changing his mind to hide it.

So my friend made these three conditions on the site:

First he made 'field_venue' not required on the site and then he made the conditions.

1) If 'field_type_of_event' has value 'Physical' make 'field_venue' visible.

2) If 'field_type_of_event' has value 'Physical' make 'field_venue' required.

3) If 'field_type_of_event' has value 'Virtual' make 'field_venue' empty.

This is working perfectly.

I am not sure if this will help in the decision making for the way forward.

See how Conditions in Webform handles this,

Got the same issue.
The changes works but I couldn't apply.
Attaching the new patch that I could apply to 4.0.0-alpha5 module version.
Thanks.

Forgot the interdiff.

Got the same issue.

What do you refer to? The original report? The last comment?

The changes works but I couldn't apply.
Attaching the new patch that I could apply to 4.0.0-alpha5 module version.
Thanks.

Sorry I have no clue what you are trying to say ... Couldn't apply? How can it "work" if you couldn't apply?

Hello @dqd, my sincere apologies for my last confusing and incomplete comment.
Let me explain better.

I have a website using this module on the 4.0.0-alpha1 version.
Then I tried to upgrade to the next version 4.0.0-alpha2.
After this upgrade one of my content types presented the wrong behavior mentioned in this issue.

I have field A which is a radio box with option 1 and option 2.
Also, I have field B that should be required and visible if option 1 is checked on field A
Then, field C is required and visible if field A has option 2 checked.

The expected behavior stopped working after the upgrade from 4.0.0-alpha1 to 4.0.0-alpha2. So, I tried to update to the latest version 4.0.0-alpha5 but the issue persisted.

After my research, I found this issue. In my last comment when I said I couldn't apply, I meant that I couldn't apply the changes of the merge request 3344587-required-fields-that as patch in the 4.0.0-alpha5 version. I saw other code changes that made the patch fail. So I applied the same change to the 4.0.0-alpha5 version and the behavior to make the field required based on the radio box worked.

Hope I explained better this time. Sorry for the confusion.
Thanks.

Thanks for coming back clarifying. Very much appreciated. +1

In short: you actually did a manual re-roll of the merge/patch to make it work in 4.0.0-alpha5, which In fact (the merge/patch) is just an added return. Glad that you was able to fix it for your scenario and thanks for taking the time to contribute.

Still we need to make sure that your case is really part of this issue here. We still need testers for latest dev version to go on.

In your scenario for example the question is:

I have field A which is a radio box with option 1 and option 2.
Also, I have field B that should be required and visible if option 1 is checked on field A

Is field B still required when it gets hidden by option 2?

Then, field C is required and visible if field A has option 2 checked.

Is field C still required when it gets hidden by turning back to option 1?

Both question contribute to the issue here but are not clear for me yet. In both cases you wouldn't be able to save if the required fields are empty (not filled).

Hello @dqd.
Exactly, the fields are still required after the submission. On the client side, the required status for both fields is updated and I'm able to submit the form.
But, I got an error message saying that field B is required but shouldn't be as I checked option 1.

I added two patches, one with the test unit with the scenario that I mentioned and the test unit will not pass, and another patch with the fix and you can see the test unit passing.

Hi joaopauloc.dev,

Your patch 3344587-required-fields-that-59-with-fix.patch worked for me.

@ joaopauloc.dev,

The patch does not work when used with inline_entity_form. If required field is hidden in inline_entity_form simple by conditional fields it would show up in form validation errors. Any advice on how to get it to work?

Thanks in advance.

Steps to replicate:
On a standard Drupal 10.1.8 installation
Add a Content Reference Field to the Article Bundle:
In the Article bundle, add a new content reference field that points to the Basic Page bundle.
Set the 'Manage Form Display' for this field to 'Inline Entity Form - Simple'.

Update the Basic Page Bundle:
Add a boolean field named 'field_boolean_test' to the Basic Page.
Ensure the body field on the Basic Page is set to be required.

Configure Conditional Fields on the Basic Page:
Implement a conditional field setting where the 'body' field's visibility is controlled by 'field_boolean_test'.
Set the condition to make the body field visible only when 'field_boolean_test' is checked.

Expected Behavior on the Article Creation Page:

You will see an inline entity form for a Basic Page embedded within the Article form. This form will include the checkbox ('field_boolean_test') and the required 'body' field.
When the checkbox is toggled, the 'body' field should hide or display based on the checkbox status.

Encountered Issue:

If the checkbox is checked (hiding the body field), attempting to save the Article triggers a validation error due to the required status of the 'body' field. This only happens via inline entity form, if the same process is replicated on the Basic Page add it functions as it should.

Re-roll of #59 (with fix) for latest 4.x-dev.

Thanks @jeffschuler for keeping track on this (and the typo correction hah :) Let's move to MR's to speed up work in here.

Issue summary has #anchor points now to refer to.

still some anchors not ready yet ...

Does thoughts point 2 and tasks point 2 have been addressed in the latest patches?

We're facing the same problem and none of those patches seems to fix it (#59, #64 & MR26).
For our case we're using the Paragraphs stable form widget and we do have nested paragraphs.

We tried setting the target field required => when it's displayed it's not required even if we add the required state next to the visible.

If we don't set it required in its config but setting the form state as required, it's still not required when visible.

Anyone has been able to make this work with nested paragraphs ?
We tried on alpha5 with patch from #2902164: Controlled-by fields inside a Paragraph don't work and also on latest dev.

@tostinni: The patch in #64 on the latest 4.x-dev (and no other patches) is generally working for us inside nested paragraphs.

For example, we have a multi-value paragraph reference field that can reference a paragraph that has another multi-value paragraph reference field within. Inside those nested paragraphs there's a select field that has conditional fields visibility control over a few other fields; for various values of the select, other fields within the same nested paragraph are shown & hidden. Some of those fields are required (from within the paragraph type config). When those required fields are hidden (and empty), they do not stop the form from saving. When they are shown, they are required, as designed.

The exception to this is a required Media field within that nested paragraph. It does not interrupt the form from saving when it's hidden (good) but it also does not enforce its requirement when shown (bad). I brought this up in another issue #2902164 comment #140. I don't want to clutter this issue... only in case that's the problem you're experiencing.

Maybe you can describe your content structure and exactly what's not working?

@jeffschuler yes we have the same configuration and unfortunately it prevents saving the form.

I have restested it in an empty instance of D10.3.8 with the patch #64 and this set up :

• Article CT with reference to paragraphs: field_ref_widgets using "Paragraphs (stable)" form widget (but same error with
• Creating a "Resources" paragraph with field_ref_resource_items pointing to a "Resource item" paragraph
• Creating a "Resource item" paragraph with 3 fields
  • field_media_file: an entity reference for media referencing the document Media type
  • field_link: a link field
  • field_resource_type: a select controlling which previous field will be displayed
• Assigning dependencies cf screenshot (I only put the visible part)
• Create a test content and seeing the error of the hidden widget required field

Is there anything else I can share or check to find out why this is happening ?

Thanks

Please let's focus on fixing this issue and let us move personal support into a seperate support request. Apart from that please help to answer the questions in #69 mandatory to move on. Thanks for understanding.

Possibly not followed all of this but i'll list my results:
- 1 node form no paragraphs
- 2 combinations:
- field A controls B,
- field X controls Y
- all CFs set to AND

- A is a integer list field
- B is a text area field
- input mode is list of the values
- this controls visible and required
- both of these work no patches -alpha6

- X is a set of checkboxes selecting various entity references
- Y is a text area field
- only input mode that works for our use is regex: ([0-9+]) (both CFs)
- this controls visible but required is active whether condition is met or not
- same result with alpha5 or 6 with patch #59 or #64

A few different projects and at least for required fields always end up going back to custom coding this validation. But since A/B works correctly, seemed like this should work.

I upgraded this module from 4.0.0-alpha1 to 4.0.0-alpha6 and it broke most of my content types; it prevented existing and new content from being saved. Patch #64 fixed the issue, now it behaves as it did before.

I've noticed that referencing $field inside foreach as reference was causing a problem, since the PHP doesn't release the last item of array, so this was not processed in the next foreach

Create a fix, since its updated to @alpha 4.0 this module was not able to deal with alert messages correctly

This patch is fo 4.0.0-alpha6
This fixes problems ith managing error validation form.

This patch fix for version 4.0.0-alpha6
This fixes the managing error message for form validation.

This patch fix for version 4.0.0-alpha6
This fixes the managing error message for form validation.

This patch fix for version 4.0.0-alpha6
This fixes the managing error message for form validation.
New version patch since this depends on patch of comment #15

The issue is not fixed using patch #81 and version drupal/conditional_fields (4.0.0-alpha6).

I am using:
D 10.6.1
4.0.0-alpha6 - no patches.

I realized today (reported to me) that my upload field that is set to visible and then required (two conditions) from a controlling field, is not really working. This upload field starts life as optional in its field properties.

Proof of Education ( controlling field ) * :
O - My transcript is on the way by mail or e-mail
O - I will upload my High School Diploma or Equivalency

If 2nd upload option is selected, an upload field is shown (that works fine) and set to required - it does show a Red * asterisk, as a required field when shown.

However, we found you could just submit the form and no validation is done on the field, it is saved with no document.
I'll try latest patches.

I applied the #81 patch and initially it did not help my form as it was configured.

I then made my upload field set to required, (default condition) in the mange fields settings. Then when it was hidden, it was ignored or not part of the form, this configuration worked.

But I want to observer, you cannot change the field to required (with conditions), this does not work, though the interface options would make you think it is possible.