Regression: Turn "delete tabs" back into buttons

Subscribing.

We add random other buttons to forms (Preview, Save and add another, Preview diff, Reset to defaults) - which can make the delete button inconsistently placed, and core can't at all control a sensible pattern - since contrib modules have to use hook_form_alter() to add to those buttons and don't know each other's weights out of hundreds of combinations.

Having delete as a tab gives us a pattern that's far more easy to survive when contrib modules are added - less contribs add local tasks to these pages, and hitting the wrong tab is less permanent than hitting the wrong button.

Sites that don't want a tab for whatever reason can also easily make this a callback with hook_menu_alter() and either add it back to the form, or use the wordpress-style link if they want. Arguably that'd be less work than doing it the other way 'round.

So big +1 from me.

Still a valid issue. Moving to 8.x.

Huge, huge +1 to standardize on *not* having different operation buttons on our edit forms. It should be a local task. I'd like to help fix this for D8.

Initial patch, likely to fail any tests that clicked the delete button on the forms.

Its great to see an initiative to streamline this experience more, its quite confusing currently that there is multiple places where one can find the delete button. Sometimes on the object, other times in the listing. I have actually been giving this quite some thought, as I was starting to write out the "buttons" pattern I noticed the many inconsistencies.

Lets first take a look at our standards http://drupal.org/node/1090012 .In #542658: Move action "tabs" out of local tasks we introduced the change of splitting local actions from listing pages. This to make clear that tabs are for navigation, and other patterns are used for actions - from the usability testing done so far - this distinction works, and people are able to easily find the "add" actions. Although we have not tested "Delete" actions, users did quite often make the step of deleting content with little to no problems.

I do not believe that the right step is to bring delete to a local tab. It is the mistake we made in the past, which caused local tabs to be diluted with a mix of navigation and actions (currently Edit, is the only one we allow there). But more importantly, the local navigation is very prominent and "Delete" should not be prominent. If you are worried about hitting delete next to save, it will be even more of a problem at Edit and Delete.

If we look at other systems, few to none of them have a local tab for Delete. So introducing this here, would very much be a Drupalsim. I propose rather than moving it, we make it more consistent - each object should have a delete button on its edit form and in the listing. We should design forms with two buttons to have more consistency #1238484: Ability to mark the form buttons to be of a specific type (so that they can be styled differently) and possibly add a :hover style for delete buttons so its easy to spot a mistake.

When it comes to the edge case described in #196758: Having delete as a button on the node edit form means certain users don't have access to it when they should, to me just means that listings should always have delete buttons.

I think this should be postponed on #1834002: Configuration delete operations are all over the place

Well, #1834002: Configuration delete operations are all over the place might be a duplicate of this one since this patch moves all delete operations to local tasks instead of buttons on forms, pretty much unifying the whole thing.

Unlike #1834002: Configuration delete operations are all over the place, this issue here jumped straight to a conclusion without prior investigation. @Bojhan seems to strongly disagree with the proposed solution, and I can perfectly understand why (because I'm also skeptical whether it is appropriate to make a destructive operation this dominant).

I think a solid plan and solution needs a proper investigation to be grounded on well-informed decisions. Also, "what are others doing" is a major aspect to this in my book. Especially, since this affects not only site owners/administrators, but also all "end-end-users" of all Drupal sites (i.e., those users and site visitors who don't even know what Drupal is).

I think the investigation was done and the result is http://drupal.org/node/1090012
which says delete should not be a tab.

I closed #1834002: Configuration delete operations are all over the place as a duplicate of this.

Next step: reverse what was started in the patch in #5, and instead:
remove the delete tabs and add delete buttons.

since @Dave Reid 's last patch was a while ago, I think it's ok for someone else to take a stab at this. (sorry Dave, reassign it if you would still like it.)

I think delete is a separate operation so it needs a own router and callback. Also having delete as button on Edit page means that user needs Edit and Delete access to perform Delete!

I am fixing the title. Introducing modals, is not necessarily part of this - its an optional addition.

this does not do much. it just removes the tab on the taxonomy view.
I could not figure out how to add a delete button on the comment edit.

#14: drupal-unify_delete-402760-14.patch queued for re-testing.

I mostly agree with andypost in #12. It should be possible to allow users to delete stuff without editing it, and there's a long-standing issue trying to address that (by moving delete operations to tabs).

I don't see any justification for changing this except that there's some inconsistency at the moment.

Why can't it be a contextual link? Probably because tabs is the sole constant in our UI, which is a bit weird.

Anyways, I dont think we can introduce a major UX regression to solve a small problem - that should be dealt with separately.

For the "need edit permission in order to delete" issue, how about instead of blocking access to the edit page (that holds the "delete" button) altogether we instead allow people to access it (as in being able to view it) but have all widgets locked and no "Save" button? So, I guess what I'm trying to suggest is that the "Edit" permission does not effect the visibility/access of the edit page itself, but rather the elements contained in that page/tab.

As for the concerns about the "Delete" action being a button means that a destructive action could be performed by accident, how about we use modal confirmation dialogs now that they're in?

Going this way would solve both the "delete should be a button - not a navigation tab" and the "need edit permission in order to delete" issues.

Bottom line is:

- "Delete" is an action and having it be a navigational element simply feels weird - it should be a button.
- Deleting is a subset of the editing action and residing in the "edit" form feels right. It is also a common UI practice (deleting a contact in iphones for example requires you to go to the contact screen and hit "edit")

PS: ...I don't mind bringing edit/delete contextual links in the game - as long as this is in addition to the "Delete" button in the form.

There' was a issue about converting Delete confirmations to use modal somewhere in #1842036: [META] Convert all confirm forms to use modal dialog
Also there's issue to draw a bottom line for Delete buttons #1834002: Configuration delete operations are all over the place

I disagree with removing delete as tabs. This puts the requirements on contextual links. Why can't delete be both a tab and a contextual link? It's possible to do both.

Please see #6

is this still applicable to 8.0.x?

Came across this issue while working on something else, closing as outdated, because:

1. It hasn't had any activity in almost a decade (patches are also outdated).
2. The discussion appears to have moved to other places/issues.
3. The "Delete" local task has existed across core content entities for a long time now and there does not appear to be an appetite to change this.
4. There seems to be more support for keeping the local task (I also agree), partly due to the fact that a user can have access to delete but not edit, so not having a local task would not be good UX for those users.

As an additional note, in this context "Delete" is not actually the action, the actual action of deleting something happens when you press the "Confirm" button on the confirm form, "Delete" just takes you to a form, in the same way "Edit" takes you to a form, and the action of confirming your changes happens when you click the "Save" button.

Feel free to re-open if anyone disagrees.