Configuration delete operations are all over the place

Before we draw conclusions too early here, I'd like to see us to investigate "what others are doing."

i.e., both competing CMS but also modern/usable web apps

I suspect that the answer will be "tab only", but then again, that's pretty dominant for a lesser-used + destructive operation, isn't it?

Tab approach is better imo:
1) menu access maps to entity operation++, delete button -- form api mess
2) delete operation needs confirmation or token - anyway we need separate url for that
3) delete should be used in vbo

Existing bugs filed against the Delete buttons:

#196758: Having delete as a button on the node edit form means certain users don't have access to it when they should
#216064: Entity form "Delete" button triggers server-side + HTML5 form validation; change "Delete" button to a link

Directly related to Delete as a tab:

#501466: Make tabs accessible to users without access to default tab

And overall only marginally related:

#116939: Add a Cancel link on forms

Additionally, almost duplicate issue, but which arrived at a conclusion before doing any investigation:

#402760: Regression: Turn "delete tabs" back into buttons

Wait, why are we rehashing this discussion? We discussed this at length in Drupal 7, and decided to go for buttons - since tabs are to be used for navigational purposes only, not actions. It is even represented in our guidelines (see the last recommendation) at http://drupal.org/node/1090012. This is simply breaking the established pattern, if you wish to have them as tabs open a feature request.

This should be major, as it breaks an existing interface pattern - and we know from the past the significance of this issue.

based on #7 we need to
open an issue for comments to have a delete button and to remove the delete tab.
open an issue for taxonomy terms to remove the delete tab (it already has a delete button)
...
wait that is what the patch (from 2011) is doing in one patch in #402760-5: Regression: Turn "delete tabs" back into buttons.
Marking this a duplicate of 402760

The logical / technical problems in #5 still stand.

I additionally have problems following the logic in #7 — if "tabs are for navigational purposes only", then why is "Edit" a tab?

Delete is an action. And Edit is an action, too.

That's not meant to say that Delete should be tab, but we do have some problems with either solution here. It doesn't help to ignore the problems.

