Allow the sidebar for the node form to be used on other entity forms as well

Related issue in the Field group (contrib) module: #2652642: Allow to position the group in the advanced (sidebar) column

Think we need to postpone this on #2916809: Add fieldset/vertical tab for URL alias field as long as it’s a moving target. Might even become redundant, let’s see.

OK, sorry.

Slightly related.

Ok I was finally able to give this a boost. Not sure about BC, but here is a patch to introduce a content-entity-form.html.twig with 2 columns that works for all content entity types like block content, taxonomy, media and nodes (even menu links, although it looks a bit sad since there is currently very little content in the sidebar).

But now that we have it, we might want to consider moving more fields, like taxonomy relations, menu link parent/weight etc.

Attached a patch and some screenshots for seven and claro.

Minor update to fix:

1. +++ b/core/modules/system/templates/content-entity-form.html.twig
   @@ -0,0 +1,20 @@
   + * Default theme implementation for a node edit form.
   

   This should be updated.

2. +++ b/core/modules/system/templates/content-entity-form.html.twig
   rename from core/themes/classy/templates/content-edit/node-edit-form.html.twig
   rename to core/profiles/demo_umami/themes/umami/templates/classy/content-edit/content-entity-form.html.twig
   

   This should be a copy.

Here is the same as #15 but for 9.1.x.

+++ b/core/lib/Drupal/Core/Entity/ContentEntityForm.php
@@ -99,19 +130,38 @@ protected function getBundleEntity() {
+      '#access' => $this->currentUser->hasPermission('administer nodes'),

We can't depend on the node permission here, so let's remove it. Also fixed some coding standards.

I guess a way to opt-in make it less likely to have issues for existing sites. Maybe some flag in the entity type annotation?

re-roll the patch to 9.3.x

re-roll the patch to 8.9.x

Replace isPublished() with isActive() for the user entity.

Published message only for Nodes

Spent an hour this morning trying to figure out why entity add form from contrib module wasn't using the sidebar. Glad i stumbled upon this - it seems to do the trick (#17 against 9.1.13)

Thanks guys.

This will sound like a stretch.. but this patch breaks the Conditional Fields module working with Paragraphs. This patch makes major changes to ContentEntityForm.php and includes:

+    if ($this->entity instanceof EntityOwnerInterface) {
+      $form['meta']['author'] = [
+        '#type' => 'item',
+        '#title' => $this->t('Author'),
+        '#markup' => $this->entity->getOwner()->getAccountName(),
+        '#wrapper_attributes' => ['class' => ['entity-meta__author']],
+      ];
+    }

Which throws this error when trying to configure a conditional field:

Error: Call to a member function getAccountName() on null in Drupal\Core\Entity\ContentEntityForm->form() (line 200 of core/lib/Drupal/Core/Entity/ContentEntityForm.php).
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 532)
Drupal\Core\Form\FormBuilder->retrieveForm('paragraph_test_edit_form', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 568)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->getDummyField('paragraph', 'test', Array, Object, Array) (Line: 171)
Drupal\conditional_fields\Form\ConditionalFieldEditForm->buildForm(Array, Object, 'paragraph', 'test', 'field_field_1', '1fa8cd98-876f-4ca5-b818-30b6e5ae64f2')
call_user_func_array(Array, Array) (Line: 532)
Drupal\Core\Form\FormBuilder->retrieveForm('conditional_field_edit_form', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)

My guess is, for those that don't know the CF module, is that the CF setting allows users to define the control value for a field using the fields defined widget. i.e. it shows the field's widget on its config form. My guess is this patch is being too liberal with where it tries to alter the entity form. It likely needs to be limited (by route??) to actually being on that form page. Just a thought.

@berdir, you are too fast.. took a look through code a bit and yes, exactly what you said. The paragraph entity is an instance of EntityOwnerInterface and therefore has the getOwner method; but this only returns a valid owner when the paragraph is attached to a parent (its normal use); but as CF is only pulling the form field in isolation of a parent; getOwner() returns NULL.

I'd likely wrap that entire field in the owner check:

if ($this->entity instanceof EntityOwnerInterface && $this->entity->getOwner()) {

}

I can do up the patch for this.

patch for 9.3.x

@liquidcms Patch giving error while applying
Needs to Re-roll for ref sharing screenshot

Hmm, not sure that patch has anything to do with those errors. The change I made is pretty minor, does the original 9.3 patch work for you?

When I try to apply the latest patch I get lots of:

