admin_views module needs to be updated to work with views 7.x-3.0-beta3

What's interesting is that views_plugin_display_system isn't a class provided by Views. It's possible that some module is misbehaving.

From looking at it, the error would indicate that views_set_page_view() is being called in appropriately. I am guessing by whatever module is providing views_plugin_display_system

And since that module didn't properly namespace its class, I can't tell what module it's coming from. You're going to have to figure out which module this is (grep for views_plugin_display_system should find it) and file an issue against that module.

Ahh, it's admin_menu

And it's probably because we recently fixed views_set_page_view to work like it says it does, so admin_menu needs to catch up.

Subscribing. I'm having some weird behavior with Administration menu since my upgrade (it loads late...the browser loads endlessly until I click "stop" and the admin menu appears) and want to see if this is related.

Same for me too. This was my first step into Drupal 7 from Joomla and I'm still not convinced I want to switch over...

subscribe. I've disabled the administration views module, and it brought back the content and user admin pages.

Yes, when I install D7.2, ctools dev, views dev, views_bulk_operations dev eveything is ok.

As soon as I enable admin_views I get a list of error messages stating:

''Notice: Trying to get property of non-object in user_access() (line 774 of /var/www/d7test1/modules/user/user.module''

And I can't list users etc. until I disable admin_views.

So this is probably as per #2.

Dig

subscribe

admin_views is unusable for me because of the problem. subscribing

subscribe

VBO has changed quite a lot in the alpha2 release. Quoting from #1182540: VBO missing after installation: "there is no VBO style plugin anymore. VBO is now a field."

The notice Notice: Trying to get property of non-object in user_access() (line 774 of drupal/modules/user/user.module' is caused by following code of admin_views in views_plugin_display_system::execute_hook_menu():

// Grep all callbacks for router items below the target path.
    $children = preg_grep('@^' . preg_quote($path, '@') . '/@', array_keys($callbacks));
    foreach ($children as $child_path) {
      // Only inherit properties from parent, if the child is not a default
      // local task.
      if (!isset($callbacks[$child_path]['type']) || $callbacks[$child_path]['type'] != MENU_DEFAULT_LOCAL_TASK) {
        // Add child to our stack of items to replace.
        $items[$child_path] = $callbacks[$child_path];
        // Ensure that the parent path really exists and inherit its
        // properties to the child (not replacing existing properties).
        if (isset($callbacks[$path])) {
          $items[$child_path] += $callbacks[$path];
        }
      }
    }

Since views_menu_alter() tracks all changes made to the callbacks by views and doesn't allow another full change of an already changed callback we end up with a nearly unmodified menu callback if a system view is a menu child of another system view (E.g. admin/content <-> admin/content/comment).
Unfortunately I'm not sure what the above inherit code is thought for. Thus I'm not able to provide a patch. For now I commented out this code and everything, what I need, seems to work atm.

Ok I was wrong - there were trouble :)
Drilled down a little more and I guess I understand the intention of the construct now.
To solve that issue views itself needs a patch - I'll discuss this with Daniel asap.

Meanwhile you find both patches attached here.
Don't be confused - the admin_menu patch also contains an indent fix (tab to spaces) ;)

Oh, and of course this needs review :)

+++ b/admin_views/plugins/views_plugin_display_system.incundefined
@@ -114,12 +114,10 @@ class views_plugin_display_system extends views_plugin_display {
-        // Add child to our stack of items to replace.
-        $items[$child_path] = $callbacks[$child_path];
         // Ensure that the parent path really exists and inherit its
         // properties to the child (not replacing existing properties).
         if (isset($callbacks[$path])) {
-          $items[$child_path] += $callbacks[$path];
+          $callbacks[$child_path] += $callbacks[$path];

Altering variables via references makes things also a bit easier to understand.

+++ b/admin_views/plugins/views_plugin_display_system.incundefined
@@ -196,9 +194,9 @@ class views_plugin_display_system extends views_plugin_display {
-      	  '#field_prefix' => '<span dir="ltr">' . url(NULL, array('absolute' => TRUE)) . (variable_get('clean_url', 0) ? '' : '?q='),
-      	  '#field_suffix' => '</span>&lrm;',
-      	  '#attributes' => array('dir'=>'ltr'),
+          '#field_prefix' => '<span dir="ltr">' . url(NULL, array('absolute' => TRUE)) . (variable_get('clean_url', 0) ? '' : '?q='),
+          '#field_suffix' => '</span>&lrm;',
+          '#attributes' => array('dir'=>'ltr'),

This is just tabs to spaces, so it's fine, got confused a bit here.

@Daniel Thank you very very much for your review. Awesome how fast you are :D
As discussed in IRC, I've created a related Views issue #1309518: Allow more complex scenarios in execute_hook_menu() by passing $callbacks as reference

Thanks for reporting, reviewing, and testing! Slightly adjusted and committed to 7.x-3.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.