Error: Call to a member function get_access_callback...

Please take a look at #1771140: view_menu_alter() adding to existing "access arguments" causes user_access() error, I think that's probably the same bug.

Please check the related issue, thanks.

In case anybody else comes across the same issue I just discovered when upgrading to the latest version of views - here is my cause and fix.

The error I was getting in WatchDog was simply:

Call to a member function get_access_callback() on boolean in views_plugin_display_page->execute_hook_menu() (line 96 of C:\xampp\apache\htdocs\drupal-7\sites\all\modules\views\plugins\views_plugin_display_page.inc).

It seems as though I had some old view that had corrupt access data associated with it - such that when the "/admin/reports/fields/permissions" report was viewed - there were no entries for "Field Type" - or "Entity Type". Simply disable or delete this view and the site came back to life - and caches could be cleared without killing the entire site.

I used drush vdis "view name" - to disable the view.

I did have to restore my site from a backup to do this - once the caches were cleared - there was simply an error page an nothing more across the entire site...

I think this error related access plugin.
some my views using access check plugin.

class  XX  extends views_plugin_access {
function get_access_callback() {
    return array('views_check_perm', array($this->options['perm']));
}
..}

there no error if using views 7.21. even after enable my custom views using 7.21, then i can upgrade to views 7.23.
it is related custom views importing when enable module. (maybe override old views ? )

I can confirm that I had the same issue after a simple view save - wiped out the whole site, no drush commands available as it was complaining of needing autoload.php (which the site doesnt need) but when I copied latest views version up the site cam back to life.

EDIT:
I still have the issue after updating to views-7.3.23

clearing cache shows this

