Trying to get property of non-object in user_access() with 2 admin views on the same path

Same here .. issue happened after updating the module.

and same here

getting a lot of notices on all page requests
Notice: Trying to get property of non-object em user_access() (linha 811 de /modules/user/user.module).

What version of views and VBO is everyone using? Have you overridden the views?

I'm using VBO 7.x-3.0-rc1 - I have overridden the default view but just to update add a page view with a custom path.

After disabling and re-enabling I'm seeing a Broken Handler in relationships in the "system" view.

Relationships
Content: Author << Normal
Broken/missing handler << This looks like the culprit throwing the error.

That's why I was asking in #4 if people had overridden views. This would probably break things. All of you having issues were. I guess, coming straight from the alpha release to the 1.0. So there is really no obligation to provide an upgrade path :) Revert your views and you will be fine.

I don't have a revert in my views list. And anyway, doesn't revert mean I would lose the extensive changes I have made? On the staging site, this problem did not occur. In both sites I am running version 7.x.3.1 of Views and rc1 of VBO so it doesn't appear that these versions of are part of the problem.

Oops, my bad. Wrong information in my last post. On my staging site Views is on 3.5, though VBO is still in rc1. So possibly upgrading Views will solve the problem. I can't try it right now on the production site, but I wanted to quickly correct my last post.

@tdurocher - I can't promise this will do the trick, but I did something similar the other day which saved me some time.

In Views find "Administration: Nodes" (Or which ever view you're using) and use Operation "Clone" . You'll now have a "normal" view completely detached from the module. Disable the view made by admin views and work on the clone.

For me it was just a matter of delete the relationship with the author, and removing busted fields (as I don't need author info). You can very likely remove the broken handler and then re-creating the author relationship and effected fields. Much less work then recreating all your customizations.

Just to note future module upgrades won't effect the clone view any more.

Thanks afoster. This did work for my node listing view, but not for my user listing - a view I worked long and hard on. However, upgrading from views 3.1 to the latest - 3.5 - did the trick. I guess that's why only some of us were seeing this very major problem.

Glad you guys seem to have sorted your issues, Using a very old views release (3.1) with a new module release dependent on views is usually not a good idea. There are a few things that are only in views newer releases that this modules default views uses.

Also, if you are overriding these default views. I'm not sure we support that, especially not during upgrades etc..

Wanted to chip in, just in case someone had the same slight variation I had.

To the best of my recollection, I hadn't overridden anything, and I was using up-to-date versions of everything, but something, somewhere, created a duplicate Administration: Nodes view, called admin_content_node. So, disabled that and I was golden.

Cheers.

There must have been something overridden and saved in the database, otherwise with the update that view would have disappeared :)

The name of the view has changed from admin_content_node to admin_views_node. So, the only way you could have had both is one in code and one in the database.

Thank you @superjems, your solution worked.

I had two views as well:
one called admin_content_node at admin/content
one called Administration : Nodes at admin/content

Disabling admin_content_node solved the problem.

@giorgio79, you should really just delete the old admin view that you have saved in the database (admin_content_node). Alternatively you can run one the the CTools drush commands to revert all admin views in one command, which I would recommend :)

'drush cter views_view --module=admin_views'

Thank you damiankloip! Just deleted the admin_content_node. Also ran the drush command, but it did not remove the admin_content_node view probably because I disabled it before. Manually deleted it now.

superjerms++

I found the same view "admin_content_node" in the Views listing, and I did not create it, yet, it was most definitely the cause of the error for me. Instead of disabling, I just deleted the view, and life went back to normal.

