Problem/Motivation

Following #2084463: Convert contextual links to a plugin system similar to local tasks/actions, contextual links cannot be attached to path parents anymore. They are collected based on group names which come from build array keys. So to attach contextual links to existing groups, you need to know this group name. However group names are somewhat arbitrary, eg. blocks have 'block', menu have 'menu', but views have 'views_ui_edit'.

Proposed resolution

Figure out how to make the names predictable to allow for automation in extending links. At least make the config entity based links use the module name.

Remaining tasks

  • Figure out what to do.
  • Build it.
  • Get it reviewed.
  • Test.
  • Commit.

User interface changes

None.

API changes

Maybe. At least some existing group names will change.

#2084463: Convert contextual links to a plugin system similar to local tasks/actions

Files: 
CommentFileSizeAuthor
#13 2134841_13.patch1.43 KBsushilkr
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,992 pass(es). View
#1 contextual-link-entity-type-based.patch5.76 KBGábor Hojtsy
PASSED: [[SimpleTest]]: [MySQL] 59,547 pass(es). View

Comments

Gábor Hojtsy’s picture

Status: Active » Needs review
Issue tags: +VDC
FileSize
5.76 KB
PASSED: [[SimpleTest]]: [MySQL] 59,547 pass(es). View

Looking at the original conversion patch, looks like only views_ui and menu_test modules have a mismatch. Here is a patch for views_ui, not sure how best to fix menu_test.

dawehner’s picture

The current changes look fine.

Sadly this does not solve the usecase of views itself, which had path based contextual links before.

Gábor Hojtsy’s picture

Well, its also not a full solution for config translation but at least would make some code less strange :D I'm open to a more general solution as well, but don't really know how that would look like.

Wim Leers’s picture

Shouldn't this be critical?

Gábor Hojtsy’s picture

So far I think only config translation and views are affected, so not sure... Views has a larger problem that it is not possible to add contextual links (which were possible from the views UI before), because you don't really know if there is a group matching and if none, you get route resolve errors :/

Wim Leers’s picture

But isn't this a critical regression?

Gábor Hojtsy’s picture

Yeah it depends on whether you consider this part of the API critical :D There have been old APIs replaced with entirely new ones where direct 1-1 mapping of features are not present and then it comes down to consideration of what is important.

pwolanin’s picture

Since the contextual links relate to the UI, it seems like the group should be "views_ui" not "view"?

e.g. if I made some other UI module (simpleviews) to edit views it shoudl have a clearly distinct group?

Gábor Hojtsy’s picture

@pwolanin: right, well. The underlying problem is that the only way to figure out which groups are available is to inspect build arrays, which are totally not predictable. We have no idea what generates the render array for *something*. If you don't want to care about existing groups, but want to add a new one, again you need to modify that render array to add a new group. You cannot just add new routes for existing groups even unless all your route placeholders are filled in in the group.

So its multiple levels less predictable / harder to extend vs. the old path based solution :/

The entity name matching would bring some flexibility, eg. the content entities also define it that way.

As for simpleviews, it would provide a UI where the same placeholders are needed (we can assume?!) so it could put links into the same group and possibly remove other links if it wants in alter.

dawehner’s picture

We could also move the contextual link groups to the entity information, so if needed someone could request them from there.
This does cover all the usecases of config translation, though not all of views.

Gábor Hojtsy’s picture

Sounds like views needs a path based system anyway where we don't need to know what build arrays have what groups. How can we make that work in the new system? :)

jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
sushilkr’s picture

Status: Needs work » Needs review
Issue tags: +SprintWeekend2013
FileSize
1.43 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 83,992 pass(es). View

Rerolled

jlbellido’s picture

Issue tags: -Needs reroll

Removed tags

alimac’s picture

We should all try and use the same sprint tag. According to https://groups.drupal.org/node/447258 it should be SprintWeekend2015 with no #.

pwolanin’s picture

Status: Needs review » Needs work

So the conclusion is that the normal/default group name should be the entity type (lower case) or the plugin ID for the entity type?

Looks like the last patch is missing most of the changes from Gabor.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.