Lost panel pages when upgrading to 3.3

Did you upgrade CTools at the same time?

Be sure to clear all caches and that the menu system gets rebuilt, then. If Panels detects that CTools is too old for it, it removes all its menu items to prevent whitescreens. It also will post a warning on the system status page that no one ever looks at.

When I updated to panels 6.x 3.3 and ctools 6.x 1.3 my link reappeared in the admin/build section. However, I lost all my pages and page list? Is there a folder in ctools like drupal/sites that needs to be downloaded and reinstalled with each ctools module release?

Hi,

similar problem here on several sites, or to be exact: on every site where I upgraded to ctools-6.x-1.3 and panels-6.x-3.3.

Upgrade procedure:

Upgraded through Drush to Chaos tool suite [ctools-6.x-1.3], and Panels [panels-6.x-3.3], in this order, plus an additional "drush updatedb", and an additional run of update.php as user #1. "Clear all caches" through Admin_menu and "Clear views cache" at ./admin/build/views/tools/basic.

Configuration:

Installed sub modules:

• Chaos tools 6.x-1.3 (enabled)
• Page manager 6.x-1.3 (enabled)
• Views content panes 6.x-1.3 (enabled)
• Bulk Export 6.x-1.3 (not enabled)
• Chaos Tools (CTools) Plugin Example 6.x-1.3 (not enabled)

• Panels 6.x-3.3 (enabled)
• Mini panels 6.x-3.3 (not enabled)
• Panel nodes 6.x-3.3 (not enabled)

I'm using the "simple cache" ("1 minute"), but neither arguments nor contexts or other fancy stuff. The problems do not go away after the "simple cache" is refreshed (after 1/10/60... minutes).

Several sites were upgraded from D5 and most of the panel pages were re-build for Panels 3.x and Views 2.x; some other site are native D6 setups without migrated/converted views or legacy stuff from Panels 1.x/2.x, so this is most probably not an legacy issue.

Symptoms:

Panel pages used as frontpages are severely broken for anonymous and logged in users; embedded content (Variants/Panel/Contents) partially vanishes, e.g. a view is not displayed anymore, embedded (system) blocks are still there; (system) blocks with rss feeds have no feed content anymore. On another site, all content is gone frome the panes, meaning: nothing is being shown anymore (views pages as well as views blocks), however the panel pages can still be edited at ./admin/build/panels/dashboard. (Re-) saving the panels doesn't bring the content back. On a third site, all panel content is views based, and the only thing left visible is (a) the views title, (b) the "more" link, and (c) the panel decoration ("round corners"). Views pages (behind the "more" links) are still working properly, so this seems to affect Ctools/Panels only.

This upgrade broke em every panel on five different sites in one or another way and left not a single panel page intact. Sites that make heavy use of Panels become completely unusable, and switching back to a backup becomes necessary.

I'd consider this issue as highly critical and would suggest to revoke the release as soon as possible as it causes severe damage and renders the module almost completely useles, if not even harmful. Instructions and/or suggestions to fix the damage would be highly welcome - e.g. if it would be safe to switch back to an older release, or if there is any other way to use ctools-6.x-1.3/panels-6.x-3.3 at all.

Thanks & greetings, -asb

Some additions:

Regarding broken rss feed blocks, Watchdog logs the following error multiple times when accessing a panel page with embedded system block:

Object of class stdClass could not be converted to string in /var/www/drupal/sites/all/modules/panels/templates/panels-pane.tpl.php in line 39.

Regarding broken views, Watchdog logs errors like this when accessing a panel page with embedded view:

Location: ./?ofact=0&ofmsgid=&ofdisp=2&ofpage=&ofrand=13829
Object of class stdClass could not be converted to string in /var/www/drupal/sites/all/modules/panels/templates/panels-pane.tpl.php in Zeile 39.

Maybe these error help tracing the problem...

Just another update:

For me this issue also applies to newly created panel pages. They can be created as usual, and when the cache at ./admin/settings/performance is being cleared, all views-based content vanishes completely from the panels.

