[Change notice] Move views_fetch_fields into an autoloadable class

Looks good overall.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/relationship/GroupwiseMax.phpundefined
@@ -11,6 +11,7 @@
+use Drupal\views_ui\ViewFormControllerBase;

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/wizard/WizardPluginBase.phpundefined
@@ -10,6 +10,7 @@
+use Drupal\views_ui\ViewFormControllerBase;

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewsDataTest.phpundefined
@@ -7,6 +7,9 @@
+use Drupal\views_ui\ViewFormControllerBase;

+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/Form/Ajax/AddItem.phpundefined
@@ -9,6 +9,8 @@
+use Drupal\views_ui\ViewFormControllerBase;

+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/Form/Ajax/ConfigItem.phpundefined
@@ -10,6 +10,7 @@
+use Drupal\views_ui\ViewFormControllerBase;

+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/ViewFormControllerBase.phpundefined
@@ -9,6 +9,7 @@
+use Drupal\views\Views;

Why is this added? Looks like PHPStorm might have gotten ahead of itself? :)

+++ b/core/modules/views/lib/Drupal/views/ViewsDataCache.phpundefined
@@ -268,6 +268,155 @@ public function fetchBaseTables() {
     return $tables;
   }
 
+
+
+  /**
+   * Fetch a list of all fields available for a given base type.

Extra blank lines.

+++ b/core/modules/views/lib/Drupal/views/ViewsDataCache.phpundefined
@@ -268,6 +268,155 @@ public function fetchBaseTables() {
+      uasort($strings, array('self', 'fetchedFieldSort'));
...
+      uasort($fields[$base][$type], array('self', 'fetchedFieldSort'));

Should be static, not self. Or I think you can do array($this, 'fetchedFieldSort'), not sure if that's better or worse?

I rerolled anyway, but have a couple of points.

+++ b/core/modules/views/lib/Drupal/views/Tests/ViewsDataTest.phpundefined
@@ -216,7 +218,7 @@ public function testViewsFetchFields() {
+      $fields = Views::viewsData()->fetchFields('views_test_data', $handler_type);

Should we use the Views class here? or just get it form the container? I'm not sure.

+++ b/core/modules/views/lib/Drupal/views/ViewsDataCache.phpundefined
@@ -269,6 +269,153 @@ public function fetchBaseTables() {
+   * Fetch a list of all fields available for a given base type.

Fetches (I know it's just moving it, but might as well!)

+++ b/core/modules/views/lib/Drupal/views/ViewsDataCache.phpundefined
@@ -269,6 +269,153 @@ public function fetchBaseTables() {
+    static $fields = array();

Can't we just store this as a property on the class and do away with this static?

Looks like this is blocking #1832858: Revamp descriptions of items in handler listings

+++ b/core/modules/views/views.services.ymlundefined
@@ -59,6 +59,9 @@ services:
+  views.views_data_helper:
+    class: Drupal\views\ViewsData

I think this class should be called ViewsDataHelper. If we are going the route of having separate classes. Then I would like to change the ViewsDataCache class to ViewsData as I think that is a better fit.

Otherwise, I think the patch looks good!

EDIT: #1989806: Rename ViewsDataCache to ViewsData is related.

So we could make this ViewsDatHelper then both service names will be consistent with their class, win :) (IMO)

Sorry, getting ahead of myself.

Here is a reroll, with comments above.

+++ b/core/modules/views/lib/Drupal/views/ViewsDataHelper.phpundefined
@@ -0,0 +1,186 @@
+    $a_group = drupal_strtolower($a['group']);
+    $b_group = drupal_strtolower($b['group']);
...
+    $a_title = drupal_strtolower($a['title']);
+    $b_title = drupal_strtolower($b['title']);

How about using Unicode::strtolower() :)

How about that :)

I guess if we don't need this to be t() then we might as well.

Hmmm... the $this->fields property is never set or used so in effect you've removed the static caching...

#33: vdc-1962234-33.patch queued for re-testing.

#33: vdc-1962234-33.patch queued for re-testing.

Patch is good, tests look great.

We still have two references to views_fetch_fields in comments...

Confirmed that views_fetch_fields is well and truly gone now.

We've got some new status handlers... due to #1998192: Allow the boolean labels of exposed filters to be configurable

Yes, I added those :) looks good.

Committed b15e921 and pushed to 8.x. Thanks!

For more information as to why this issue was moved to the Drupal core project, please see issue #3030347: Plan to clean process issue queue

Moving back to the contributed Views issue queue and closing as outdated per https://www.drupal.org/project/views/issues/3030347#comment-13023447