Other entities work but without the additional manage display path like on node types

hi Prashant

I am just looking into this module for use with custom entities myself, and when I saw your issue my heart sank, because it seemed like I would have to reimplement all my conditional fields manually. However, based on my initial investigations it may not be that bad.

My own custom entities have been built in code with the aid of Drupal Console, rather than ECK, so I am not sure if the same will apply here. But it is worth a try.

If you go to /admin/structure/conditional_fields/ you should see a list of all entities. Unfortunately the code assumes they have bundles, even though mine do not, so you have to double nest the entity type as a bundle type, but if you drill down to

/admin/structure/conditional_fields/your_entity_type/your_entity_type/

you should see...... well, actually you might still see nothing. For reasons I will explain technically below. However I found a little non-technical workaround. If you visit the form display settings tab of your custom entity's settings - most likely at /admin/structure/your_entity_type/settings/form-display - do nothing, and press save, then refresh the conditional fields manager, you should be able to add new conditions in the same as way as for nodes.

In this fashion I have successfully added a conditional field to one of my custom entities.

This post has been made assuming you are a 'site builder' aiming to operate via the UI. I will make a follow up post with a more programmer -centric explanation in case you would rather work in code, and for the attention of the maintainers.

Adding the "Manage dependencies" tab to custom entities' settings page

The 'Manage dependencies' tab is created by a combination of the conditional_fields.links.task.yml, the conditional_fields.tab route in .routing.yml and the ConditionalFieldController::provideArguments method.

Unfortunately the routing hardcodes base_route: entity.node_type.edit_form and the controller hardcodes the string 'node', but it is relatively simple to copy, paste and tweak these to point at a particular custom entity type instead. By doing so I have been able to get the tab to appear on my custom entity with relative ease, and if you only need this to work for 1 or 2 custom entities, which will never change, you may perhaps resort to this approach. Obviously, though, this copypaste approach is a terribly shabby solution, which is why I'm not posting it as a patch or even block of example code...

Assuming I don't run into a showstopping reason in the next few days of investigation why I cannot proceed with this module, I will look at writing some sort of dynamic route enhancement to solve this in a non-horrible way, however I would be interested to hear back from the maintainers whether they are amenable to incorporating such work, or if they have hardcoded nodes in this fashion due to a deliberate design decision that this module should only be available for nodes. (Perhaps bigger dragons lay lurking that I have yet to encounter with custom entities)

Secondly and imo more interestingly I would like to share the results of my investigation into why custom entities (often) come up blank even when accessing them via /admin/structure/conditional_fields/

The problem here lies in src/Form/ConditionalFieldForm.php, line 232, which loads the $form_display_entity from the EntityTypeManager service's storage. Ironically, the authors of this module have done things the right way, which causes the problem - because core is inconsistent and a bit half-baked.

From the comments in includes/entity.inc:

We do not preemptively create new entity form display configuration entries for each existing entity type and bundle whenever a new form mode becomes available. Instead, configuration entries are only created when an entity form display is explicitly configured and saved.

In other words, unless you go through the UI and click 'save' on a form display settings page, no config representing this display is created and put into storage. Hence my recommendation to go through the rigmarole of doing so in the previous comment, as an easy workaround.

But then I wondered, if my entity forms have no corresponding form display item created until I explicitly configure and save, how come my custom entity CRUD forms have been working fine all this time? How exactly do I go to /my_custom_entity/{id}/edit and have that page work, if my form display item is missing? I deduced that something in core must be doing some logic like:

 $form_display = fetch_from_config_or_storage_or_whatever($entity_type, $form_mode);
if (!$form_display) {
  $form_display = generate_implicit_config_derived_from_basefielddefs_or_whatever($entity_type, $form_mode);
}

Well, I poked around and eventually found exactly that. My typical entity CRUD forms are coming from core/modules/field_ui/src/Form/EntityFormDisplayEditForm.php calling the global, deprecated function entity_get_form_display().

The entity_get_form_display() function perfectly handles this "if it exists, use it, if not, create/infer it" logic exactly as suspected. But it's deprecated. That's weird.... another round of googling and finally we get somewhere.

https://www.drupal.org/node/2835616 admits that although this has been deprecated since before 8.0 was released, no replacement has ever been made, leaving core to continue to rely on it.