I agree those technical problems would have to be solved as part of either issue removing the delete tab. (So #402760: Regression: Turn "delete tabs" back into buttons should do that if it moves forward.)

Edit is tricky. And I think we should have a separate issue for dealing with that.

There's modal form related issue #1842036: [META] Convert all confirm forms to use modal dialog

Raising criticality as it introduces a major inconsistency, we have already seen in testing to be quite confusing (Baltimore 2009). @sun I dont think we have over the past years ever ignored the problem this introduces, but we need to figure out a good solution to those edge cases - we shouldn't introduce a major usability issue to solve it.

Further to #7 and #9, I believe delete should also be a tab, as it takes you to a delete confirmation page, it's not deleting directly.

There was a issue to convert delete confirmations to modal forms so having a tab is nonsense in the logic

I read the other comments in this issue and now think that edit and delete should be node links.

I was just looking at a use-case on my website and will explain my reasoning, which is based on wiki section. I've setup some view pages as menu tab items, so if i visit /wiki I will have tabs for say /wiki/latest and /wiki/categories. These are all navigational links, as clicking them will show more content.

Now if I visit a wiki node, I might have tabs for View, Edit, Delete, Revisions, Talk.
- View, Revisions and Talk are all navigational links (as clicking them will show more content).
- Edit and Delete are action links, they are going to do something to the node.
So node Edit and Delete are not really any different to say flag links, subscribe links, etc. It would make sense to have them all together, and it does seem counter-intuitive having them as tabs.

Further to this though, a lot of other modules make tabs on nodes that should be links (as they alter the node in some way). Some that come to mind are Display Suites 'Manage Display' tab and AutoExpire's 'Entend' tab. Some module tabs like 'Devel' make sense though, it only shows information regarding the node.

In a perfect world, it would probably be better to 'rename' menu tabs and links for pages and nodes, to say navigation and actions. When you think of links, you think of links to other pages, so how is that any different to a menu tab (Edit page a prime example)? And menus are even worse, as menu-tabs are not readily editable from the front-end, and then you have main/secondary page menus which are, but they are not the same thing (but both are called menus). I think this does confuse people starting out with drupal, I know it did with me. So you could break into the following things.
Menus - links to different areas/functions the website.
Navigation - links to 'content' somehow related to the current content.
Actions - modify/alter the current content.

Edit is not an action. It takes you to a new page where you can perform an action (saving, publishing, etc).
This issue is about delete, please don't bring edit into it.

I'll have to agree with @tim.plunkett on this one (even if "edit" feels like an action to some). Even if it was deemed to be an action link after all, I'd file a request to make an exception. As for what some people perceive as "actions" that require a whole page to perform various other actions before submitting any intended change, I'm sorry but these are definitely not actions performed directly to the content in a single step.

I guess what I'm saying is that if something fits in a modal without reducing the UX, then put it in a modal. In the case of the "delete" action, it's not simply a matter of not wasting a page load. It improves UX in various other ways too.

Moreover, as I mentioned before, the "delete" action is a subset of the edit action and it feels right to be someplace alongside "save". It is an action being performed on the content itself. On the other hand the "revisions" page that was mentioned as an example, feels more like a page to manage not the content itself, but things related to it (its revisions). The word "manage" is implied there and if it weren't for the sake of saving horizontal space, I think we'd have it be "manage revisions". I'm sure you'll all agree that you cannot do serious management in a modal (think confirmation modal here - not overlay).

Lastly, to those concerned about the destructive nature of the "delete" action, please consider this: is it not destructive to save changes to a piece of content that is not configured to have revisions? Well, that is another case that we need to handle with a modal confirmation IMO, but this matter is entirely OT here, so I won't go further there (I'm almost certain I was following a related issue, but the closest match I could find is #482312: Proposal: unpublish rather than delete content - perhaps it was an article I read someplace and my memory tricks me to remember it as an issue)

...#1960928: Provide an opt-out modal confirmation when saving changes to content that is not configured to hold revisions.

Operations are links, that should point to pages and not execute actions directly (which is what also happens when you enable or disable a view at the moment). Entity forms have fancy delete buttons that delete entities the moment you click on them. This is a slightly different, but closely related problem. If we continue using confirmation forms, then we should link to those forms using hyperlinks and not buttons.

Edit is not an action. It takes you to a new page where you can perform an action (saving, publishing, etc).
This issue is about delete, please don't bring edit into it.

A "delete" button that first takes you to another page before asking for confirmation to delete the entity is not an action either, and should therefore not be a button, but a link.

The Sabbath was made for man, not man for the Sabbath.

We present primary form operations as buttons, and should do so even if a confirmation is required. Presenting users with links-versus-buttons based on our implementation details forces users to contend with frustrating inconsistencies for no good reason. As long as there are no security or stability implications, reasonable user expectations of consistency and clarity should not be overruled by letter-of-the-law parsing of the HTTP spec.

*MIC DROP*

Yeah, I agree. There was some study that showed that having buttons as links had the effect to reduce importance of the button. So, it is quite common to present buttons with destructive actions (such as the "delete" button) as links. I was never a big fan of that though. I too favor consistency and would rather have all primary actions as buttons.

If we need to prevent accidental deletions, we should use confirmation steps and the best way to do that in order to avoid extra page loads ans loss of context is using modals where possible. If we need to prevent the action before it even happens, we should change it's color to a red(ish) one. If people hate having multiple colors in the primary action buttons (we currently use blue for submit and gray for the rest), then the red color can only be applied on hover. Besides, applying a "danger" class to these buttons gives themers the freedom to style them as they please (even to look like links).

An interesting side-effect of using buttons that do not actually do anything with the submitted form data (such as delete buttons, whether they redirect to a confirmation page or not), is that the HTML5 validation is still performed, which prevents the delete button from being clicked.

As long as there are no security or stability implications, reasonable user expectations of consistency and clarity should not be overruled by letter-of-the-law parsing of the HTTP spec.

The problem is that using links for destructive actions do have both security and stability implications. First, GET requests come with certain preconditions that are assumed by specification and by implementations. That is that they can be repeated without causing problems (since they are read-only), that they are idempodent (they can't cause side-effects). Additionally, some clients (namely HTTP 1.0 clients) may not properly obey cache headers or behave predictably (the headers are basically heuristics).

Additionally, by using a link, you're exposing the token to log files when transmitted over HTTP, and copy/paste in all cases. Now, since it's just a CSRF token, it's not a HUGE deal (it's useless without the session identifier). However, considering that both drupal_salt and drupal_private_key are 100% static for all time, there is room for brute forcing them (if I know my session identifier, I can brute force both other values for a valid token for me, and then having both static tokens, I can now brute force a session id from a given CSRF token). And thereby gain access to any account's session for which I have a token. It's a long shot, but it's still possible.

Now, if the CSRF system was switched to use a nonce based token (number used once), then this attack would not be possible. Additionally, if the token was only ever transmitted outside of the URL, it would not be possible either (as there's no practical way to get ahold of the token).

Finally, to the point of following "letter-of-the-law" of a spec, that's why it's a specification. You *should* be following it by the letter. If you don't, it stops being useful. By having everyone follow the letter of the specification, rather than an interpretation or what you feel like, we all win. The biggest nightmares we've faced were caused by willful ignoring of defined standards because of whatever reason. Either stick to the standard, or don't use it. To do anything different is irresponsible...

I have to disagree with Eaton as well. Following the letter of the HTTP spec *is* important. "Eh, I'm going to use green lights to mean stop, because that fits better with the color scheme on this street" is intrinsically dangerous. So is abusing the spec on which the Web is built. That *is* "consistency of expectation"; if you expect that a GET request will change data then... frankly you're wrong. :-) Your expectation should be, is documented to be, and is for any non-buggy software, that GET is idempotent. (Except in HTCPCP, where it's documented to not be in the spec.)

Really, what we should be doing for non-idempotent action-y links is having them all by default point to a confirmation form, with no extra parameters. Then in Javascript we grab that link and override its click event. On click, we instead send a POST request to the appropriate page (we can do mime type switching here, like we do for ajax, if we want, or something else), including a token saved in, say, the settings array. That POST is correct, because it's supposed to be changing data.

The problem is that using links for destructive actions do have both security and stability implications.

I think you're misreading my intent -- we should use form buttons for all form actions, even if an interstitial action is required. The interstitial popup should offer button-based confirmation and cancellation buttons.

Really, what we should be doing for non-idempotent action-y links is having them all by default point to a confirmation form, with no extra parameters.

I agree. I'm arguing for consistency in this approach -- up to and including the unecessary use of POST buttons, not the use of GET links for destructive operations.

To clarify: I disagree with Eaton about HTTP compliance: We should absolutely be strictly compliant with the HTTP spec, because not doing so always has "security or stability implications".

From a UI perspective, "buttons for actions, links for safe operations" (as I think Eaton is saying) makes sense. If there are exceptions (not here) where a link should actually do something, then the non-spec-breaking approach I describe in #25 is preferable.

I think we're definitely not hearing each other. ;-)

"Buttons for actions, links for safe operations" is a purist's reading of the HTTP spec, and leads to the ugly scenario we currently have: on confirmation dialogs, "Delete" is a button but "Cancel" is a link. This is in keeping with the idea of strict spec compliance. This is dumb, for the reasons outlined above.

Instead, we should treat cancellation as an action and use a form button for it, even though it is not a data-changing operation. This violates the letter of the spec, but not in the way that ircmaxell thought. The result is more consistency in the UX, less complexity for theming these special case confirmation dialogs and forms, and no loss of security or stability.

If we want UI consistency, can't we simply make links look like buttons? We already style the shit out of all sorts of other UI elements, so we should be able to do this as well.

Using buttons for a simple redirect also puts a burden on developers and hurts server performance, as every button needs a form submit handler that performs the redirect. This requires extra code and an extra redirect, making the site slower as well.

There's no spec requirement that POST be non-idempotent. A button that submits via POST and then responds with a 302 redirect to the URL that would have been in the cancel link is spec-legal.

'course, whether it's actually a button or just a link styled to look like a button, meh, I don't care. :-)

There's no spec requirement that POST be non-idempotent. A button that submits via POST and then responds with a 302 redirect to the URL that would have been in the cancel link is spec-legal.

'course, whether it's actually a button or just a link styled to look like a button, meh, I don't care. :-)

The "just style the link and the button to look identical" approach doesn't acknowledge the fact that buttons and links are handled differently by screen readers, have differing levels of stylistic consistency across browsers, and impose a frustrating double-the-work requirement on designers overriding the elements in CSS. If we're going to change anything, I think consistency, and a reliance on POST for action-buttons (including confirmation or cancelation buttons in confirm popups) is the best long-term solution.

@eaton: that's because buttons and links ARE different. When I click a link, I know I'll end up somewhere else. When I click a button, I know magic and unicorns are going to happen. This allows users to anticipate what's going to happen. People expect a "Delete" button to delete something, and not to redirect them to a confirmation page. It's like making the "Save" button redirect the user to a page that asks "Are you sure you want to save this new piece of content?"

You raise the issue of duplicate CSS, which is valid. On the other hand, however, using buttons to simply redirect users has a similar consequence on the backend: form submit handlers that perform redirects, and increased server load + page loading time. Neither is preferable, but IMHO the reason why we'd need duplicate CSS is much more valid than the reason why we'd need redirect form submitters and increased loading times.

A related issue: #1965910: Remove enable/disable entity operations.

@eaton: that's because buttons and links ARE different. When I click a link, I know I'll end up somewhere else. When I click a button, I know magic and unicorns are going to happen. This allows users to anticipate what's going to happen.

Subtle correction: this allows HTTP/HTML-aware developers to anticipate the implementation details of what's about to happen.

People expect a "Delete" button to delete something, and not to redirect them to a confirmation page.

Citation needed.

form submit handlers that perform redirects, and increased server load + page loading time.

In all seriousness, are "cancel links in confirmation dialogs for destructive operations" part of the highly-cacheable critical performance path for any site? If a user is seeing a hard-coded confirmation dialog, they're already performing operations that are likely to bust caches, something far more performance-intensive than a single submit-handler-with-redirect.

Toolbar and Overlay already do much more evil things to our HTTP traffic than sending a 302 from a form submit handler.

I'm not sure exactly what I've stumbled into here, but wanted to leave a note that #1967112: HTML 5 validation breaks the cancel button in Views UI dialogs makes a technical argument on why we might need Delete/Cancel and its ilk to be links, rather than buttons. HTML5--;

Also note, that if you have a button using input[type=submit] in a form, it means that the browser still requires all HTML5 fields to pass validation. See http://jsfiddle.net/GKxNR/ and #1967112: HTML 5 validation breaks the cancel button in Views UI dialogs.

Is there no HTML5 equivalent of FAPI's #limit_validation_errors? Because that's what we need here.

Totally agree with eaton.

Canceling is not a link, it's an action. As a user, all I know is I want to cancel the action, it's none of my business what the site needs to do to accomplish that task. It's probably just a 302, but maybe it needs to clean up some bit of state?

This really has nothing to do with the HTTP spec or performance, especially.

Let's not focus on the semantics of the word "action" too much. What this really is about is dark magic that has consequences versus dark magic that has no consequences*.

1) We have quite a decent list of arguments in favor of following the HTTP spec and NOT using buttons for redirects/indirect actions. These are based on facts and concrete real world problems, such as HTML5 validation, possible CSRF exploits, and more, which is all perfectly explained in #24 by @ircmaxell.
2) I would really like to see if there are arguments that are in favor of UI consistency and using buttons for redirects. I understand what @eaton and @msonnabaum are saying and the idea of UI consistency appeals to me. However, I haven't seen any factual evidence in favor of this approach, except the obvious argument that one-click actions are user-friendly, but I think we can probably make that happen without links fairly easily.