Error: Call to a member function get_access_callback() on boolean in views_plugin_display_page->execute_hook_menu() (line 96 of /var/sites/xxxx/public_html/sites/all/modules/views/plugins/views_plugin_display_page.inc

I followed the link to the related issue but that doesnt seem relevant to my error?

Rolled back to 7-3.21 and I can now clear cache and run update.php

This is unrelated to the above bug that Damien mentioned.

This bug was introduced in release 7.3.23 in commit 0d270fa by Damien McKenna in a change to `views_plugin_display.inc` to return FALSE from `get_plugin` instead of no return if the plugin doesn't exist.

Relevant Git diff snippet:

@@ -898,6 +940,7 @@ class views_plugin_display extends views_plugin {
    *   The name of the plugin defined in hook_views_plugins.
    *
    * @return views_plugin|FALSE
+   *   FALSE if no plugin, otherwise the requested instance of a plugin.
    */
   public function get_plugin($type = 'style', $name = NULL) {
     static $cache = array();
@@ -931,7 +974,7 @@ class views_plugin_display extends views_plugin {
       $plugin = views_get_plugin($type, $name);
 
       if (!$plugin) {
-        return;
+        return FALSE;
       }
       if ($type != 'query') {
         $plugin->init($this->view, $this->display, $options);

This caused a poor interaction in line 90 of `views_plugin_display_page.inc` which checks if the access plugin is set rather than falsey which means it doesn't use the fallback and a method is attempted to be invoked on FALSE:

    $access_plugin = $this->get_plugin('access');
    if (!isset($access_plugin)) {
      $access_plugin = views_get_plugin('access', 'none');
    }

    // Get access callback might return an array of the callback + the dynamic
    // arguments.
    $access_plugin_callback = $access_plugin->get_access_callback();

Thanks for debugging this @chippiewill.

I grepped for 'get_plugin' on the whole code base and found a few more cases. Hopefully I did catch them all, it's kind of hard to trace these and requires a lot of concentration... The patch is attached with the "hard" suffix. As an alternative, I prepared another patch that changes the return value of the method in question from FALSE to NULL, which should work as well. I attached that patch with the "easy" suffix. Note that both patches are dry coded and I have not done any testing on them, yet. Let's see what the test bot thinks about both approaches. No interdiff, since it's trivial.

Ok, not as bad as I expected, but it underlines nonetheless just how risky and hard the hard way to fix this actually is ;). Let's try a new patch that hopefully fixes the test failures. The "easy" patch in #11 still is an alternative way to fix this.

Let's try to add a test that should have flagged this. Again there is the "hard" patch trying to make it work with the existing get_plugin() return value and the "easy" patch that changes the return value of get_plugin().

The only way I was able to test for this locally was by providing a view with an access plugin that didn't exist, so that's what the test does. From a security standpoint, I find it kind of questionable that "access plugin doesn't exist" is the same as "no access check". E.g. consider a case where some custom or contributed module that provides an access plugin in use on the site is inadvertently removed or the plugin otherwise fails to load and then the views using this access plugin are suddenly without an access check and might disclose sensitive information. I would rather differentiate between the case where $handler->display->display_options['access']['type'] is not defined at all and where $handler->display->display_options['access']['type'] points to an access plugin that does not exist or can not be loaded. But it seems that it has always been this way until both of these cases resulted in the whole site being inaccessible in the latest release, so let's concentrate on fixing the regression for now and discuss anything else later...

easy patch on #14 didnt work for me - still getting:

Fatal error: Call to a member function get_access_callback() on boolean in ....../views_plugin_display_page.inc on line 96
Drush command terminated abnormally due to an unrecoverable error.

The hard patch in #14 worked for me.

The easy patch in #14 worked for me.

The easy patch in #14 worked for me.
I did not try the hard patch

The hard patch in #14 worked for me

The hard patch in #14 worked for me. Thanks!!!

Does anyone know of a way (as simple as possible) to reproduce this problem? That would make reviewing easier.

@BrankoC, #14 describes how to reproduce and the hard fix added a test case.

I believe that #14 hard patch works for me. Without it, I could not run drush cc all without getting an unrecoverable error.

The patch #14 worked for me. thanks

My solution was that:

1. Line 96:
$access_plugin_callback = $access_plugin->get_access_callback();

I changed it to:

$access_plugin_callback = false;

2. F5 and I had my site returned, disabled the view I created earlier, restored line 96 to how it was, cleaned cache, and re-enabled the view.

3. To make sure it worked completely, I cleared the cache again.
The error does not appear, my site does not break again.

-

I have reproduced the error several times when wanting to follow this Drupual Commerce tutorial https://www.youtube.com/watch?v=XOg_uWiC5MY, but before that I have created a Categories view, then I follow the instructions of the tutorial, when I installing these required modules:

- Node View Permissions (node_view_permissions-7.x-1.6).

- Commerce (commerce-7.x-1.15).
- Cart.
- Checkout
- Commerce.
- Commerce UI.
- Customer.
- Customer UI.
- Line Item.
- Line Item UI.
- Order
- Order UI.
- Payment.
- Payment Method Example.
- Payment UI.
- Price.
- Product
- Product Pricing.
- Product Pricing UI.
- Product Reference.
- Product UI.

- Commerce Card on File (commerce_cardonfile-7.x-2.0-beta6).

- Commerce License (commerce_license-7.x-1.3).
- Commerce License Role.

- Commerce License Billing (commerce_license_billing-7.x-1.0-beta4).

- Commerce Customizable Products
(commerce_custom_product-7.x-1.0-beta2).

- Date (date-7.x-2.10).
- Date API.

- Entity Bundle Plugin (entity_bundle_plugin-7.x-1.0-beta2).

- Address Field (addressfield-7.x-1.3).

- Entity Reference (entityreference-7.x-1.5).

- Advance Queues (advancedqueue-7.x-1.0).

- Rules (rules-7.x-2.12).
- Rules translation.
- Rules UI.

- Commerce Card on File Testing.

- Views Bulk Operations (views_bulk_operations-7.x-3.5).

- Views Megarow (views_megarow-7.x-1.7).

- Views (views-7.x-3.23). ***
- Views UI.

After doing all that, my site breaks.

Also have Commerce installed. Wonder if there is a conflict. Was getting similar error messages, unable to flush Views cache without error, unable to see menu links for pages made in Views
#14 hard patch seemed to work for me, BUT ONLY temporarily.

Went to clone a view and now I have fatal errors:
Class 'views_handler_field' not found in
.../sites/all/modules/registration/modules/registration_views/registration_views.module on line 303
Call to undefined function system_get_info() in
.../sites/all/modules/context/context_layouts/context_layouts.module on line 92

That issue doesn't sound related to the patch. If you look at the code for the patch, it didn't change much. I can clone views just fine using the hard patch.

You're right. Finally got it working again after errors and WSOD. Problem was that I had renamed old Views folder to Views-HOLD rather than deleting it before uploading the patched version, then even after I removed it, it was evidently stuck in cache, which I was unable to effectively clear for a while. Finally managed to clear cache after temporarily deleting the Registration module folder to gain access to the update.php page, reuploaded the Registration module and ran update script.
Seems fine now, with hard-patched version.

Committed. Thanks everyone!

I'm getting this error after installing Commerce License. I'm running Views 7.x.3.23. Any idea when 7.x.3.24 will be coming out so I can get this fixed? Is n3054091-14-easy.patch the one I should try to run to patch it in the meantime? I tried and it keeps telling me it can't find the files that are mentioned in the patch. I have it in the Views folder. Should I have put it elsewhere?

I'm running:

patch -p0 < n3054091-14-easy.patch

Patching from inside the views folder is correct, but you should use patch -p1 < file.patch (p1 instead of p0). The hard patch has been committed by the maintainer and will be in the next release, but I think both patches have been sufficiently tested by the community by now, so either one should fix it for you.

Unfortunately, we can't say exactly, when the next release will be ready. Hopefully it will be soon, but it's done, when it's done. You can follow the parent issue referenced in the sidebar, which is the planning issue for the next release. Child issues of the planning issue will need to be fixed before the next release.

Perfect, thanks. That worked. As long as I have a patch that is working, I'm good to wait. I just wasn't certain whether the issue was indeed fixed with one of the two patches. :)

Now I should be able to move on to the next parts of installing Commerce.

I got this same error after installing H5P module. So not related to commerce.

I was able to fix it without patching, just manually cleared all the "cache" tables, then was able to run "drush cache-clear all"
and I got site back up.

But maybe I have to patch this if it happens again, but the site was working really many months I guess, only after this module installation crashed.

I Have Views 7.x-3.23 and PHP 7.1

@jukka792, did you try using the "hard patch" in #14? This issue already has a patch committed for 7.x-3.24.

Thanks #28 adrianolmedo, the manual script update described allowed to get my site backup.

I was also working on installing/activating Commerce module and its related modules/features. Initially I built a Commerce-WebForm form on my local host. Next step was to build it on the shared hosting site, then the errors appeared. Happy to get my hosted site backup and plan next steps.