Error Message: has_path() on a non-object...

This is an error that used to appear in really old versions of Views. My best guess is that during the PHP upgrade, serialized data for the default views in your cache_views table would not unserialized under the newer version of PHP. Wiping out that cache probably would have fixed the problem.

I just experienced this same error. I'm using version 6.x-2.0-rc1. It appeared to happen after I created a custom views-view-fields.tpl.php file. Clearing my cache didn't fix it and neither did removing that file and clearing the cache again. However, I'm running a version of this site locally with nearly the same content and I'm not getting an error on that site trying to get into views.

Bob, did you end up needing to re-create your views after uninstalling and reinstalling?

Thanks for the info, Bob.

I tried just turning off Views and then turning it back on, but that didn't work (nor did I expect it). Did you do anymore more than an uninstall in the modules screen? I assume when you do that, it wipes all traces from the db?

For me, re-doing the Views should be quick as the local version of my site still works, so I can just export my Views from there when/if I get it working on my live site. I won't be attempting any of this until the weekend though.

Changed status to Active until I fix it.

I fixed my issue without uninstalling Views, re-installing and re-creating my Views. My issue had to do with the Calendar mod. At one time I installed it, but then realized I didn't need it. I'm getting this error when I disable and uninstall the Calendar mod. It seems I need the Calendar mod turned on to avoid this error. I'm thinking if I did a full re-install of Views, this error would be fixed, but I guess I'd rather keep Calendar installed than re-build my Views.

Merlinofchaos -- does this sound like an issue with Views or Calendar to you? Any other experience with Views not working if Calendar is uninstalled?

I had the same error. I also had Calendar installed but not enabled.

• After enabling the Calendar module, I was able to see the views page.
• Then, I reverted/disabled the Calendar view.
• After this, I was able to disable the Calendar module with no issues.

KarenS: Any ideas what might be causing this? I actually suspect this is a bug in Views itself, but Calendar is supplying the data so you might be able to give me a better idea of what's happening here.

Just one more person to say that I experienced the same thing. Error ocurred when calendar module present but not activated. Activating the calendar module made the problem go away.

Exact same problem for me, except activating the cal module did not help with the problem :(

I suspect that calendar displays that are stored in the Views database are causing these errors when you disable the Calendar module. I had similar reports of problems with the iCal module when it was disabled and fixed it by forcibly removing those displays from the database in my hook_disable() and hook_uninstall(). I'm thinking I need to add something similar to the calendar module to remove calendar-defined displays when the Calendar module is disabled.

If you ever save the default calendar, even if you don't use it, the data goes into the Views database, causing the error later if you uninstall the module.

I've been trying this idea out with the latest rc versions of Calendar and Views and I can't create any problems any more. I can create a calendar and then disable the Calendar module and I get no errors anywhere.

I still need to add an uninstall to remove the calendar displays if the Calendar is uninstalled, but it doesn't appear to me that disabling the module will create any problems any more, so I think this is since fixed somewhere in Views or Calendar.

If there are problems in the latest code, we need the new message because there is no longer anything at all on line 649 in Views.

Nope, there is still one problem and this is a Views problem. Here's how to recreate it:

1) Enable a module that defines its own display plugin.

2) Add that display to a view and save the view.

3) Disable the module that defined the plugin.

4) The view is still there and it contains a display that has no handler. Try to edit that view and you'll get a fatal error, the new message is:

Call to a member function has_path() on a non-object in ..../views/plugins/views_plugin_display.inc on line 688.

The workaround is to completely remove that display when the module is disabled, which seems unnecessarily destructive if you are just temporarily disabling a module. So it seems a better fix would be to check for missing handlers and bail out gracefully.

But maybe merlin has a better idea.

After a little more testing, it looks like Views bails out gracefully everywhere else, we just need a fix on that one line. With this patch I can edit the affected view without any fatal errors.

You're absolutely right, Karen; in fact, I realized recently that it is entirely possible for modules to ship views that have displays that might not exist. IN particular, panel panes seem like something modules might just utilize.

Committed. Thanks Karen!

My problem was a bug in my code, but this discussion was helpful and let me clarify things a bit if someone else comes by looking for the same answer.

I had a function as seen below which tossed this error until I added the following line:
$view->set_display('view_block_articles_by_type');

function articles_by_types_content($mytid) {
  $view = views_get_view('filter_articles_by_type');
  $view->set_arguments(array($mytid));
  // change the amount of items to show
  $view->set_items_per_page(5);
  $view->pre_execute();
  $view->execute();
  print $view->render();
  ;
}