> (Stripping trailing CRs from patch.)

which might be why automated testing doesn't like it?

(BTW @vikashsoni there is no need to upload a screenshot of a failing patch, it's pointlessly using up storage space, it's enough to just say the patch doesn't apply.)

Here's a reroll on 9.4.x.

Fixed the missing parameter docs.

Re-rolled patch #36, I have provided a patch along with interdiff. Please review.

+++ b/core/themes/claro/css/layout/content-entity-form.css
@@ -6,7 +6,7 @@
+ * Layout overrides for content entity add/edit form.

In code, we should say 'node' rather than 'content entity'.

Just fixed the custom command issues in #37 patch and made the change mentioned in #38, thanks!

I'm using the patch from #39 with Drupal 9.3.12 successfully =)

The CI isn't passing for #39 😥

The Seven theme has been removed from Drupal 10 core. However, it looks like the most recent patch also changes the Claro theme to work in a similar way, so moving this to Claro for further discussion.

When using this patch in conjunction with the Webform module, the author meta information will always be there when the Webform is rendered.
Not being able to see the Author (user) name will result in a Label only form element.

I've updated the patch from #39 to work with D10.1

Fixed CCF for 10.1.x.
Please review.

I don't think this is in the right component, because most of the changes are in the entity component and the node module.

Re-rolled #48 for 10.2.x

Fixed some missed files on #50

If going to stick with patches please provide an interdiff between patches. #51 went from 31.54 to 14.88 with no interdiff or explanation.

Recommendation is MR btw.

Issue summary should follow standard issue template.

Thanks

https://www.drupal.org/project/drupal/issues/2519362 recently went into 11.x; it includes a form-two-columns abstraction which looks similar to what this issue is trying to achieve. Since that's actually in core and now a precedent, does it make sense for the work here to change and adapt to it?

I've updated the patch in#52 to work with D10.3

Made a MR from patch 57.

Tried to use the earlier patches as well, so it would preserve history, but there were too many added and rotted files -- couldn't find a core branch that the early patches would apply to (and it's surprisingly hard to find the answer to the question 'which core branch was the development branch on this date?')

> https://www.drupal.org/project/drupal/issues/2519362 recently went into 11.x; it includes a form-two-columns abstraction which looks similar to what this issue is trying to achieve. Since that's actually in core and now a precedent, does it make sense for the work here to change and adapt to it?

Yes, #2519362: Redesign the menu link add form to be less overwhelming goes in the right direction, but sadly it didn't generalise -- it adds a dedicated twig template for the menu item form.

We need to keep the generalized approach in this issue which adds a content_entity_form template.

Huge +1 on this for sbx. Currently, site builders don't understand why non-node entity forms look and behave different from node forms. It starts with taxonomy term editing and continues with widely used contrib entities like commerce products.

Adding tags accordingly.

I'm not entirely sure I'm in the right place for this. But we're experiencing a probably unwanted side effect which is that webforms now show author information underneath the form, because of the way the patch adds the meta data.

Should webform handle this (and should I create a ticket within that project). Or is this backwards compatibility breaking, and should we handle it differently?

I see #46 adresses this aswell but I do not see a follow up, it might've gone overlooked?

In light of the discussion of seanb and berdir in #19 and #20, the most BC friendly way to do this, would be having an configurable flag or indeed an annotation or a settable property, that would allow this to be optional. And maybe in a Major update enforce it, if that's a path we'd want to tale?

I think there's a cleaner way to do it than introducing an annotation flag:

- add a new class ContentEntityFormWithSidebar
- deprecate ContentEntityForm

Nothing changes for entities which use ContentEntityForm or a subclass of it.

Entity types should switch their form classes to using ContentEntityFormWithSidebar when they're ready.

Then in 12.x we remove ContentEntityForm, then rename ContentEntityFormWithSidebar to ContentEntityForm.

Sounds like a clean solution indeed, I'd agree.

I tried to rebase the MR and adapt the changes for 11.x but failed (I apologize, it was my first commit on a MR).

I still think the ContentEntityForm should have the sidebar by default because that is in my opinion the expected behavior for content entities, but I also understand that principle of finding a solution with minimal impact. For that reason I created new patches and a new MR based on @joachim's solution.

I've updated the MR and also created a new patch for 11.2.4 with all the latest changes (do not use the previous ones).

My suggestion about deprecating form classes needs more detail -- I forgot about the twig templates that are involved too! Can twig templates be deprecated?

Re-rolled #57 for 10.6.3