The issue to fix it, https://www.drupal.org/project/drupal/issues/2367933 seems to have stalled 6 months ago after getting mired in 'big picture' difficulties.

Thus we are left in the strange position where core does things "the wrong way" according to core standards, by using a deprecated function, and therefore works; and Conditional Fields laudably does things "the right way", by avoiding it, and ends up broken as a result.

until #2367933 ix fixed in core it seems to me that the only reasonable options are to either

(a) reinvent the entity_get_form_display() wheel each and every time Conditional Fields needs to access this form display item (seems stupid to me - DRY)
(b) write our own module-specific wrapper for this logic, which will, inevitably, come out identical to entity_get_form_display(), by dint of solving the exact same problem (also seems stupid to me)
(c) rewrite line 232 and other instances (e.g. line 168) to use entity_get_form_display() , despite the deprecation, on the basis that tons of core itself is still using it, no reasonable alternative has been provided and having been outstanding since before 8.0 and a fairly dormant issue it does not look likely that it will be provided any time soon. As such one would hopefully expect entity_get_form_display() would not actually be removed soon, either, so it is reasonably safe to use it.

Option c would therefore be my call, and I have verified that making this change locally allows me to use conditional fields on any custom entity, without going through the faff of manually saving each of their respective form display settings in the UI. However, I am of course not the maintainers of this module and they may take a difference stance.

As above I await with interest any input from the maintainers since the site I am currently building is almost entirely made with custom entities and will require many conditional fields. Whether it is collaborating on this module or going off and doing my own thing I will have to get it working one way or another (including also support for inline entity forms and multistep entity forms), but obviously I would much prefer the former :)

We are starting in on a project that requires Conditional Fields to work with the Group module, which defines a Group (and Group Relation) entity type. I think @stevekeiretsu is right and option c is the way to go. @stevekeiretsu do you think you could put up a patch for this so we can see exactly how to go about this?

I'm actually finding that setting things up via /admin/structure/conditional_fields works just fine. I was a bit confused that there was not a Manage Dependencies tab on the Group entity types, but so far so good.

I'm not familiar with that module but my guess would be that something in the install/setup code explicitly creates form display config(s) for the entity/ies it proves. Thus obviating the need for either the UI workaround or the change to entity_get_form_display()

To be fair it has occured to me since that the case of having entities with no explicit form display config created may be a rare one, and there could be an option (d) I didn't consider, which is that core devs believe there should always be such a corresponding config item available and it's the responsibility of anyone creating an entity to make sure it does exist. That doesnt smell right to me, because I don't think nodes etc follow that rule, but who am I to say :)

In the meantime I've actually kind of abandoned the use of this module because as far as I can see, the main thing it delivers is the ability to manage these conditions via the UI, whereas I would actually prefer to keep them locked in code, and it turns out using the form #states API directly is very easy (albeit mildly broken, requiring me to also borrow some of this module's javascript improvements to core) and much more lightweight. All of which is a long way of apologising for not including a proper patch right now. If I get a chance I will dig out the old branch with my hacked up copy of the module but in the end, as far as I remember, I only needed to replace line 232 + line 168 of src/Form/ConditionalFieldForm.php with an equivalent entity_get_form_display() call - it should be self-explanatory when you see those lines in context.

First approach at embracing all kinds of entities, including non-Core entities that implement a link template "conditional-fields" in their entity annotation. I borrowed some code from auto_entitylabel, where I helped enabling custom entities as well, see #2945387-5: Support entities without bundles (User, etc.).

As I said, this is just a first approach, and with quite some remnants and inconsistencies left, it is in need for a proper cleanup. However from what I manually tested, everything should work quite well. Please test and help bringing it forward.

The patch above works for me for custom user fields. I will do more tests and will let you know if I find any issues.

Indeed, patch #9 doesn't apply anymore.

Here's a new patch, basically just a reroll, aside from reordering the constructor's arguments and adding a missing parameter hint.
From a very basic first test it seems like there are many bugs left, though the #9 version seemed to work quite fine on my custom entities. I need to take a few hours off and work through every aspect step by step.

As I need this for a current project, I will most probably finish it soon, however certainly not this week, neither next week when I'm on holidays. So everybody please feel free to push it forward.

17 fails,just like the last patch #9 one month ago.

