Closed (fixed)
Project:
Custom Elements
Version:
3.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
9 May 2024 at 15:20 UTC
Updated:
30 May 2024 at 09:19 UTC
Jump to comment: Most recent
There are some things that needs improvement still:
- Merge CustomElementsEntityDisplayFormBase into EntityCustomElementsDisplayEditForm
- Empty plugin settings forms should not see a "settingsForm" edit icon
- Fix editing keys and pressing save bug
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
fagoComment #3
fagocheckbox: "Force rendering as custom element"
Comment #5
fagook, 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 create a follow-up.
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.
Comment #6
fagocreated https://www.drupal.org/project/custom_elements/issues/3446485 as follow-up
Comment #9
junkunczOkay 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.
Comment #10
junkunczComment #12
junkunczComment #14
fagothanks, works well, merged. thus, this point is still open, right?
- Empty plugin settings forms should not see a "settingsForm" edit icon
Comment #16
junkunczComment #17
junkunczDONE:
- 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
Comment #18
roderikOops - 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.
Comment #19
roderikPushed inconsequential commit to this issue -- only to prevent merge conflicts (that would have occurred if I pushed it elsewhere)
Comment #20
roderikComment #22
roderikFixed, thanks!
Comment #23
fagoThanks for bringing this home! When reviewing changes, I found an issue with it though. Created #3447556: Entity-CE-Display form sometimes displays form buttons for empty forms.