Allow form modes to use default operation if a form operation is not explicitly set

the problem here that contrib module developers will require to check each form-alter for class to make sure that edit/delete or other form is used that makes hook_form_FORM_ID_alter() a regression

This feature are assumed in form_mode_manager module. I guess we can reproduce similar mecanism onto this issue ?

I don't quite understand the problem in #8.

What would hook_form_FORM_ID_alter() do at the moment that this patch would prevent?

Given the forms in question can't be output at the moment anyway, who would be altering them?

Update patch to current version. Work great on my side (with a Group entity). Thanks stevector

Update patch to core 8.7

fall_back patch for 8.6.15

Here is my fix for #18

Sorry, was attached a wrong patch.
This patch should be better

I don't understand why it failed.
Trying this one

+++ b/core/lib/Drupal/Core/Entity/EntityTypeManager.php
@@ -220,7 +220,12 @@ public function getListBuilder($entity_type_id) {
     if (!$class = $this->getDefinition($entity_type_id, TRUE)->getFormClass($operation)) {
-      throw new InvalidPluginDefinitionException($entity_type_id, sprintf('The "%s" entity type did not specify a "%s" form class.', $entity_type_id, $operation));
+      // If there is not a class specified for this operation, try the default
+      // class. This condition is likely used by form modes added through
+      // the form modes user interface.
+      if (!$class = $this->getDefinition($entity_type_id, TRUE)->getFormClass('default')) {

I recall there was reason to have no fallback to default

The condition was added in this issue: https://www.drupal.org/project/drupal/issues/2168333
But I can't see any mentioning anywhere in this issue or any other issue why there's no fallback. However for custom entities maybe there are some cases when the fallback won't work properly if the default/add/edit all different or just the first and last two.

Anyway, for me, this #24 patch works in my scenarios.

Instead of falling back to default I would prefer that we can choose the form handler during the form mode creation process.
Making this more explicit will be more understandable for developers and for site builders.

We can let the user select either a form class to be used or a form operation from which to dynamically retrieve the form class. I think that we need both options to make it more flexible.

I disagree with it, if we let the 'user' choose, then there's no guarantee the chosen class can handle the entity properly (except if you filtering really well). You need to make sure somehow that class can handle the entity properly. These are by default the default, add, edit and delete forms, which the entity annotates (from here the first three is the same most cases, except if you have a custom entity but in that case any way you need to define in code your form handler). Besides that, if we allow the user to choose which form builder he wants to use then we need to allow which display render want to use, I mean currently in the system there are fallbacks (i.e. manage display I'm pretty sure that also falls back to default), if the fallback is not good to you, then you can define your own way, in this case, i.e. hook_entity_type_build(). And personally I don't want to use a system that looks like a dog and behaves like a cat, it just increases the complexity.

In short, I don't see any reason to do it in 99.99% of the cases.

if we let the 'user' choose, then there's no guarantee the chosen class can handle the entity properly (except if you filtering really well)

But that is valid for the default form class as well. There is no promise for it being an universal one. Following this logic this issue would be "won't fix" simply because there is no guarantee that any of the form handlers can manage the form display.

I feel like developers needing more custom form behavior should be able to write or specify the form class they want to use in code. Adding a form class discovery system seems like unnecessary complication to this issue.

It should be assumed that the entity's default form should be able to correctly display the form. If it can't, that should be considered a problem with the entity's default form, not with using the 'default' form mode as a default.

I could see an argument being made to allow the site builder to select an operation from those defined on the entity type to create a new form mode for, but that seems like it should go in a follow up to this issue.

Rerolled against 8.9.x.

This patch might fix the failed tests of patch #34.

code is fairly old, doesn't pass commit checks anymore for 10.1.x

Address Drupal CS issue of patch #37.

By mistake added a patch twice.

Not sure #8 was answered
Reading the comments doesn't seem like there is an agreement on the solution forward.

I just separated and expanded on the form operations documentation at https://www.drupal.org/docs/drupal-apis/entity-api/display-modes-view-mo... it might be useful when considering this patch.

In light of the clarity brought by reading all the code relating to that handbook page I would like to offer a few observations. I have no opinion whether this patch should or should not be added, a few things are worth noting:

1. Currently array_keys($entity_type->getHandlerClass('form')) retrieves all possible values that can be passed to the second argument to getFormObject($entity_type->id(), $operation) and after the patch this will not be case. However, I am not sure this is an API, it's certainly not documented: the only slight hint in the doxygen is the fact @return can be an array on getHandlerClass(). But that's just a slight hint. Neither getFromClass() nor getFormObject() mentions this. It is also not clear to me why would anyone need to enumerate all possible form operations. So it's possible this is still not an API change but IMO it's worth considering this briefly.
2. Currently, there is some operation fallback in DefaultHtmlRouteProvider for add-form and edit-form. This is why HtmlEntityFormController / EntityTypeManager work without a problem even if add/edit is not defined as a form operation. For example, User defines the edit-form link template but not an edit form operation.
3. Even with this patch, any UI defined form modes would still not provide anything to the user. No pages, no local tabs, no modals, no nothing. Cstom code is still necssary for any of that to happen. In light of that and what DefaultHtmlRouteProvider does, is this the place to do the fallback? Or perhaps the custom code should do the fallback?
4. If the patch is accepted, the fallback from DefaultHtmlRouteProvider could be removed. The routes and the entity form display objects and alter hooks would all get "add" / "edit" as form mode versus just "default". Core currently works around this in, for example, media where the add and edit operations are separately defined (but are handled by the same form class). Perhaps this could be removed as well. Perhaps in a followup. But if such cleanups are deemed worthy to be doing that's an argument in favor of the patch.
5. Perhaps the fallback should be optional. collectRenderDisplay has such an argument, for example.

> Currently array_keys($entity_type->getHandlerClass('form')) retrieves all possible values that can be passed to the second argument to getFormObject($entity_type->id(), $operation) and after the patch this will not be case.

I don't understand this at all -- the patch doesn't touch getHandlerClass() at all.

> However, I am not sure this is an API, it's certainly not documented

The @return also says 'handlers' plural, so I'd consider this to be documented.

(BTW see also #3295307: EntityTypeManager::getHandler() doesn't allow for nesting.)

> I don't understand this at all -- the patch doesn't touch getHandlerClass() at all.

Currently, if you want to know what $operation can you pass to getFormObject, the answer is: whatever getHandlerClass() return. After the patch it is, I believe, "anything". That's the difference I was pointing to.

Ah ok I think I understand.

Currently, the valid values for the $operation parameter of EntityTypeManager::getFormObject($entity_type_id, $operation) are specifically the array keys in the returned array from $entity_type->getHandlerClass('form').

After the patch, you could call EntityTypeManager::getFormObject($entity_type_id, 'any old rubbish I made up') and get back the default form operation.

So it's a DX question - is it the right behaviour to fallback silently, or should it complain that the $operation is invalid.

It's clearly not the intention that you can invent a form operation on the fly -- the docs for getHandlerClasses() say:

* - form: An associative array where the keys are the names of the
* different form operations (such as 'create', 'edit', or 'delete') and
* the values are the names of the handler classes for those
* operations. The name of the operation is passed also to the form

For someone looking for a temporary solution before fixing this issue, you can do like this to get a custom form
It will add to handlers['form']['custom_mode'] = handlers['form']['default']

 $handler_type = $this->entityTypeManager()->getDefinition($entity_type, TRUE);
    $default_handler_class = $handler_type->getFormClass('default'); 
// or $default_handler_class = $handler_type->getHandlerClasses()['form']['default']; 
      $mode = 'custom_mode';
      $handler_type->setFormClass($mode, $default_handler_class);
    $form = $this->entityTypeManager()->getFormObject($entity_type, $mode)->setEntity($entity);