- Issue created by @fago
- Merge request !55Issue #3446302 by fago: Improve labelling of checkbox to take over entity rendering. → (Merged) created by fago
- 🇦🇹Austria fago Vienna
ok, I worked over the checkbox labelling and logic, please see
https://git.drupalcode.org/project/custom_elements/-/merge_requests/55/d...
I think we can merge this is as a first step.> - Fix editing keys and pressing save bug
I took a quick look at this. This is not as simple as I hoped it is. Turns out there is some complex ajax-refresh logic going on, which is handled/implemented by the attached JS library "field_ui.js" ($form['#attached']['library'][] = 'field_ui/drupal.field_ui'). It seems this JS is atm necessary to handle updates of the region field when elements are moved into "hidden" and back to "content" region. This JS also somehow takes care of changing the submitted POST data to incude the "name" field.let's also check whether we can drop this:
* \Drupal\custom_elements_ui\Plugin\Derivative\CustomElementsUiLocalTask::alterLocalTasks
* custom_elements_ui_local_tasks_alter()
seems unneeded to me. - 🇦🇹Austria fago Vienna
created https://www.drupal.org/project/custom_elements/issues/3446485 📌 Simplify entity-ce-display form and AJAX logic Active as follow-up
- First commit to issue fork.
- 🇭🇺Hungary junkuncz
Okay I'll do the class merge.
Regarding the local tasks: looks like unfortunately we cannot drop out that hook at
https://git.drupalcode.org/project/views_local_tasks/-/blob/1.0.x/views_...
https://git.drupalcode.org/project/custom_elements/-/blob/3.x/modules/cu...It's weird but probably there is no better way atm.
- Assigned to junkuncz
- Status changed to Needs work
6 months ago 8:14am 13 May 2024 - Issue was unassigned.
- Status changed to Needs review
6 months ago 9:49am 13 May 2024 -
fago →
committed 4da2b1e9 on 3.x authored by
junkuncz →
Issue #3446302 by junkuncz: Refactor to remove...
-
fago →
committed 4da2b1e9 on 3.x authored by
junkuncz →
- Status changed to Needs work
6 months ago 11:36am 13 May 2024 - 🇦🇹Austria fago Vienna
thanks, works well, merged. thus, this point is still open, right?
- Empty plugin settings forms should not see a "settingsForm" edit icon
- Status changed to Needs review
6 months ago 10:13am 14 May 2024 - 🇭🇺Hungary junkuncz
DONE:
- empty plugin settings forms should not see a "settingsForm" edit icon
- hide "extra fields" on EntityCustomElementsDisplayEditForm
- move some logic from buildForm() to form() (it was a debt from an earlier MR)
- a few tiny code clean-up - 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU
Oops - mismatching availability may mean this waits until Thursday before I merge this -- because I had a question about the "Empty plugin settings forms should not see a "settingsForm" edit icon".
I guess that's fine though.
- Status changed to Needs work
6 months ago 1:04pm 15 May 2024 - 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU
Pushed inconsequential commit to this issue -- only to prevent merge conflicts (that would have occurred if I pushed it elsewhere)
- Status changed to Needs review
6 months ago 1:04pm 15 May 2024 -
roderik →
committed aa717899 on 3.x authored by
junkuncz →
Issue #3446302 by junkuncz, fago: Improve entity display editing UI
-
roderik →
committed aa717899 on 3.x authored by
junkuncz →
- Status changed to Fixed
6 months ago 8:49am 16 May 2024 - 🇦🇹Austria fago Vienna
Thanks for bringing this home! When reviewing changes, I found an issue with it though. Created 🐛 Entity-CE-Display form incorrectly assumes every plugin has a settings-form key Active .
Automatically closed - issue fixed for 2 weeks with no activity.