*) I do not know the technical term, so if anyone can bring my stab at writing fantasy fiction back to reality, please do so.

1) We have quite a decent list of arguments in favor of following the HTTP spec and NOT using buttons for redirects/indirect actions.

I would love to see where in the HTTP spec it talks about buttons.

However, this is in the spec, regarding redirecting from a POST:

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource.

...possible CSRF exploits, and more, which is all perfectly explained in #24 by @ircmaxell.

Pretty sure the security concerns were about using links for destructive operations, which no one is arguing for.

Just to clear up some facts:

1. D8 allows to make links look like buttons for a long time already. The .button class is sufficient. cf. #1845728: Refactor and introduce generic button CSS styles for forms and links
2. The claimed semantic difference for screen-readers is not true. That's what <a role="button"> is for. cf. http://www.w3.org/TR/wai-aria/roles#button
3. There's a third incarnation of <button role="link">. HTML5 user agent validation unclear. cf. #1719640: Use 'button' element instead of empty links

If we remove the Delete tabs, then the Delete buttons should simply be links. To be precise:

<a role="button" class="button button-danger">Delete</a>

The Delete "button" on the Edit form is and always has been a simple HTTP redirect. CSRF protection still happens on the delete confirmation form.

Please note that contributed modules are integrating with delete confirmation forms, in order to perform additional actions upon deletion. The maximum we can do is to load the confirmation form in a modal dialog, but instant/one-click deletion via Ajax is not possible, as it would break an important integration point for contrib.