In the current state, the 'panels' module is absolutely useless :-(

Greetings, -asb

I have this problem as well. This is not just a problem with upgrading existing panels. Up to this point I have only been using Mini-panels on my site, but I was hoping to start using Panel Pages, based on earlier successful experimentation. But now even when I try to create a simple panel page, it shows as completely empty, both in the Preview and in the actual URL. All of the CTools examples exhibit this problem as well. There is just nothing displayed at all. I agree with asb that this makes Panels (or at least Panel Pages) completely useless.

Do you have caching enabled on the panel displays?

In my case (panel pages), the "Simple cache" is enabled partially (some panels, some sections). If I disable the cache, the content comes back.

That somehow explains, why new panel pages at first do show content and later, when doing an "Clear all caches" in admin_menu, it is lost.

So there remains the performance problem to solve ;) Is it safe to use the views built-in cache together with Panels?

Thanks & greetings, -asb

subscribing. very similar issues if not the exact same as asb.

My panels have been dstroyed. I no longer have the organic panels variant as an option to add new panels. Only "panel" Variant. I M

Subscribing. Very similar issues on my end.

Also seeing this problem after an upgrade to 3.3.

Instead of passing the $content string on line 39, you are passing this.

object(stdClass)#36 (5) {
["subtype"]=>
int(4)
["title"]=>
string(11) "Our Purpose"
["content"]=>
object(stdClass)#36 (5) {
["subtype"]=>
int(4)
["title"]=>
string(11) "Our Purpose"
["content"]=>
*RECURSION*
["type"]=>
string(6) "custom"
["css_class"]=>
string(13) "content-panel"
}
["type"]=>
string(6) "custom"
["css_class"]=>
string(13) "content-panel"
}

But they now seem to have returned. I'm confused but will report back if anything more comes of this.

Some more information.

I cleared the cache after the problem appeared. Then when I reloaded the page, the problem was there. A subsequent reload made the issue go away and the content appeared.

On a new computer, I load the page - the issue is there. (Same var_dump as shown above). When I refresh, the content appears.

Happens for all the panels except my Custom PHP content, which loads fine every time.

subscribing. I'm having a similar problem, with cached panels.

I removed simple caching from those panels that displayed a views display, because they were conflicting with each other, but one of the panels (I don't know which one) is still giving this error...

I had a similar issue where all panels were lost, along with my admin link to panels, when upgrading panels to 6.x-3.3, but after upgrading ctools to 6.x-1.3 and refreshing cache all panels (and panels admin link) are back and everything is OK.

If a cache clear temporarly fixes your problem, see #655268: Cache problem with 3.x-dev / also present in 3.3 release

Thanks. #19 That helped. That is scary when you update panels, not realizing that it is not only dependent on ctools but on a certain release of ctools. That dependency should be better noted on the modules list page.

Drupal doesn't have any built in version dependency handling, so I'm doing it all manually. I'm not sure I *can* put something in on the modules page, but maybe I can find some better way to inform people.

I try to always mention it in the release notes, but people rarely read them. :/

I was going to say that they are in the release notes but maybe I'm the only one that reads them :)

Had the same problem, but a couple of refreshes later it was fixed. Heart skipped a beat though :)

Actually... it seems that the first time you visit the page it throws up the
"Object of class stdClass could not be converted to string... panels-pane.tpl.php on line 39" error.

If you then refresh it sorts it out, but the first time a user visits the site it appears as I see quite a few of them in my logs. I have also tried disabling the Poorman cron run I had set up, but same prob.

BTW - Not viewing with IE, have disabled all performance caching, using latest version of Chaos Tools 6.x-1.3 and using Panels version 3.3.

Just disabling the caching I have set on the individual panel panes, hopefully this will sort it out. Will report back soon.

[edit] nope still throwing up the error.

[edit] have changed line 73 in /modules/panels/includes/plugins.inc - see http://drupal.org/node/655268
from : $content->content = $cache->content;
to: $content = $cache->content;

That seems to have sorted it for now.

Views caching is still working fine, Panels caching is not.

#25 needs to be evaluated and should be rolled into a proper patch.

Caching, caching...if only there were an issue for the caching problem. Oh wait. #655268: Cache problem with 3.x-dev / also present in 3.3 release.

Rather than re-opening a completely inappropriate issue.

subscribing