Decide what to do about important contextual links when that module is disabled or restricted

Reposting slightly edited from #1874664: Introduce toolbar level "Edit" mode that shows all contextual links with additional notes below.

Reality is that Drupal displays these local tasks only for some high level objects and only if you view them on their own page. If you view a node in a Views view, in a block or as part of a Panels pane or a teaser in some other way, then you have no editing local task on the node. Also, if the high level object on the page (the main page object) is not a node or user, you pretty much don't get editing or other local tasks (eg. if your page is a view or panel). Also if you have anything displayed not as the main content object of your page (block, menu, etc.), you have no way to directly edit that either.

So the answer to "how do I edit this block", "how do I edit this view" or "how do I edit this node if its displayed with views (and the creator did not check to link title to the node page)" if you have no contextual links is the same: go to the admin page and try to find the object somehow to edit.

The proposed solution here makes it so regardless of where the node is displayed, whether it is a teaser or full node, and even whether it is a node page or view page or block or menu or panel or whatnot, you have the same way to do operations on it. You don't need to think "ah, this is a node, so I should go to it's page and edit it there" but "oh, this is a block so I'll need to manually find this in the admin UI". Instead of two competing affordances for operations on underlying page elements, people only need to learn one and can get to operations *faster* because these are even available on teaser views, etc.

The fact that full node pages (and user pages) have edit tabs on them is a legacy behaviour. Views, panels, blocks, menus, etc. don't have these, and blocks and menus don't even have a frontend "object page" where they are the main object for them to have an edit local task. If your site is built with panels with panes, or spaces+context with blocks, then you don't have "object pages" for your page components to go and hit the edit tab. This privilege for nodes and users and only if they are displayed on their own page is very one-off on the front-end where most things have no way to edit without contextual links.

I think it is a crucial question to pose whether it is worth it to maintain two separate experiences. One where you can edit some things via local tasks only if you view their full page display on their own page and one where contextual links not interfering with the site design appear for all kinds of objects granularly based on your permission levels for them in one unified fashion everywhere.

Local tasks are very-very limited and if Drupal wants to go beyond Wordpress' simplicity and provide real flexibility, we should not tie us to them IMHO.

Note that comments currently have edit/delete links displayed inline, in all contexts, but not using contextual links.

So while it's an inconsistent experience, you get the tab on nodes and the links on comments without that module enabled, but now only for comments. That makes going to admin/content more of an obvious regression from Drupal 7 for me, than if you had to do it for both.

We don't have contextual links on comments because the original Drupal 7 patch to add contextual links to comments led to a menu_get_item() call for every comment on a page (i.e. a separate query to the router table for each comment), unfortunately that bug has never been fixed and the patch was rolled back instead. I've re-opened the original bug report it now the contextual links usage has broadened beyond admins, at #607244: Decrease performance impact of contextual links.

Here is a patch to move towards unified use of contextual links instead of tabs on front end objects. This is not a competing patch for the above, in fact the two can possibly be merged if we want these to re-appear as tabs when contextual module is not on. But as said above, people loose a whole lot more without contextual links.

The following changes were needed:

NODES
- make translation tabs inline actions (both legacy translation module and entity translation module)
- make book outline inline action
- document title suffix containing contextual links

USERS:
- make editing, shortcuts, contact, openid and tracker inline actions (NOW this is going to be controversial and definitely need extensive discussion, not all of these are administrative actions; users edit their own accounts regularly and others contact users or track their posts)
- introduce render controller for users to add contextual links when not in compact mode (eg. when rendering user picture on nodes)
- add title suffix (where contextual links get rendered) and fix bug around attributes that was pre-existing, so the links show up

TERMS:
- make all taxonomy term local tabs into inline actions
- add contextual links to render controller
- add title suffix to template (same as above)

This results in:

Now for the weaknesses. Obviously many of the user actions are navigational. Eg. contacting a user or looking at what the user posted are not really actions on the user and not backend operations either that would need to be hidden away like this. Also a user herself to be able to edit her account requiring an admin action is very odd. So I think the application of this to users is weak.

Then for taxonomy terms, there is a rendering artefact. Although the above screenshot shows I see the taxonomy term contextual links, reality is if there is no description for the term, there is no space to display the pencil (the main taxonomy term area is 0px high), so they will just not be visible. I think things like this are artefacts that we should be able to resolve by for example figuring out how to move up the main objects' contextual links to the page title instead of the content below the title. That clearly needs more work.

As for comments on entities as @catch mentions, they also need the "reply" link at least to be well discoverable I guess, and then moving the rest to a contextual area would group the admin tasks into the contextual operations while reply would be kept as a frontend feature.

Made an attempt at moving the admin comment links (edit/delete/approve/translate) as summarised by @sun at #607244: Decrease performance impact of contextual links to contextual links too. The comment module is a pretty big hodgepodge of stuff, so this is not very trivial. The patch goes as far as doing this for "delete", and the above patch already does translate, but edit and approve are much trickier.

Edit: all comment menu paths use comment/% (not loading comment directly) but edit uses comment/%comment directly. It has a comment saying this is for performance, but I don't really understand why. Entity loading is cached as far as I understand. Not sure why most comment paths NOT load the full comment entity up front.

Approve: this has one more issue, namely the approve operation should only show up if the comment is not published yet which could be coded into menu item access (so long as contextual links are based off menu items); it also gets a form token to avoid XSS since it directly approves comments instead of with a confirmation form; there is no current way to add such one-off addendums to contextual links

There is also a bug with how contextual links are engaged, eg. when you open down a comment's contextual links the parent node's contextual links also open.

Of course this also has all the performance implications outlined by @catch at #607244: Decrease performance impact of contextual links.

BTW I realize the issue is about what to do if most of these changes are made, but since most of these changes are not made yet, I thought it would be paramount to come up with the extent of the changes first. Maybe I should have opened yet another issue around this actually.

I don't really agree with moving everything into contextual links for the issue brought up in #4. Local tasks are commonly used in the wild as navigation elements, and not administrative tasks. Views UI allows us to create arbitrary views at local tasks and they are commonly used as 'tabs' on nodes for more information, profile pages under users, etc. Replacing this pattern with contextual links seems contrary to the intent of contextual links.

Please see this comment at the parent issue: #1882482-104: [meta] Unify editing approaches in Drupal.

Trying to build consensus. I think we're actually closer than I remembered :)

In that issue, we removed "Edit" as a primary tab (MENU_CONTEXT_PAGE) from node pages, and instead made it a contextual link

We probably should have rolled that back. Or at least added back the local tasks.

We did roll that part of the patch back, didn't we? I see "View" and "Edit" tabs on my D8 install on node/1.

That probably makes this issue mostly irrelevant now. And probably not "major."

Updated issue summary.