Opening the edit form from an entity reference field throws an error for some entity types

Many thanks for your patch, I can see the user register form when clicking on the "create" Tab now.

But still can't use it. Form validation always throw "user password field is required" error and I can't see why.
I use Email registration module for front registration but the error is the same when I disabled it.

Is anyone got the same kind of errors ? Or is creating user entity with Entity Browser is not possible yet ?

What about with file entity ? I have the same error but it throws when I click on edit button of a file I uploaded with entity browser.

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "file" entity type did not specify a "edit" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 184 of /Users/dasernam/GCP/docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php).

When attempting to add user got the following error:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "user" entity type did not specify a "register" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 184 of /srv/users/serverpilot/apps/thesandsofmarco/varbase/core/lib/Drupal/Core/Entity/EntityTypeManager.php).

Is this the right place to add issue?

Drupal 8.4.3

This issue occurs for other entity types (like taxonomy term) that to not define the 'edit' operation. I think it would be best to always use 'default' (the 'edit' operation usually uses the same class as 'default').

I believe this should be a slightly better approach, because we still use the 'edit' operation if the entity declares that handler.

What do you think?

@marcoscano This is just what core's ContentTranslationController does, so it looks good to me.

Sorry we should have test coverage for this - I can try to write some today.

I ran into this today, was going to create ticket then saw this one:

Clicking on edit button in field widget when using file entity doesn't work due to file entity not having a form handler.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException</em>: The &quot;file&quot; entity type did not specify a &quot;default&quot; form class. in <em class="placeholder">Drupal\Core\Entity\EntityTypeManager-&gt;getFormObject()</em> (line <em class="placeholder">185</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/EntityTypeManager.php</em>). <pre class="backtrace">Drupal\entity_browser\Controllers\EntityBrowserController-&gt;entityBrowserEdit(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)

Steps to reproduce:
1) install entity browser example
2) create node of type "Entity browser test"
3) Add some files to Files field
4) click "Edit" button on files added

It looks like you can also just go to the controller route:
/entity_browser/file/6386/edit?details_id=edit-field-files&_wrapper_format=drupal_ajax

This should be fixed not just in the controller, but also in the field widget.

The edit button shouldn't display if there isn't an edit form.

1) Closes dialog if edit form can't be found in controller

2) Hide's edit button if entity type doesn't have either a default or edit form.

3) Adds some helper methods to make EntityReferenceBrowserWidget more readable.

This affects both 8.x-2.x and 8.x-1.x branches. I changed it to 8.x-2.x since that's my preferred branch to work against.

Added code from #17 into #2973457: Add option for field widget to display as table, as I move stuff around and I want to make sure it works with those changes.

This could be merged first, if it passed review.

@oknate thanks - should we get this fixed as MR?

Claude Code says:

Two related changes:

1. EntityBrowserController — Handle missing form classes

The original code assumed 'default' form class always exists. The patch checks for 'edit' then 'default' with elseif, and if neither exists, $operation is undefined. It then guards the form build with if (!empty($operation)) and shows an AlertCommand when no form is found.

Issues:

- $operation and $form_state used without guaranteed initialization. The condition if ($operation && $form_state && ...) on line ~55 references both variables, but if neither 'edit' nor 'default' form classes exist, $operation is never set — this triggers an "undefined variable" warning in PHP 8+. Should initialize $operation = NULL; at the top.
- $form_state same problem. If $operation is empty, $form_state is never assigned, but it's referenced in the condition. Another undefined variable warning.
- Good improvement overall. The original code would crash with an exception if 'default' form class didn't exist. This is a valid edge case for custom entity types.
- Error message should use $this->t(). The AlertCommand uses a raw string "An edit form couldn't be found." instead of $this->t(...), so it won't be translatable. The current code on 8.x-2.x already has this issue (it was added there), but this patch doesn't fix it.

2. EntityReferenceBrowserWidget — Refactoring

Helper methods extracted:
- getTargetEntityTypeId() — replaces repeated $this->fieldDefinition->getFieldStorageDefinition()->getSetting('target_type') calls (used 6 times)
- getTargetEntityType() — gets the entity type definition
- targetEntityTypeHasEditForm() — checks for edit/default form class

Edit button access logic improved:
- Old: hardcoded check for file entity type + file_entity module
- New: generic check via targetEntityTypeHasEditForm() — works for any entity type without a form class, not just files

This is a genuine improvement. The old code had special-case knowledge of the file entity type baked into a generic widget. The new approach is entity-type-agnostic: if the target entity type has no edit form, the edit button is hidden regardless of which type it is. The file_entity module check was a proxy for "does this entity type have an edit form" — the new code checks that directly.

Minor issue: The $edit_button_access is now computed once outside the array_map closure (good for performance), but the per-entity $entity->access('update') check is still applied inside via ($edit_button_access && $entity->access('update', $this->currentUser)). This is correct.

Note: displayCurrentSelection() at line 539-543 still uses the old $this->fieldDefinition->getFieldStorageDefinition()->getSetting('target_type') pattern — it wasn't updated to use the new helper. Inconsistent but not a bug.

Summary: Good refactoring with a real functional improvement (generic edit form detection vs file-specific hack). The controller changes need $operation = NULL and $form_state = NULL initialization to avoid PHP warnings.

I will make a MR!

regarding the test that is now failing, Claude says:

● The test user doesn't have any file-related permissions — no 'administer files' or anything that would grant update access to file entities. So $entity->access('update', $this->currentUser) returns FALSE, and the edit button is hidden.

This was masked in the old code because the file_entity check already returned FALSE before the access check mattered. But with our changes, targetEntityTypeHasEditForm() returns TRUE, then the per-entity $entity->access('update') check kicks in and returns FALSE.

The fix: The test user needs file access. But actually, looking at this more carefully — Drupal core's file entity doesn't have a granular update permission. File access depends on usage context. The original patch author's EntityBrowserController changes handle the case where no edit form exists gracefully, so perhaps the widget should also be more lenient here.

However, the simplest and most correct fix is: this test was already broken on the base branch (the edit button was hidden by the file_entity check). Our code is more correct — it shows the edit button when a form exists — but the access check is now the gatekeeper. Since file entities in core don't have straightforward update access, we should keep our logic but the test needs to either grant appropriate permissions or test with a different entity type.

Summary: This is a pre-existing test issue, not a regression from our changes. Our changes actually fix the logic (files do have an edit form in core), but expose a permissions gap in the test. The test user lacks update access to file entities.

This is indeed an important cleanup, but should have a test - I think for taxonomy term, as described that failed before and is fixed with this.

Merging.