With regard to UX, an important and often overlooked aspect is that you cannot reach the Delete operation from the page that shows/views an entity. You first have to go to the Edit form, and only from there, you can get to the Delete form.

If you're the content editor and/or moderator of a site, this completely unnecessary multi-page-load interaction can get very annoying over time.

I am staying far away from the overall debate here, but just to clear up a couple more facts:

1. An interesting side-effect of using buttons that do not actually do anything with the submitted form data (such as delete buttons, whether they redirect to a confirmation page or not), is that the HTML5 validation is still performed, which prevents the delete button from being clicked.

   This is simply a bug on the part of whoever defined the form; they should have set #limit_validation_errors to an empty array (as hinted at by @tim.plunkett above). That will fix both the HTML5 validation errors as well as the accompanying server-side validation errors. (This is the situation with #1967112: HTML 5 validation breaks the cancel button in Views UI dialogs too.)

   So, it's unrelated to this issue one way or another.

2. Additionally, by using a link, you're exposing the token to log files when transmitted over HTTP, and copy/paste in all cases. Now, since it's just a CSRF token, it's not a HUGE deal (it's useless without the session identifier). However, considering that both drupal_salt and drupal_private_key are 100% static for all time, there is room for brute forcing them (if I know my session identifier, I can brute force both other values for a valid token for me, and then having both static tokens, I can now brute force a session id from a given CSRF token). And thereby gain access to any account's session for which I have a token. It's a long shot, but it's still possible.

   The hash salt and private key are each 40+ characters in length, and when Drupal constructs a token from them, it is done using a SHA-256 hash algorithm. If you can figure out a way to brute force that, there are a large number of government agencies (as well as criminal organizations) that would pay all the money they had at their disposal to hire you :)

