Fatal error: Call to undefined method view::get_option() in sites/all/modules/admin_views/plugins/views_plugin_access_menu.inc on line 28
Any idea why this may be appearing when accessing any front-end page (except the homepage) only for logged out (anonymous users)...?
When does this module get called?
I'm running PHP 5.3.5 and the latest version of all modules with no custom code enabled.
Modules that are enabled:
404 Navigation
Add another
Address Field
Administration Development tools
Administration menu
Administration views
Block
CAPTCHA
CCK Blocks
Chaos tools
CKEditor
Color
Computed Field
Conditional Stylesheets
Contextual links
Database logging
Date
Date All Day
Date API
Date Popup
Date Views
Devel
Email
Entity API
Entity Reference
Entity tokens
Epsa Crop
External Links
Fancy Login
Field
Field collection
Field Collection Trim
Field SQL storage
Field UI
Fieldgroup
File
File entity
Filter
Flush All Caches
GeoIP
GeoIP Rules
Global Redirect
Google Analytics
ie6update
Image
Image resize filter
Image style flush
Imagecache Actions
Imagecache Autorotate
Imagecache Canvas Actions
Imagecache Color Actions
IMCE
IMCE Mkdir
jQuery Update
Lightbox2
Link
List
LoginToboggan
Mail Redirect
Menu
Menu attributes
Menu Block
Module filter
Node
Node clone
Number
Options
Options element
Override node options
Path
Pathauto
PHP filter
RDF
reCAPTCHA
RoleAssign
Rules
Rules UI
SpamSpan
System
Text
Token
Transliteration
User
Video Embed Field
Video Filter
Views
Views Bulk Operations
Views UI
Webform
Webform Reply-To
WYSIWYG Filter
Comment | File | Size | Author |
---|---|---|---|
#6 | admin_views-menu_access-1949786-6.patch | 801 bytes | plach |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedHave you reverted these admin views? People have had strange behaviour from having overriden views in the database, then updating this module. See the project page. I would try reverting all of these views first, as No one else has reported this problem.
OR
Are you trying to use my access handler provided by admin_views? You shouldn;t really be doing that.
Comment #2
damiankloip CreditAttribution: damiankloip commentedComment #3
sydneyshan CreditAttribution: sydneyshan commentedI've played with a few possible culprits and narrowed the conflict down to a custom View that defined a Page display, set the path to /search and defined the Access restrictions setting to 'Menu system path'. Changing this 'Access restrictions' setting to 'None' fixed the conflict. The page(s) I was trying to view (that displayed the error this issue relates to) had an exposed filter from this view displayed as a block.
I'm not sure what the significance of this setting is or why it would cause conflicts with the Admin Views module.
Comment #4
damiankloip CreditAttribution: damiankloip commentedThe menu system path is provided by the admin views modules, for the admin views system plugin. Unfortunately, views doesn't have a way to filter access plugins by display type. This access plugin will be completely useless if it's not used with the system display type.
Comment #6
plachI am experiencing this too, STR:
/admin
, e.g./test
/test
page/test/1
as an anonymous userExpected behavior: see the page content.
Actual behavior: fatal error.
The problem seems to be that the access plugin code tries to call the
get_option()
method on the view object instead of the display object. Additionally the item router path is compared to the current path, instead of the item actual path, that is'test/%'
instead of'test/1'
in the example above.The attached patch fixed the issue for me.
Comment #7
damiankloip CreditAttribution: damiankloip commentedThat fix looks good to me, and indeed, get_option() only lives on the display handler.
You are overriding an already existing path that is outside admin/ right?
Committed to 7.x-1.x
Comment #8
plachThanks!
I am embedding the view in a page generated by a custom module: so, yes, the path is already existing.
Comment #10
idiaz.roncero#6 worked like a charm.
I was having a different problem - it was the logged-in non-admin users who couldn't access their own /user pages. Permissions were OK, and the PHP error was the same.
I just wanted to thank plach and inform that this error can come out also with authenticated users.