Use Config Entity query for views_get_applicable_views()

Going to look at this.

Hmm, not sure we can do this, as most of what this is used for are on display instances. E.g. getting 'uses_hook_menu', which is from the plugin definition.

We could try writing it out to the file and see which is more performant.

Just realized that using efq could be even a performance boost.

Currently it initializes ViewExecutables for all views, but with efq you simply wouldn't have to anymore.

The prob is that currently displays are assumed to be enabled, or 'enabled' could be set to 0 or 1. I'm not sure if we can do an efq query where menu/path IS NOT NULL *and* enabled IS NOT NULL OR <> 0 ?

So we could do something along the lines of this? Then atleast we are filtering down the initial result set.

Oops.

+++ b/core/modules/views/views.moduleundefined
@@ -1107,32 +1107,24 @@ function views_get_enabled_display_extenders() {
 function views_get_applicable_views($type) {
...
+    ->condition('display.*.display_options.path', NULL, 'IS NOT NULL')

I guess we only use this for 'uses_hook_menu' now that blocks are derivatives, so this won't break, but just noting we'll have to axe the $type or do this conditionally

+++ b/core/modules/views/views.moduleundefined
@@ -1107,32 +1107,24 @@ function views_get_enabled_display_extenders() {
+  foreach (entity_get_controller('view')->load($query) as $view) {

foreach (drupal_container()->get('plugin.manager.entity')->getStorageController('view')->load($query) as $view) {

+++ b/core/modules/views/views.moduleundefined
@@ -1107,32 +1107,24 @@ function views_get_enabled_display_extenders() {
-        $result[] = array($executable, $id);
...
+        $result[] = array($executable, $id)

Missing ;

Thanks Tim. Generally it's a good idea if I actually check patches first ;) So we should use the $type param and change it it path for now maybe. Also changed your other points.

So this assumes that if one display has a path, then all displays of that view have a path. Here's an ugly hack for that, but we'll need a better solution.

Here's another option, to preserve the existing behavior and prevent an API change.

Yeah, I guess the only trouble with that is that disabled views would be returned too, unless you always passed in the ids..

What about that?

Let's edit the patch file :)

I like that.

+++ b/core/modules/views/views.moduleundefined
@@ -1107,32 +1114,34 @@ function views_get_enabled_display_extenders() {
+    ->condition('disabled', '0')

Let's just use FALSE here instead. Then we're consitent with the patch in #1901076: Use config query to get enabled and disabled views. too.

New version.

Considering that my patches weren't used, I feel comfortable RTBCing this. (If it comes back green)

That looks like we're all happy with this now. Nice team work.

DOH

Hah, nice catch. I manually tested this time and it works. That interdiff was the only problem.

->condition("display.*.display_plugin", $ids, 'IN'). WIN.

I know catch said he was somewhat concerned about this getting abused everywhere, so I was going to assign it to him, then noticed that he created the issue in the first place. :D

Committed and pushed to 8.x. Thanks!