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

Created on 11 July 2017, about 8 years ago
Updated 9 February 2023, over 2 years ago

Based on #2803875: Node form meta information should not come from a theme and #2882801: Review and improve the media creation form , I had the idea that we could let entity forms/modules opt-in to the seven sidebar by setting a flag on the form structure, for example $form['#sidebar'] = TRUE. possibly also on the specific elements that should be in the sidebar, although that could maybe be done through the existing group functionality as well.

Not sure yet about all the details, as the current implementation relies on a specific template that seven activates for node but is actually defined in node.module (yep, weird) and it does not have columns in node, but in *classy*.

So maybe instead of introducing a flag, we could just introduce a content-entity-edit-form template that seven can override and make it two-column? Not sure about BC for node, though.

📌 Task
Status

Needs work

Version

10.1

Component
Entity 

Last updated about 2 hours ago

Created by

🇨🇭Switzerland berdir Switzerland

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇷🇴Romania bogdan.racz

    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.

  • 🇷🇴Romania bogdan.dinu

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

  • last update about 2 years ago
    Patch Failed to Apply
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update about 2 years ago
    Patch Failed to Apply
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update about 2 years ago
    Custom Commands Failed
  • last update about 2 years ago
    Custom Commands Failed
  • 🇮🇳India _utsavsharma

    Fixed CCF for 10.1.x.
    Please review.

  • last update about 2 years ago
    28,694 pass, 232 fail
  • 🇬🇧United Kingdom joachim

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

  • 🇧🇾Belarus impol

    Re-rolled #48 for 10.2.x

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MariaDB 10.3.22
    last update over 1 year ago
    Custom Commands Failed
  • 🇧🇾Belarus impol

    Fixed some missed files on #50

  • Status changed to Needs review over 1 year ago
  • Status changed to Needs work over 1 year ago
  • 🇺🇸United States smustgrave

    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

  • 🇺🇸United States angrytoast PNW

    https://www.drupal.org/project/drupal/issues/2519362 📌 Redesign the menu link add form to be less overwhelming Fixed 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?

  • 🇷🇴Romania bogdan.dinu

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

  • Merge request !9082#2893740 → (Open) created by joachim
  • 🇬🇧United Kingdom joachim

    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?')

  • Pipeline finished with Failed
    about 1 year ago
    Total: 182s
    #244547
  • 🇬🇧United Kingdom joachim

    > https://www.drupal.org/project/drupal/issues/2519362 📌 Redesign the menu link add form to be less overwhelming Fixed 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, 📌 Redesign the menu link add form to be less overwhelming Fixed 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.

  • 🇩🇪Germany Anybody Porta Westfalica

    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.

  • 🇳🇱Netherlands ricardopeters

    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?

  • 🇳🇱Netherlands ricardopeters

    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?

  • 🇬🇧United Kingdom joachim

    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.

  • 🇳🇱Netherlands ricardopeters

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

Production build 0.71.5 2024