The issue title suggests that it's the multiple *locations* in the ui that make delete operations a problem. This is mostly a question about *where* users can expect to find them. I see discussion mostly about *what/how* they should look like. Details for later, basically off-topic for now.

1. What's the current situation in core? Make a list, collect screenshots (individual items, bulk, …)
2. Any interesting other things that contrib modules do? Make a list, collect screenshots
3. Analyze what we've found, what are the main usage scenarios? (individual items, bulk, in-place?)
4. Select the most promising solution(s) that optimize the main uses without excluding ways to solve edge cases
5. Implement, (argue a bit more about buttons vs. links here if you like)

We're still at step 1.

I can't believe this discussion is still going on 3 years later.

The simple answer is this.

You shouldn't have to 'edit' something in order to 'delete' it. They are two different things and we should definitely have two local tasks - one for each - which themers can style as tabs or buttons however they see fit (end discussion on that point).

The question of the confirmation screen is another issue, and should perhaps be given as an option (function on or off) from an appropriate place in site config. Site admins can then decide if the additional confirmation page is required.. or not.

But let gets the delete local task in core asap please....

Closely related #2085907: Ensure all configuration entities have an Edit/Configure tab by default

Sometimes they are linked :) It looks pretty good in most places. There doesn't seem to be a delete link in image styles however, on neither the style or the effect - I know quicksketch kinda hacked this part though.