I have tried the latest patch from #12.
It solves the core entities problem, I see the block types now have the new "Manage dependencies" tab.
It does not seem to solve the problem for non-core case.
I see that the added conditional_fields_entity_type_alter() is only modifying the core provided entities.
For instance, paragraph entity types do not have the "Manage dependencies" tab.
If I remove the constraint in the patch to only target core entities, which seems to be about taxonomy terms and user entity types, I could see it correctly.
Attaching here a patch for that change.
Back to NR for the tests to run, and produce the same results as before.

> #7 I'm actually finding that setting things up via /admin/structure/conditional_fields works just fine

Hmm. I found that I could set them up there (admin/structure/conditional_fields/paragraph/my_para).
Indeed, all the configuration would save, but conditional fields were not being hidden/shown when editing the paragraph content.

> #14 Patch

After applying that patch and attempting to use with paragraphs, I encountered several problems.

A) While a new "Manage dependencies" tab appeared on the paragraph type I was attempting to apply it to, I could not add/remove conditions.

A.1) When attempting to add conditions I received ...

Drupal\Core\Routing\UrlGenerator->getRoute('entity.my_Para.conditionals') (Line: 271)
Drupal\Core\Routing\UrlGenerator->generateFromRoute('entity.my_para.conditionals', Array, Array, 1) (Line: 105)
Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute('entity.my_para.conditionals', Array, Array, 1) (Line: 753)
Drupal\Core\Url->toString(1) (Line: 174)
Drupal\Core\Utility\LinkGenerator->generate(Object, Object) (Line: 94)
Drupal\Core\Render\Element\Link::preRenderLink(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 58)
__TwigTemplate_d8cc0bfa9062f4451f75954e87e15bb12a273baede349045f858950f2fde23e0->doDisplay(Array, Array) (Line: 443)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 414)
Twig\Template->display(Array) (Line: 422)
Twig\Template->render(Array) (Line: 64)
twig_render_template('core/themes/classy/templates/form/confirm-form.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('confirm_form', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

A.2) Likewise, when attempting to remove them I received ..

Drupal\Core\Routing\UrlGenerator->getRoute('entity.my_para.conditionals') (Line: 271)
Drupal\Core\Routing\UrlGenerator->generateFromRoute('entity.my_para.conditionals', Array, Array, 1) (Line: 105)
Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute('entity.my_para.conditionals', Array, Array, ) (Line: 753)
Drupal\Core\Url->toString() (Line: 130)
Drupal\Core\Form\FormSubmitter->redirectForm(Object) (Line: 77)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder->processForm('conditional_field_edit_form_tab', Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder->buildForm('conditional_field_edit_form_tab', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

B) When visiting admin/structure/conditional_fields/paragraph/my_para, I received the following warnings/notices ...

Notice: Undefined index: parameters in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 104 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php).
Drupal\conditional_fields\Form\ConditionalFieldForm->__construct(Object, Object, Object, Object, Object) (Line: 128)
 ... 
Warning: array_keys() expects parameter 1 to be array, null given in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 104 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php).
Drupal\conditional_fields\Form\ConditionalFieldForm->__construct(Object, Object, Object, Object, Object) (Line: 128)
 ...
Warning: array_shift() expects parameter 1 to be array, null given in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 105 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php).

I believe this patch fixes the remaining routing issues.

I have not, however, managed to get states correctly applied to Paragraph entities when using Inline Entity Form.

More investigation required.

Sorry, trying that one again.

I'm using 8.x-1.0-alpha5 with Drupal 8.7.2 and I the patch from #17 is not applying

Hi, I've updated the patch for the latest -dev.

P.S: I'm trying the module using Layout Builder Modal and the conditional field doesn't work in this case.

@FiNex can you please provide some step by step instructions on how to apply your patch please?

@the_glitch: hi, I've only adapted the patch #17 to be applied to -dev, I don't know if it still apply to the current -dev. Anyway the method is simple, you can read all about it on the following page: https://www.drupal.org/patch/apply

Got it working with patch #20.

