Introduce footer region to ContentEntityForm

The only class that ContentEntityForm currently explicitly defines is 'class' => ['entity-content-form-revision-information'], should we be consistent with that and use entity-content-footer or so?

This would be amazing to support workflow's additions on the form.

+++ b/core/lib/Drupal/Core/Entity/ContentEntityForm.php
@@ -127,6 +127,17 @@ public function form(array $form, FormStateInterface $form_state) {
+    if ($this->entity instanceof EntityPublishedInterface) {

I don't think we should condition this region on EntityPublishedInterface, some workflows beside Content Moderation might not care about an entity being publishable or not.

I agree with #3 and #5.

Also I wonder if it's worth pulling in $form['status']['#group'] = 'footer'; in this issue.

Sorry, #6 was more of a question than an action. I'm on the fence about putting the status field in the footer generally, or do it on a per entity form basis. I guess even if we put status in the footer in ContentEntityForm, the entity still needs to update the base field definition to display the field in the form.

We could update the base field settings on the original base field in \Drupal\Core\Entity\EntityPublishedTrait::publishedBaseFieldDefinitions?Comment entity also uses this trait, so we might have to override things there.

+++ b/core/lib/Drupal/Core/Entity/EditorialContentEntityBase.php
@@ -25,6 +25,19 @@ public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
+    if ($entity_type->hasKey('status')) {

The entity key should be 'published'.

+++ b/core/lib/Drupal/Core/Entity/EntityPublishedTrait.php
@@ -32,11 +32,26 @@ public static function publishedBaseFieldDefinitions(EntityTypeInterface $entity
-    return [$entity_type->getKey('published') => BaseFieldDefinition::create('boolean')
+    $fields = [];
+    $fields[$entity_type->getKey('published')] = BaseFieldDefinition::create('boolean')
       ->setLabel(new TranslatableMarkup('Published'))
       ->setRevisionable(TRUE)
       ->setTranslatable(TRUE)
-      ->setDefaultValue(TRUE)];
+      ->setDefaultValue(TRUE);
+
+    // Add the status form field.
+    if ($entity_type->hasKey('status')) {
+      $fields['status']->setDisplayOptions('form', [
+          'type' => 'boolean_checkbox',
+          'settings' => [
+            'display_label' => TRUE,
+          ],
+          'weight' => 120,
+        ])
+        ->setDisplayConfigurable('form', TRUE);
+    }
+
+    return $fields;

We don't need to add this on, with the if hasKey, we can just update the original BaseFieldDefinition.

(and the key is published, not status. See Node, Media, and Comment.

I don't think we should change EntityPublishedTrait to show the field by default, that's for individual entity types to decide when and how they want it displayed.

The patch in #7 was perfect IMO.

Agreed. This forces it on all entity types that implement this, it is up to them how to display it.

I'm still very confused about how exactly 9.x and deprecations and so on will work, but in theory, we could do what we did before.. introduce a setting to opt-in to this, and switch the default or remove it in 9.x, but I don't think this is worth it.

Also the CSS parts are tricky, because seven has quite a bit of node-form specific CSS, also e.g. the #edit-body thing above which is not limited to node form and is actually a configurable field, so different fields will look different. But if we suddenly apply all of that to all entity forms like comments and so on. And it's also partially tied to the node specific form alter that seven does (that we simplify but not completely remove in another issue) Maybe we could do a separte issue to introduce a something-form class that entity forms can add (or similar to above, we add by default in 9.x) to get the same styling for their forms.

Media doesn't have a status and published entity key, it just has published, but it looks like that's irrelevant if we go with the patch in #7. I would like to see an easier way to opt in or out, other than the changing the base field definition, but I guess @Berdir is right, it's not worth it.

Details elements have a useful #optional attribute, that does not show the wrapper if it is empty. That would be quite nice here as well because then we can guaranteee that the markup/output is not going to be altered unless you actually use that footer region.

Container unfortunately doesn't, and it is less likely to cause a visual change, but it could possibly still result in some additional spacing in theory.

Not sure if it's worth to add support for that for container or do a custom #pre_render for this element only here?

Tracking this, since it's something we'll need to undo once we bring layouts to entity forms.

#2893586: Add #optional support to the Container render element got in so let's use it here :)

Looks good.

That was a random fail introduced by #2526150: Database cache bins allow unlimited growth: cache DB tables of gigabytes!.

Did some manual testing of this, looks good

Can we get a change notice here selling this feature - thanks

Added Change notice https://www.drupal.org/node/2908181

Committed as 2e3db91 and pushed to 8.5.x.

Published change record.

Thanks.

Retroactively removing tag as it didn't factor into the initiative after all