Image styles don't use the entity form controller,

They absolutely do.

class ImageStyleEditForm extends ImageStyleFormBase
abstract class ImageStyleFormBase extends EntityFormController

When I did that port, I kept the UI the same, which had no delete link. I have no idea why there was delete link, and I think we can just remove that hunk outright (EntityFormController::actionsElement() will ensure it is not added to the add form).

updating for resolution.

issue summary needs updating to summarize the concerns and how they are addressed. also needs current approach.

#55: delete-tabs-config-entities-55.patch queued for re-testing.

So I checked a few places:

- Contact types
- Menu (noticed the "delete confirmation page" has a +Add link, lol)
- Image styles

They all seemed fine so RTBC from a visual standpoint.

While manual testing I realized that actions don't have neither a delete link right on the action nor as local task.
Additional comments seemed not to be touched by the patch, but are mentioned in the issue summary. From the code perspective this is perfectly fine.

Sure, just updated the issue summary for that config entity point.

Yay, this is a good UX improvement. rtbc++

update

quick correction after talking to dawehner in irc, imagine config

summarize discussion. place holders for ui changes, added related issues. reorganize.

new images from current core and patch from #55 for issue summary.

correct html and make it clear html section needs updating

added images from current core and patch in 55

Just realized that taxonomy terms are content. Also, http://hojtsy.hu/blog/2013-sep-13/drupal-8-multilingual-tidbits-14-intro... has a image which shows a summary of what is content and what is config.

---------

double checked the delete operation for image styles. looks ok.
operations button same before and after.

delete before

delete after

moving taxonomy into content (it is not a config entity)

Committed 1f9a488 and pushed to 8.x. Thanks!

I guess we need a change record for site builders

I'll do the change record.

I followed the instructions at https://drupal.org/change-records

draft: https://drupal.org/node/2091137

please review.

What about add a listing of all the removed local tasks at the end.

https://drupal.org/node/2091137/revisions/view/2843841/2843971

(oh, messed up tags earlier. fixing.)

Made some minor fixes - makes sense to me though :)
https://drupal.org/node/2091137/revisions/view/2845103/2848997

#55: delete-tabs-config-entities-55.patch queued for re-testing.

Patch in #55 does not apply to latest clone of drupal 8.x

There's no patch for content entities!
I think better to make this in before #2102125: Big Local Task Conversion to minimize the patch size

added that code review done and ui review done

I think better to make this in before #2102125: Big Local Task Conversion to minimize the patch size

Well, nothing happens on this issue, so I don't see a reason to wait on that. It is so much not worth!

to help clarify where the second part, content starts.

There was a commit in #65. Anything else should be a follow-up.