Just to clarify (and as I mentioned in #12) to any more people having these issues; You will only have these old views if they had previously been saved to the database before you upgraded to the new version :) So first check which views are overridden (you can do this with drush ctools commands), as when the new views come from the new release, you have a database version that is now just in the database and not overridden.

Just updated from administration views to the new 7.x-1.0 and had the same issue.
Disabling the admin_content_node did the trick.
thanks so much!

Why not just delete the view?

I disabled it first just in case something happened. I just deleted it and everything fine.

Had the same problem, just cloned the admin user list view, made a page display, and then error message started appearing as well as the people admin menu item disappeared from admin menu.

I went into my new 'cloned' view and deleted the 'system' display and now all is well.

Hope that helps

Disable and then re-enable admin_views_user.

I have this issue too after updating to new version. But I included some custom Fields and filter criteria entries in my old admin_content_node. Not only one or two, I added several definitions. So could I delete new view and keep my old one ?
Or it is advisable to delete admin_content_node and recreate fields in new view?

It seems that this happens if you have any admin views overriding the same path, to fix you must disable one of them and clear cache.

EDIT: I think this is possibly still a bug though as if you debug what is actually causing the error it's passing the permission string as the $account object in user_access() which is obviously very bad.

I found it quite odd that admin_views provides defaults for all administration type pages because to export your own changes you must first clone the ones admin_views provides, then disable the defaults and export the new clone. However, the default's do help in getting a headstart

Bug exists in 1.2

Where are you seeing this being passed to user_access? Our access plugin doesn't use user_access. Elsewhere in views? More details on that would be good.

Also, why is it odd to provide default views for a module that is about providing default views?

@damiankloip Your code doesn't have to call user_access for it to be called, views will call this for each entity to ensure a user can see it.

To replicate this bug form a standard install:

1) Enable admin_views
2) Clone a default view from admin views (for this example I'll use Administration: Users)
3) Save the view with the same path
4) You should now see the errors at the top of the views edit page.
5) Navigate to admin/people, you'll see more errors and an Access denied (see screenshot).

I don't know why a permission is being passed as the $account object but I assume it's an issue with having 2 admin views with the same path. Should we not check when setting the path whether a display already has this path? Page displays do this already.

The thing about the default views: The reason I mentioned it is for the exact reason I found the bug. Most people would want to alter what the module provided by default. To do this they must clone, save, and disable the old view before their new one will work. Otherwise, altering the default view will make them non exportable.

Thanks, I'm ok with the access system. Let me be more explicit. What I mean is that this is an affect of upstream code in views, not this module.

Should we not check when setting the path whether a display already has this path? Page displays do this already.

Where do you mean page displays do this? They don't validate this on a UI level, you mean as a result of execute_hook_menu()? So this is invoked on display plugins from views_menu_alter, which does check for already existing paths. However, this checks the return value from execute_hook_menu so for normal pages this is fine, as it will only return n items array, but in admin_views we have modify the $callbacks array that is passed in by reference aswell.

I would say the best fix is possibly to add UI level validation of this?

To do this they must clone, save, and disable the old view before their new one will work.

Welcome to the CTools export system...

@damiankloip I am simply trying to fix a bug that other people may encounter, I'm not trying to prove you wrong as your responses suggest.

You are correct though! This is a bug in views itself, I remember the page display did used to validate on a UI level. That does not seem to be the case anymore and creating any display on a path that already exists causes this bug. Changing project, although there may be another issue already out there.

Backtrace:

Notice: Trying to get property of non-object in user_access() (line 798 of modules/user/user.module). =>
... (Array, 20 elements)
19: user_access() (Array, 2 elements)
file (String, 28 characters ) modules/user/user.module:798
args (Array, 2 elements)
0 (String, 23 characters ) access content overview
1 (String, 23 characters ) access content overview
18: _menu_check_access() (Array, 2 elements)
17: _menu_link_translate() (Array, 2 elements)
16: _menu_tree_check_access() (Array, 2 elements)
15: _menu_tree_check_access() (Array, 2 elements)
14: menu_tree_check_access() (Array, 2 elements)
13: menu_build_tree() (Array, 2 elements)
12: menu_tree_page_data() (Array, 2 elements)
11: menu_set_active_trail() (Array, 2 elements)
10: menu_get_active_trail() (Array, 2 elements)
 9: i18n_menu_node_context_condition->execute() (Array, 2 elements)