I have tested the "1.x-dev" version of this module with patch (#20):

(Drupal 8.7.9)

My need was to add 'Dependencies' to Taxonomy Terms. So far, it works flawlessly.

Thanks for the contrib!
(The least I could do was report my results..)

patch #20 is apply successfully

It works fine for taxonomy and node but

When tried to add the Conditional fields inside Paragraph types and save setting, I encounter the following error.

LogicException: Getting the base fields is not supported for entity type Paragraphs type. in Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions() (line 209 of /var/www/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php).

Paragraphs Module Version 8.x-1.10
Conditional_fields Version 8.x-1.0-alpha6
Drupal Version 8.8.1
PHP Version 7.3.11

field_states_ui does the same function but works in paragraphs. It has a few patches that need applying.

Just discovered that issue. I am surprised that it is not written in the description of the module that it is working only for nodes. It took me a while to realize that it was not working for blocks.

Hello,

like jungKunwar, I get the same error with the patch #20 when I add a conditional field on paragraph...
Before to apply the patch, I could add a condionnal field on paragraph in /admin/structure/conditional_fields/paragraph.

Here is all the errors/notices in the logs :

Notice : Undefined index: parameters dans Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (/srv/data/web/vhosts/myserver.com/htdocs/modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php ligne 105)...

...

Warning : array_keys() expects parameter 1 to be array, null given dans Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (/srv/data/web/vhosts/myserver.com/htdocs/modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php ligne 105)

...

Warning : array_shift() expects parameter 1 to be array, null given dans Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (/srv/data/web/vhosts/myserver.com/htdocs/modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php ligne 106)

...

LogicException : Getting the base fields is not supported for entity type Type de paragraphes. dans Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions() (ligne 209 de /srv/data/web/vhosts/myserver.Com/htdocs/core/lib/Drupal/Core/Entity/EntityFieldManager.php).

Re-rolled from the latest dev, and added some fixes related to this issue https://www.drupal.org/project/conditional_fields/issues/3084107

Hello,

I fix some error on Drupal 9.
First, EnhancerInterface instead of RouteEnhancerInterface interface.
And I replace entity.manager dependencies with entity_type.manager.

Anyway the patch didn't work for me with a fresh D9 install, the lastest conditionnal_fields dev release and this patch.

My first fix was not complete, here the complete patch file.

I'll still working on a paragraph support as I need it on one of my project.

32 did not work : errors :
Notice: Undefined index: parameters in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 74 of modules\conditional_fields\src\Form\ConditionalFieldForm.php).
Warning: array_keys() expects parameter 1 to be array, null given in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 74 of modules\conditional_fields\src\Form\ConditionalFieldForm.php).
Warning: array_shift() expects parameter 1 to be array, null given in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 75 of modules\conditional_fields\src\Form\ConditionalFieldForm.php).

#32 throws even more warnings than mentioned in #33

Notice: Undefined index: #type in conditional_fields_attach_dependency() (Zeile 307 in /web/modules/contrib/conditional_fields/conditional_fields.module)

Warning: array_keys() expects parameter 1 to be array, null given in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (Zeile 74 in /web/modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php)

Also, it does not work at all for me.

Any suggestion for what alternative module to use for Block Type?

@Farnoosh You could give Field States UI a try.

Re-rolling patch.

It is also not working for me with a taxonomy term reference controller field, in either 8.x-1.0-alpha10 or 4.x-dev. I've tried with the target as autocomplete or Simple Hierarchical Select.

I am using Drupal 9.1.8. Patch #37 would apply to 8.x-1.0-alpha10 but when I deleted a dependency I got this error:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getDefinition() on null in Drupal\conditional_fields\Form\ConditionalFieldDeleteFormTab->getCancelUrl() (line 24 of modules\contrib\conditional_fields\src\Form\ConditionalFieldDeleteFormTab.php).

After that, on /admin/structure/conditional_fields/media/image I get these errors:

Notice: Undefined index: parameters in Drupal\conditional_fields\Form\ConditionalFieldForm->__construct() (line 97 of modules\contrib\conditional_fields\src\Form\ConditionalFieldForm.php).

Hi Nick,
For the taxonomy it works for me, without that patch.

Just do not select widget type as it does not work, but AND(second option with the ability to writte custom) and write the taxonomy tag IDs one by one so insted "Yes" you can put "1", but in select list you will still see "Yes".

Hope it helps.

Thank you @coaston. That works, at least for making the target field visible/invisible.

#37 does not apply to 4.0.0.-alpha1

I think i had some odd paragraph bundle corrupted when cloning fields to it from a node bundles using Field Tools module. This gave me an error and no CF UI when i went to the CF settings for that paragraph bundle. Started looking for patches including this one and non applied.. but these are all very old and certainly this must work now??

