- 🇷🇴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. - last update
over 1 year ago Patch Failed to Apply - last update
over 1 year ago Patch Failed to Apply - last update
over 1 year ago Custom Commands Failed - last update
over 1 year ago Custom Commands Failed - last update
over 1 year 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.
- last update
11 months ago Custom Commands Failed - Status changed to Needs review
11 months ago 1:54pm 10 January 2024 - Status changed to Needs work
11 months ago 3:44pm 10 January 2024 - 🇺🇸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 Princeton, NJ
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? - 🇬🇧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?')
- 🇬🇧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?