Return early of pane has no content, to prevent notice

I like this more than the (object) cast being used in an earlier patch, so committed.

This patch has introduced a couple of undesirable side-effects:

1) the empty content for these panes (which may potentially have been expensive to generate) is not cached.

2) modules do not have any opportunity to manipulate the content with hook_panels_pane_content_alter.

The object cast approach did not cause these problems.

git revert 2e6370ce36b82e3019a7dd73e65eb6b09deecc08 ?

Uploading the revert patch so that I can reference it.

Here's a slightly updated patch:

• Removed pointless variable priming with FALSE
• Removed skipping of caching if content is empty
• No casting of return of ctools_content_render(). ctools_content_render() returns nothing or an object. (At least as far as I understand the code)
• Added condition to skip css handling if the content is empty.

Looks and tests good. Fixed!

http://drupalcode.org/project/panels.git/commit/692ad30

The object casting originated in #1241064: In panels_renderer_standard::render_pane_content(), the return value of ctools_content_render() should be cast to an object. (commit 8b9c1ce39d9358be2a62356a0e98ea4c791c7869 )

Are we causing a regression here?

Unrelatedly, the comment "Pass long the css_id" seen in this patch makes no sense. I imagine it was supposed to be "pass along..." ?

Are we causing a regression here?

I don't think so because the issue described there related to the "css configuration code". And the patch from #7 encapsulates that part as a whole into a condition that checks if $content is not empty.
Thus the code that caused the other issue won't be executed if there's no object.
For concerns about returning content that isn't empty and isn't an object I just can say that ctools_content_render() deals with an object too. So we would hit an issue there before panels_renderer_standard::render_pane_content() is executed.

Right, I think I concur with that. panels_renderer_standard::render_pane_content() is only called by panels_renderer_standard::render_pane() which is diligent in not making assumptions about the return value.

The only pitfall I can see is that the implementations of hook_panels_pane_content_alter I can see (there are a couple in my current codebase) are assuming that $content is an object. However they're also assuming it's an object with a content property, and casting NULL to an object isn't going to magically add one of those, so I think it's entirely reasonable to call those bugs in the implementations and expect them to verify their assumptions!

Call this a post-commit RTBC :)

A patch for that typo I noticed.

Every module implementing hook_panels_pane_content_alter() must be ready that $content can be NULL, right?

maximpodorov: yes, I believe so.