Undefined property: stdClass::$did in skinr_panels_skinr_elements()

Actually, this is incorrect. The display's did is required here.

Which version of Panels and CTools are you using? I am not getting these problems.

I've tested with the following versions:
CTools 7.x-1.0-alpha4
Panels 7.x-3.0-alpha3

Did you create a panel page from scratch to test with, or was it a pre-existing one (imported, or provided by a module)?
I'm not sure why your pane wouldn't include the display did information while mine does.

I'm getting similar problem with Panels Everywhere and enabled “Provide a sample variant for the site template”.

Notice: Undefined property: stdClass::$did in panels_panels_pane_content_alter() (line 77 of [...]/sites/all/modules/skinr/modules/panels.skinr.inc).
Notice: Undefined property: stdClass::$id in panels_skinr_preprocess_index_handler() (line 65 of [...]/sites/all/modules/skinr/modules/panels.skinr.inc).

@Headache: does the patch in #5 resolve the notice from line 65 of panels.skinr.inc for you?

@moonray, yes, it does. But only for line 65. Notice for line 77 still exists.

Can you list which panels related modules are enabled, and on what sort of page (panels page, panels node, min panel, panels everywhere page) you are when the notices appear? I'm having no luck chasing this down.

List of packages: drush pm-list (png, 112KB)
Just did clear installation, enabled panels everywhere (#overlay=admin/structure/panels/settings/everywhere) and checked “Provide a sample variant for the site template” (so the first two options enabled).
No panel nodes, pages or mini-panels enabled. Only Panels Everywhere sample site template.

Well, it seems fixed after updating to 7.x-2.x-dev 2011-Jun-11. I'm not getting any notices now.

I've finally managed to track this down. It only happens for panels pages loaded through code.
The new tests in #1185224: Write tests for functionality plugins actually exposed this.

I'm not sure whether we can fix this easily. Going to have to run it past the panels people and see whether this is a bug on their end or expected behavior.

Well, investigating this further, I'm finding we're running back into the crazy idiosyncrasies of panels/ctools impregnability.
There are no hooks to let you process things on creation and deletion of panels and pages. The only hook in existence is hook_panels_display_save().

So, what this means is that we can't establish enough context for any panels when they aren't in DB (read from code), leaving us SOL. Also, if a page object gets overridden and saved to DB, the pid changes. We can react to that through hook_panels_display_save(), but if a page object is reverted, we have no way to react to that resulting in orphan skin configs (and for the user the skin config is lost).

This is quite annoying, and difficult to resolve. I had this occurring on my production site, but not on my local copy. The database was relatively in sync so I just dropped the skinr db tables from production db and imported them from my development db. This solved the problem, but of course is not a proper solution.

The easy 'fix' is to edit every panel that's stored in code and save it (without making any changes). This will store it in DB instead of code. It's not a very good permanent solution, though.

See #1292662: Skinr throws multiple errors on home panels page for a workaround using hook_install() if you are including your default panel pages or mini-panels in a module.

Don't know if this is related, but I'm getting a similar error (at least I think it's similar) when viewing my main forum page, which uses Advanced Forum. I don't get the error on my front page which is entirely panel-driven.

Notice: Undefined property: stdClass::$did in skinr_panels_skinr_elements() (line 41 of /home/scalemod/public_html/sites/all/modules/skinr/skinr_panels/skinr_panels.skinr.inc).

It repeats 12 times, but the rest of the page does seem to render ok.

Most likely advanced forum stores a panel in code, which is why you're getting this issue.

There doesn't seem to be a way in D7 to suppress writing errors to the screen, so where does a fix on this stand?

You can easily turn off error reporting here: admin/config/development/logging

Thanks, still not used to where things are in D7 over D6.

I am new to drupal, sorry if the question is not related to this topic, but may tha patch apply for myy problem with fusion_apply:

Notice: Undefined property: stdClass::$did in panels_fusion_apply_preprocess_index_handler() (line 65 of ...(localhost)... drupal7/sites/all/modules/fusion_accelerator/fusion_apply/modules/panels.fusion.inc).
Notice: Undefined property: stdClass::$pid in panels_fusion_apply_preprocess_index_handler() (line 65 of ...(localhost)... /drupal7/sites/all/modules/fusion_accelerator/fusion_apply/modules/panels.fusion.inc).

On more question, I am not currently using fusion theme any, does it make sense to keep on using Fusion Accelerator over the Skinr module?.
Thanks

Fusion uses quite an older version of Skinr for their base. Skinr has evolved since then, and the patch most likely won't apply.

As for using Fusion Accellerator over Skinr... I obviously would tell you to use Skinr since it's newer, better, faster (ok, that last one might still need some proof ;-) ). One down side of Skinr right now is that there is no upgrade path from previous versions. However, I'm working on the last major change to Skinr (iimplementing Context integration) after which the API will no longer change, and I will implement full upgrade from previous versions.

So, really the decision is yours, but I recommend using Skinr.

The title change is due to changes in code. The error is now in the skinr_panels_skinr_elements() function.

The attached patch doesn't actually fix the underlying problem (we need a Panels fix for this), but it gets rid of the notices and displays a messages offering a workaround.

Actually from looking at http://api.lullabot.com/panels_theme/7 and using dpm($variables), I was able to find the $did property in $variables['display']->did, not $variables['pane']->did. Attaching patch.

@Mark Carver: Using display instead when the panel is in code results in a non-unique ID, which is useless for our purposes. Sure it gets rid of the notices, but doesn't fix anything. In that light, the patch in #27 is still the one to use.

I've committed the patch in #27.
If you find any issues with it or have a better fix, feel free to post it and change the status of this issue to 'needs work' or 'needs review'.

For now, until we get any updates in panels that will allow us to change the way we're handling things, it set to postponed.

Is there a related Panels issue reported for this?

Not anymore that I could find. Panels ideally needs to have a unique ID for panel displays (did) and panes (pid), including panels in code. UUID seems the most logical solutions, and there used to be an issue related to it. However, I can't find it anymore.

Update: #1277908: Introduce UUIDs onto panes & displays for better exportability & features compatibility seems to look at implementing UUID.

The patch that was committed in #27 is not good IMO. The problem is that whilst there is a workaround in the referenced drupal.org issue, it is just that - a workaround, and not really aplicable for many sites, especially those that are mainly driven by features in which features are always supposed to be in their default state. The problem with the path is that it writes a standard status message to the screen using drupal_set_message(), and there is no way to disable this message other than implementing the workaround and overriding the panel's default state - which may not be a viable option.

It's good to point people to the workaround, but it shouldn't not be so intrusive as to unconditionally shove this message infront of people's faces.

@mrfelton What would you suggest as a better alternative, considering there is no possible good fix (due to panels limitations) at present?

I would suggest making the note about the workaround on the project homepage, and possibly as a watchdog entry, instead of a status message that shows up for all users.

Here is a patch that changes the status message to a warning in the watchdog. I think this makes a lot more sense. We need to alert site administrators to the problem which the watchdog call does, but we don't need to tell everyone else about it!

That looks like a good change. Will commit this as soon as I find a little time.

Committed #37.