file (String, 80 characters ) sites/all/modules/i18n_menu_node/plugins/i18n_m...
args (Array, 0 elements)
 8: context_context_page_condition() (Array, 2 elements)
 7: call_user_func_array() (Array, 1 element)
 6: module_invoke_all() (Array, 2 elements)
 5: context_page_build() (Array, 2 elements)
 4: drupal_render_page() (Array, 2 elements)
 3: drupal_deliver_html_page() (Array, 2 elements)
 2: drupal_deliver_page() (Array, 2 elements)
 1: menu_execute_active_handler() (Array, 2 elements)
 0: main() (Array, 2 elements)

It seems that record in menu_router table is passing extra argument to user_access().

The following query listing all these invalid entries:

SELECT * FROM menu_router WHERE access_callback = 'user_access' AND access_arguments LIKE "a:2:%"

or by drush:

drush sqlq 'SELECT * FROM menu_router WHERE access_callback = "user_access" AND access_arguments LIKE "a:2:%" \G'

This should shows something like:

             path: admin/content
   load_functions: 
 to_arg_functions: 
  access_callback: user_access
 access_arguments: a:2:{i:0;s:23:"access content overview";i:1;s:23:"access content overview";}
    page_callback: views_page
   page_arguments: a:2:{i:0;s:16:"admin_views_node";i:1;a:2:{i:0;s:8:"system_1";i:1;s:8:"system_1";}}
delivery_callback: 
              fit: 3
     number_parts: 2
          context: 0
       tab_parent: 
         tab_root: admin/content
            title: Content
   title_callback: t
  title_arguments: 
   theme_callback: 
  theme_arguments: a:0:{}
             type: 6
      description: Administer content and comments.
         position: 
           weight: -10
     include_file: modules/node/node.admin.inc

See the access_arguments which has 2 items instead of one.

This could be caused that I've two views which share the same path and permission. Comment #29 confirms that.
This happens even if one of the view is disabled.

Duplicate of:
#1771140: view_menu_alter() adding to existing "access arguments" causes user_access() error

I was receiving this using Views 7.x-3.7, with VBO and Admin Views.

Cache clear fixed it.

This article helped me to fix the same error after enabling Admin Views:
https://swsblog.stanford.edu/blog/troubleshooting-administration-views-7...

I think the vast majority of users are encountering this after enabling Admin Views, so I'm moving this back to the Admin Views queue to make it easier to find, even though the root cause may lie within Views.

Reactivating to get feedback on #36

This is a won't fix for me. These problems are related to people upgrading from an alpha release I think?

For me at least the problem has nothing to do with an upgrade- it occurs on a fresh installation of admin_views 1.5.

#1771140: view_menu_alter() adding to existing "access arguments" causes user_access() error fixes this for me, but I don't know if it's the _best_ fix or not. From the sound of it, there may be a way to fix this in admin_views as well.

Getting same issue. I've cloned admin/content view and changed path into my custom path. When i tried to access my custom path, drupal says 'Page not found'. how to solve this?

But #23 is worked for me.

That is the expected behaviour. The admin views system handler does not work with custom paths, otherwise it would just be a page display :) You need to clone this as a page display. There was a recent security issue with the last release that had good reason for this.

@phponwebsites I have updated the issue description with the cause and workaround.

I also get this on a fresh install - admin/content was inaccessible after I cloned the "Administration: content" view. Disabling the original view and clearing caches fixed it up.

A possible solution is to remove the 'clone' option in the contextual menu and provide an 'Override' option instead, which would disable the original view and clone it.

Thanks @calebtr I have the same problem with my custom admin views. There was a duplicate path for admin/people in my case. Solved changing the custom view to another path or disabling the standard one.

Ditto with #44

Patch for review is attached.

