EntityQueueHandlerInterface defines a settingsForm() method, which takes no arguments and the comment says "Generates a settings form for this handler."
Even if a handler overrides this method, as BrokenEntityQueueHandler does, the settingsForm method is never called anywhere. From the comment, I would assume that it should allow handlers to add to the /admin/structure/entityqueue/list/%entityqueue_queue/edit form. It should probably also allow handlers to add elements to /admin/structure/entityqueue/add as well. In order to work on the add page it would either have to:
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | entityqueue-call-settings-form-2145631-2.patch | 4.08 KB | jojonaloha |
Comments
Comment #1
jojonaloha commentedIn working on #2508431: An entity queue for each term? I found the need for this issue to be fixed first. Attached is a patch that calls this method for each handler and hides it using Form #states depending on which handler is selected. When editing an Entityqueue it only calls the settingsForm method for the queue's handler, since we do not allow that to change. Also there is an API change, the settingsForm method now takes $form_state by reference. I needed access to that in working on #2508431: An entity queue for each term? and I think any handler that does implement this method will likely want that as well.
Comment #2
moonray commentedThis mostly works for me. The only issue I run into is this:
If a settings form for a handler that isn't selected includes required items, they block the form from being submitted.
Comment #3
quicksketchYeah, this is a blocking item here. Instead of just using #states, we'd probably need to use #ajax and show/hide sections of the configuration form based on which handler is selected.
Comment #4
amateescu commentedClosing issues for the 7.x version, which is not supported anymore.