Tried a vanilla d9 site and para/cf works. Tried another para bundle on my site and it does work. Removed all the cloned fields and that bundle still broken. Deleted bundle and added fresh. Added a couple simple fields.. P/CF works fine. Re-cloned all the fields over - it still works.. very odd..

--------------

spoke too soon. After rebuilding the bundle the UI does work now.. but adding a dependency and it crashes.

Patch introduces deprecated entity.manager

I updated the patch on #37 so it applies to 4.x. The failed hunk was on ConditionalFieldDeleteFormTab::getCancelUrl method. Needs extra work and review.

Still needs work and review.

Re-rolled for latest 4.x-dev.
(A couple line changes no longer necessary because fixed in #3191870: Warning: Undefined variable $entity_type in Drupal\conditional_fields\Form\ConditionalFieldForm->buildTable() (line 297 (commit).

Testing for #46 on 10.1.2

Patch applies successful.

Working with Comments on a Media type.

Unable to add conditional to a List (text) and have a conditional List (text) display.

Error is:

"Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of core/lib/Drupal/Core/Entity/EntityTypeManager.php)."

Thanks for your efforts on this!

I have created few entities and bundles using ECK module https://www.drupal.org/project/eck
but Conditional Field module is displaying "Manage Dependencies" tab only for Content Types not for any other entities.
Basically it only working for node types.

This is a assumption caused by the circumstance that you don't "see" something in UI. That does not mean, it doesn't exist.

Tested latest Conditional Fields with ECK custom types successfully here. And the misleading aspect of it is that only the manage display tab is missing. But the ECK types are listed under admin/structure/conditional_fields and setting up works fur supported field types wihtout flaws. If some underlying functionality is silently broken is not tested yet of course. But I do not see any issues here after some days testing despite of the issues of some field types, which are already reported elsewhere, and do not belong to this particular issue here. Maybe some parts of it have been addressed and merged already in other issues like stated some comments above. So we need some more reports here.

Note: The manage display tab is just a nice additional give away. And opinionated from my POV. The introduction could be based on the confusion users had by setting up CF under a different path than the content type. But field form widgets can create issues sometimes, as we all know in the nested ajax field order form. That's why CF works in most cases better than similar modules trying to tame field form widgets.

The additional tab close to the fields under manage display was a good compromise back then to minimize UI confusion. Added additionally to the existing path under admin/structure/conditional_fields, where you can set up the conditions without field form widgets or manage display tabs coming into mix.

I would rather recommend to stop adding tabs under entity type manage display pages in future and leave the settings under the admin/structure/conditional_fields path with good documentation on it so that users understand why. Also from mobil first aspects that is a better route.

That reduces maintenance and unclutters the manage display UI and makes the module more flexible out of the box without hunting the white rabbit in adding forms to any possible place in UI where field bundles and manage display pages are involved.

Before we can go on here we need more confirmation of users that CF does not work with ECK by using it under admin/structure/conditional_fields and making sure that occurring issues really belong to ECK support and do NOT appear on same field types under common Entity type "Node" as well.

The patch #46 is creating a new class Drupal\conditional_fields\Routing\RouteEnhancer which contains the use statement:
use Symfony\Cmf\Component\Routing\RouteObjectInterface;
That class has been deprecated, so the use statement needs to be replaced with:
use Drupal\Core\Routing\RouteObjectInterface;

In addition, the patch also creates the class Drupal\conditional_fields\Routing\RouteSubscriber, which contains the method getSubscribedEvents(). The method signature needs to be changed to match the signature of the method in RouteSubscriberBase which is being extended:
public static function getSubscribedEvents(): array

Aagh... Missing semicolon from the replacement user statement. Fixed.

Thanks for all the hard work in here @all over the time. And thanks for all the reports in between.

But please: Again, like described in my long comment before, please post more reports validating that CF would NOT work with other than node types. Because I already confirmed that it works with ECK types out of the box in the comment above. And #42 confirms that too.

We should not post further patches here before we have not discussed the maybe missing parts this issue should be focused on now. Like for example the managed display admin path on custom entities.

To not confuse other users I change the title and temp hide the patches until somebody chimes in to respond to my comments and is able to discuss the updated patch direction for this issue.