Add a dropbutton field handler to Views

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/Links.phpundefined
@@ -0,0 +1,91 @@
+ * A abstract handler which provides a collection of links.

An abstract, but should we be calling this abstract when it's not abstract, or make this abstract? I guess the second one :)

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/Links.phpundefined
@@ -0,0 +1,91 @@
+    // Only show fields that follow this one.

I think this is meant to be 'Only show fields that precede this one'.

It would also be good good to filter by only fields that can actually render links. This is potentially a good follow up issue, as there currently isn't a nice way to achieve this.

I was just manually testing this patch for #1851086: Replace admin/people with a View and it works great!

+++ b/core/modules/system/system.views.incundefined
@@ -0,0 +1,21 @@
+function system_views_data_alter(&$data) {

Why is this an alter and not just a regular info hook?

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/Links.phpundefined
@@ -0,0 +1,91 @@
+    $field_options = array_slice($all_fields, 0, array_search($this->options['id'], array_keys($all_fields)));

Don't we do this for tokens as well? We could probably have a helper (follow-up, of course)

+++ b/core/modules/views/lib/Drupal/views/Tests/System/FieldDropButtonTest.phpundefined
@@ -0,0 +1,46 @@
+      $this->assertEqual(count($result), 1);
...
+      $this->assertEqual(count($result), 1);

We should probably add assertion messages

+++ b/core/modules/views/lib/Drupal/views/Tests/System/FieldDropButtonTest.phpundefined
@@ -0,0 +1,46 @@
+      $result = $this->xpath('//ul[contains(@class, dropbutton)]/li/a[contains(@href, :path) and text()=:title]', array(':path' => '/node/' . $node->id(), ':title' => 'Custom Text'));

I think the "Custom Text" should technically be wrapped in t().

I think we might want to move this back to hook_views_data_alter() as we are adding this to the views "table"?

The tokens array was being polluted, so we were getting the values returned from getPreviousFieldLabels() twice. Like :

array (
  'age' => 'Age',
  'id' => 'ID',
  'name' => 'Name',
  'Fields' => 
  array (
    '[age]' => 'Age',
    '[id]' => 'ID',
    '[name]' => 'Name',
  ),
)

#11: 1826604-11.patch queued for re-testing.

I think this is good to go.
I've manually tested it, and the code changes look great, especially that new helper method.

This is blocking any efforts to port admin listings to Views.

Though, this needs to be updated for the $testViews approach and #1855228: Move Views core module tests to their respective modules

Postponed on #1855228: Move Views core module tests to their respective modules
Rerolled for the $testViews

This is major because it blocks every single admin view conversion.

Updated for the recent commits, should be back to RTBC if green.

Yep, looks good to me too.

OK so the code in general looks fine, but system module shouldn't know anything about views. Ideally system module shouldn't know about anything at all because it's been shot in the brain.

Yep, understood. We can move this back to views.

Oh well that's easier.

If there's something in /includes or core/lib that needs views integration, then that integration should probably go into a new or existing module that's neither system nor views. Same as we just re-added entity module to avoid stuffing things into system.

Eventually /includes shouldn't exist at all - we'll one-day migrate all of that to core/lib or core/modules (although it might take another release or so).

This looks like a generic handler and not related to any particular core subystem so I'm not sure it's a problem here though? Committed/pushed to 8.x but happy to discuss this a bit more.

Will this be backported to Drupal 7 or is there a module to provice dropbutton links in views? This would be very very useful!

Self-Answer: See #1608920: Add drop-button field display