Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I get the following error when I have set a view display to only permit access to role A and I visit the display as a user who is not in role A.
PHP Fatal error: Call to a member function access() on a non-object in sites/all/modules/views/includes/view.inc on line 229
I have the Content Access module installed, but I disabled it to confirm that it isn't the cause of the problem.
Comments
Comment #1
dawehnerCan you export your view please?
Comment #2
capellicSorry about that. Here it is.
Comment #3
capellicAny ideas? Thanks!!
Comment #4
capellicA gentle bump. :-)
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedI am confused. That view does not contain any access control.
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedHm. Ok, after dereine points it out I see it, even though firefox refused to find it earlier. Ignore #5.
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedHmm. I made a view similar to this and I can't replicate the problem.
It looks like the error is in view::choose_display(). Can you put some debug around the line that is failing and see what the $displays variable is set to?
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedMarking nmi -- need some debugging from source to determine what's going on here.
Comment #9
esmerel CreditAttribution: esmerel commentedNo updates for more than 30 days.
Comment #10
mpotter CreditAttribution: mpotter commentedI am getting this same error in Views 6.x-2.11 (different line number)
Fatal error: Call to a member function access() on a non-object in /sites/all/modules/contrib/views/includes/view.inc on line 237
Here is my view:
I looked at the view.inc file and added some debugging. Here is the relevant code:
If I print the $display_id when logged in a a user without the "admin" role, I get this:
If I log into user1 (or any user with the Admin role), then I only get this:
display_id: page_1
So the real problem seems to be whatever routine is calling choose_display and how it is generating the $displays argument.
For now I am patching my choose_display routine to check to ensure that display[$display_id] is a valid object. But somebody who knows more about how Views works should look into whatever routine is generating the $displays array and adding the extraneous "page" element somewhere
Comment #11
mpotter CreditAttribution: mpotter commentedActually, as a followup:
When logged into user1 (or other user with "admin" role), the $displays array *still* has both "page_1" and "page" in it. However the loop stops at the first one because the handler->access() routine returns true. If I just dump the $displays array directly, I still see that it has the "page" $display_id at the end.
So when the user does not have any access to any display, it gets to the "page" entry at the end and gives the error because $this->display["page"] is not a defined object.
Also, if I just patch this routine to check is_object($this->display[$display_id]) then it fixes the error, but then it causes the view to be displayed even if the user doesn't have access to it. Which defeats the purpose of the access control in the first place.
This is on a live site so I can't really play around with disabling modules or anything like that. The only other access module that the site uses that might be somehow interfering with this is the Forum Access module and the Menu per Role module.
Comment #12
amittarkar CreditAttribution: amittarkar commented@ mpotter : How did you figure out which module is causing the problem?