Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This issue does not have consensus.
By default, config entity list controllers show enable and disable operations. These are usually implemented as one-click action links.
The problem with this is (and see #1834002: Configuration delete operations are all over the place) that links perform GET requests, and those are not supposed to cause side-effects. Instead, we should remove these, and probably add a checkbox to entity edit forms with which we can control whether an entity is enabled.
Comments
Comment #1
tim.plunkettTagging. No opinions formed yet.
Comment #2
andypostOTOH we could find a way to use enable/disable
For example a contact forms could be disabled...
Anyway better to hide this links on entities that does not use status
Originally it was introduced in #1826602: Allow all configuration entities to be enabled/disabled
And here's a change notice
Comment #3
andypostComment #4
xjmRetitling for what I think the issue is actually about.
Jury's still out in my head as well. :)
Comment #5
XanoDrupal\Core\Entity\EntityListControllerInterface::getOperations()
says it Provides an array of information to build a list of operation links. The actual problem is that we are using links for tasks that should never be performed using links, whether those links are displayed as dropbuttons or not. Operation links should be used for navigation, and not for actions. See @ircmaxell's comment in #1834002: Configuration delete operations are all over the place for a better explanation.My idea was to allow entities that have statuses to be enabled/disabled using a checkbox in the edit form. I think this possibility should be available regardless of whether we remove these operation links, but that's a more personal opinion.
Comment #6
tim.plunkettTagging.
Comment #7
xjmYeah, I'm still not sold on this. IMO, operations one might perform on an entity include things like: Edit, Delete, Enable, Disable. I don't think some purism about what's links vs. buttons is reason for us to make it more work to perform these common operations, and I especially don't think it makes any sense whatsoever to change it at the controller level because the word "link" is used in documentation when in practice these are rendered in a dropbutton.
Comment #8
Bojhan CreditAttribution: Bojhan commentedI don't get what usability impact this has.
Comment #9
XanoThe word used in documentation says that those operations are intended to be used as links, which use HTTP GET. If we want to follow the HTTP spec (which I think we should), we can't perform certain operations using GET, such as enable/disable/delete, because those operations have consequences and should be performed using a different HTTP method. We actually do only display operations as links. The reason I quoted the docs, was to illustrate that we purposefully decided to use links incorrectly.
Besides, this issue is about HTML buttons (which can be used to perform non-GET requests), not HTML lists with links (which can only perform GET requests) that we style to look like buttons.
Comment #10
xjmThe usability impact is that the options to enable or disable or a view are no longer available to quickly select from the dropbutton at (e.g.)
admin/structure/views
, and you have to dig around in the Views UI to find an option to enable or disable the view. The more I think about it, the more I'm -1. If we need to have a confirm form so be it, but those operations should be available on that page.Comment #11
yoroy CreditAttribution: yoroy commentedXano: try and use as simple and specific as possible wording in your issue title. Also, it helps to state the problem first instead of a solution.
I think we are supposed to help content creators, builders, devs in roughly that order. Putting a specification in front of that listing doesn't seem useful to me.
What is the problem with GET, how big is that (potential) problem and how does that measure up against the usability trade-off?
Comment #12
XanoSee @ircmaxell's comment in #1834002: Configuration delete operations are all over the place for a better technical explanation about why using GET for actions is a problem.
I agree that the dropbuttons are extremely useful, but the specific technical implementation of one-click actions violates the HTTP specifications. This means that the implementation is buggy (and requires additional workarounds, such as CSRF tokens), but not the feature itself.
Comment #12.0
xjmUpdated issue summary.
Comment #13
XanoWith CSRF protection built into our routing system, I don't think this is really an issue anymore.