recoverable fatal error: Object of class stdClass could not be converted to string in /home/websites/draven/public_html/sites/all/modules/ctools/views_content/plugins/content_types/views.inc on line 132.

This happens on every page.

I use : panels, panels everywhere, cck, views.

I have no idea what causes this or where it might come from.

Details
Type php
Date Thursday, May 6, 2010 - 4:20pm
User Draven Caine
Location http://www.guardiansofthenight.com/
Referrer http://www.guardiansofthenight.com/roster/palisade_caine
Message Object of class stdClass could not be converted to string in /home/websites/xxx/public_html/sites/all/modules/ctools/views_content/plugins/content_types/views.inc on line 132.
Severity error
Hostname XX.XX.XX.XX
Operations

Comments

Status:Active» Postponed (maintainer needs more info)

Try updating to the most recent -dev to ensure it's still occurring, or at least so I have a line number I know is accurate.

EVERY page? Including admin pages? I need more to go on, here.

Title:recoverable fatal errorstdClass could not be converted to string: views_content/plugins/content_types/views.inc:132

Actually helpful title.

Version:6.x-1.3» 6.x-1.4

I report a similar bug. The trigger was embedding a view in a pane. I'm using both panels and panels everywhere. So the error message appears for each page that loads the pane with the embedded view.

I've tried both a content pane display and a block display, to no avail. The issue persists. I'm using Views 3.
I've even upgraded to the dev version, but it was slim chance of being something very different from the stable release that happened today.

Thank you,

Status:Postponed (maintainer needs more info)» Active

I've updated the issue status accordingly.

Further details. And a fix. Instead if choosing 'Views' and then the 'Content Pane' display in the pane setting I choose 'Views panes'. And everything goes smoothly. No error message is generated.

Right now I'm using two views without arguments, but later today I will create a view with an argument and see how it goes. I'll report back.

Thank you,

Updating my report on this bug. I've created a View with a Content Pane dislplay that receives two arguments. In the pane the arguments are taken from the context. It works flawlessly.

To recap. The only way I can reproduce the bug is by embedding a view that doesn't receive arguments and choosing not the Views Panes from the pane content menu, but as a View, selecting the content pane display and leaving it like that.

Have any idea how to go about what view could be adding this issue?

Priority:Critical» Normal
Status:Active» Fixed

"embedding a view in a pane" <-- this terminology is confusing, I'd rather you didn't use it - it seems to suggest that there's this "pane" is an independent thing to which a view has been stuck, and that maybe there's even some other stuff in there. That's really not how it works - the 'pane' is just a minimal container for that holds the view. The pane doesn't exist unless there's the corresponding view.

That said, I think I understand why you're phrasing it that way - because you're going about combining Views and Panels backwards. The items listed under the 'Views' category are an inferior approach to combining the two, intended only for the barest convenience (hence the 'L'(egacy) on the pane icons in the add content modal). This legacy case is a little more like 'embedding' views. But this is why the 'Content Pane' Views display type exists - as a better connector. So trying to use the legacy approach with a Content Pane display defeats the _entire_ purpose of creating a content pane display in the first place. I've modified the legacy pane settings dropdown so that it no longer includes Content Pane display types in it at all to avoid this in the future.

If you're gonna use legacy, use legacy. The Content Pane-based connector is, however, almost always better.

Yes I understand that. I've never paid much attention to the 'Pane Settings' that appears in the 'Content Pane' display. Somehow I think it makes more sense to have it next to the panel settings. After all when I choose a context or add a relationship that's something that will feed a View further ahead. I also choose the identifier that a given context or relationship will use in the panel settings.

In workflow terms I think it makes more sense to have it in the panel settings, although it really defeats the purpose of the Content Pane display type. Testifying that is the fact that I've never bothered with the 'Pane settings'. It seemed like a duplication of settings form. I understood that one of them was legacy, but I thought that it was the View 'Pane settings'. I was wrong.

Surely the fact that it's a better connector to have a 'Content Pane' display type and a 'Pane Settings' dwarfs the convenience of a more streamlined workflow when building a panel.

Thank you for your reply and above all for your work on panels & ctools.

Related issue:

#764006: PHP error when viewing panel

Panels Everywhere might be involved too, sending non-string arguments.

@drifter: hmm, I hadn't noticed that issue, I'll have a look at it too.

@perusio: They are different use cases, admittedly. I typically discourage use of the 'legacy' for two basic reasons:

1) That's a crap-ton of configuration on the legacy settings form, much of which is sensitive to conf on the View itself - though none of that conf is visible, since you're in the Panels interface. The sheer quantity of it increases the likelihood of a screw-up, inadvertent or otherwise. It also contributes greatly to configuration numbness. Moreover, even if it's OK for me, it makes it far easier and safer for me to pass the site over to a less experienced developer. Or even just for me - it's FAR easier for me to come back a couple months later and debug/change something if I don't have to comb through two dozen form settings and try to reconstruct my memory of why I configured it the way I did.
2) Since all that configuration is specific to that pane instance, and there's no way to reuse a pane instance (yet), legacy views are completely non-portable. By creating Content Pane displays on the view itself, I'm making reusable bits that conform tightly to the requirements of my IA - that is, I can create a Content Pane which represents a specific way of using a particular View that might need to be used four or five places throughout my site in a slightly different way. So instead of thirty clicks and repetitive configuration setting for each of those instances, I just do all that once on the View, and offer up overridable options to the pane that reflect the variations my IA dictates will exist across those four variations.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.