Use hook_entity_form_display_alter() instead of Layout Builder's custom overrides display altering hook

1. +++ b/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php
   @@ -65,6 +65,9 @@ class EntityFormDisplay extends EntityDisplayBase implements EntityFormDisplayIn
   +   *   (Optional) If the render display should be instantiated without
   

   Optional -> optional.

2. +++ b/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php
   @@ -65,6 +65,9 @@ class EntityFormDisplay extends EntityDisplayBase implements EntityFormDisplayIn
   +   *   attempting to load any display from configuration.
   

   Defaults to FALSE. ;)

3. +++ b/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php
   @@ -72,28 +75,30 @@ class EntityFormDisplay extends EntityDisplayBase implements EntityFormDisplayIn
   +    if (!$transient) {
   

   How about returning early instead of nesting everything inside this check?

4. +++ b/core/modules/layout_builder/src/Form/OverridesEntityForm.php
   @@ -76,24 +76,16 @@ public function getBaseFormId() {
   +    $form_display = EntityFormDisplay::collectRenderDisplay($this->entity, $this->getOperation());
   

   Shouldn't we call it with $transient = TRUE? :)

+++ b/core/modules/layout_builder/src/Form/OverridesEntityForm.php
@@ -76,24 +76,15 @@ public function getBaseFormId() {
+    $this->setOperation('layout_builder');

This shouldn't be needed because the form operation is already defined as layout_builder in the entity definition.

Maybe we should also introduce EntityDisplayBase::TRANSIENT_MODE or something?

I don't think we need that IMO, CUSTOM_MODE describes it well and Views uses it for the same use case :)

+++ b/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php
@@ -65,6 +65,9 @@ class EntityFormDisplay extends EntityDisplayBase implements EntityFormDisplayIn
+   * @param bool $transient
+   *   (optional) If the render display should be instantiated without
+   *   attempting to load any display from configuration. Defaults to FALSE.

@@ -103,6 +108,7 @@ public static function collectRenderDisplay(FieldableEntityInterface $entity, $f
+        'skipDisplayInitialization' => $transient,

The naming of transient here is coupling WHAT the code does with WHY someone would want to do it.

Also, this variable does multiple things:

1. Prevents a saved display from being loaded
2. Prevents the default/fallback from being used
3. Expands the logic in EDB::init() from only working for custom modes to custom modes and those that set skipDisplayInitialization to TRUE

The changes within CM and LB look good, so I'm happy with the approach. Just concerned about communicating what this means, and subtly changing how important/necessary CUSTOM_MODE is

I think it mostly needs naming/docs improvements, not necessarily a new implementation.

I think this is NW now based on Tim's feedback..

How about changing the variable name to $default_fallback (or $load_default?) and make it only about whether we should attempt to load the default display from configuration. This would allow people to save a layout_builder form display in config, and I think that's a feature that we shouldn't try to prevent..

Also, I don't think that using EntityDisplayBase::CUSTOM_MODE as the 'final' mode for the form display object is that problematic, developers have two ways of getting the 'initial' form mode that was requested: EntityDisplayInterface::getOriginalMode() and the $context['form_mode'] argument of hook_entity_form_display_alter().

+++ b/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php
@@ -82,7 +86,9 @@ public static function collectRenderDisplay(FieldableEntityInterface $entity, $f
-    $candidate_ids[] = $entity_type . '.' . $bundle . '.default';
+    if ($default_fallback) {
+      $candidate_ids[] = $entity_type . '.' . $bundle . '.default';
+    }

@@ -101,7 +107,7 @@ public static function collectRenderDisplay(FieldableEntityInterface $entity, $f
-        'mode' => $form_mode,
+        'mode' => $default_fallback ? $form_mode : static::CUSTOM_MODE,

Oh this is so much clearer!

Thanks, this would be great to land in 8.7 before that Layout Builder hook is in the wild.

Since this hook was in 8.7.0-alpha1 we need to write a CR and release note for the removal

Updates the IS with a release note and wrote a CR: https://www.drupal.org/node/3042512

Making the release note a bit clearer about the limited scope of the BC break.

Not a beta target, though. This needs to be committed before the beta phase begins. If it had not landed by today it would simply have needed to follow the deprecation process instead

Committed to 8.8.x and cherry-picked to 8.7.x. Thanks!

Tagging for the release notes. (We'll include this in the beta release notes, but probably will remove it for the 8.7.0 minor notes since the BC break does not affect updates from 8.6.)

Oops, also belatedly published the CR.