Target Field added to default form display

Here are small changes to allow using different displays for other content types.
Interdiff is not working, unfortunately.
The changes I've made is replaced the condition

if($entity_type == 'node') {

with

if (isset($condition['form_display']) && $condition['form_display'] !== 'default') {

Patch in #19 fails against version 4.0.0-alpha3

Updated patch for 4.0.0-alpha3

Can confirm patch in #21 works as expected.

Do we need to concern ourselves with backwards compatibility for folks who don't provide the additional arguments? What if a site already has a hook_conditional_fields, etc? Will those sites immediately break once this patch is added to the code base?

https://www.drupal.org/files/issues/2023-11-10/conditional_fields-suppor... →

Updated patch for 4.0.0-alpha5

The last submitted patch, 24: conditional_fields-support-form-modes-3111036-24.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Adjusted patch with proper static caching of dependencies.

Oops, fixed fatal error.

Is the goal of this to have different conditions on different form display modes? I think it would be a common use case that the conditions should be the same. There should be a way of making a default condition that applies anywhere that a more specific one does not.

It should also be considered how this would interact with ✨ Support conditional fields where the fields are on different form modes Active .

Re-rolled the patch from #27 for dev-4.x.

#27 applies to 4.0.0-alpha5, but not the dev branch.

Can't find the issue in the rush but I know there is another issue here around targeting the behavior that Conditional Fields only works if any of corresponding fields are in any of the forms, mostly at least in default form. This seems to be a requirement - or let's say - "as it works" in the moment the way Conditional Fields is build, and I am not sure if we rather need refactoring here in a bigger scope to fix this and for all other issues related and how this patch here interferes progress on this. I would prefer that Conditional Fields do not require to have any of the conditional fields in any form to be kept because rebuilding content editing UI sometimes require to move fields around and disable them here and there. In the moment Conditional Fields sometimes removes the setup then completely if a field of this condition is disabled.

Before I review and commit this I would like to get more opinions on this and of we maybe need a META to solve this from the ground up.

I have tested patch #29 and it doesn't seem to work with IEF (inline entity form) widgets when custom form mode is used under widget settings.

Testing details:
I have checked the patch on the IEF complex widget by using custom form mode (under the widget setting).
After doing some debugging from the browser inspect tab, I see the data-drupal-states attribute with the json object (i.e., #states info) is not getting rendered on the html element.

But works when form display is changed to "default" under widget settings

Because of #29 changed to Needs work.

@SocialNicheGuru: if a maintainer sets the status to "needs info" it is rather recommended to leave it up to the maintainer if the info needed is provided already (no offense) but I fully understand that we all want to ring bells to move on ;-)

Again: Please help if possible, we need answers to #30 before we can review and move on with patches.

#29 Could not apply patch!