Sorry, code formatting typo in last patch. Give this one a try. Thanks.

This currently checks all views and modifies menu router items for any view with a duplicate path, not just admin view ones.

This also looks overly complex in general to me, we could just load all views using the system display, and go from there. I'm not really sure I like the idea of altering menu data.

New version of the patch that limits to system displays. Regarding altering menu data, I only see one of four ways this issue can be resolved:

1) Remove the extra access arguments from menu data as is done in this patch.

2) Add validation to Views submit to block a system display from being saved when the same path already exists.

3) Modify Drupal core user_access to return FALSE if $account is a string.

4) Modify Drupal core menu creation to not allow a second item in an "access arguments" array that is a string.

The problem is Drupal uses the menu item's access arguments [0] and [1] for user_access($string, $account) (where $string is a permission). The cause of the Admin Views errors is the duplicate system paths create situations where the function being processed is "user_access('administer users', 'administer users')". This is completely wrong; the second parameter cannot be a string.

Yeah, We know what the issue is here. It's been around for a long while now. How this patch approaches it is not one that I want to commit I'm afraid. Altering menu items for what is essentially just a mis-configuration. This should therefore just be a validation error on the display path options form IMO.

If unwilling to accept altering menu data, you should have been more direct in #48.

To be clear, the menu alter is just to avoid displaying the user_access() notices. It doesn't fix anything, and it isn't permanent. Once the site builder fixes paths, the menu items are no longer altered.

Based on your response, I assume you consider displaying the PHP user_access() notices acceptable?

See attached. If you don't like admin_views_page_alter, just say so. However, I think it would be misguided to not give information to sites already using admin_views.

I don't like it. That's a worse approach as it runs on every page.

I said in #48 I didn't like the idea of altering menu data. Didn't realise you needed it to be more obvious than that...

I'm not overly interested in people that decide to configure two views to use the same path. We should add validation for this and leave it as that for now. As well as than even something notifying people in requirements would be fine. Running something on every page load to cater for more of an edge-case misconfiguration seems overkill.

I'm not overly interested in people that decide to configure two views to use the same path.

This comment made me give some extra thought.

I don't consider this the fundamental issue. What I believe is happening in 90%+ of the cases is people are cloning a default view, never modifying the path, saving the view, and not realizing there is a conflict.

To address this, validation should be added to both the path option and view.

One further update. Previous version had a couple of bugs that needed to be fixed. Also made the supporting functions more modular, which allowed some code to be removed.

The patch at #54 works like a charm for me.

The create content at admin/content page suddenly disappeared from admin menu and refused access at admin/content direct. No new modules, nothing changed, just suddenly occurred.

So 13 to 15 had it right for me.

I had two views as well:
one called admin_content_node at admin/content
one called Administration : Nodes at admin/content

Deleted admin_content_node view and content reappeared in the admin menu and all working fine. Solved for me, thanks.

The 2 year old patch in #54 to admin_views.module and views_plugin_display_system.inc still applied cleanly to the latest 7.x-1.x-dev, but after reading through this thread I'm not sure where to go with this issue.

@Chris2, my opinion is this is a nasty issue that can leave developers scratching their heads as to why this would be happening.

I believe patch #54 is reasonable and fair, and addresses the previous comments.

Thanks ron_s, I read through the issue thread a 2nd time and I agree. Is anyone else able to do another review/test before changing to RTBC?

- Cloned Administration: Users /admin/people
- Produces errors: Notice: Trying to get property of non-object in user_access() on multiple lines .../modules/user/user.module)
- Page /admin/people becomes inaccessible (Access denied)
- Installed/Used dev version - admin_views-7.x-1.x-dev
- Ran db updates, flushed cache, etc.
- refreshed /admin/people - still Access denied
- tested disabling the cloned view, admin/people is ok

Rerolled after #2411193: Move 'system' display plugin to a submodule was committed.

Committed. Thanks everyone.