Problem/Motivation
Getting a bunch of notices and tracked it down to authcache_panels trying to render a mailchimp block.
Notice: Array to string conversion in drupal_render() (line 5978 of /includes/common.inc).
This is what the rendered array looks like:
https://gist.github.com/joelpittet/b1cc3e5386e363f212a7
Proposed resolution
Not sure if the correct solution is to check and use the array as a renderable array or mark the block as not cacheable in the hook. In this specific case it shouldn't be cached because it's a form block.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 2429765-pane-content-as-render-array.diff | 854 bytes | znerol |
| #2 | notice_undefined-2429765-2.patch | 645 bytes | joelpittet |
Comments
Comment #1
joelpittetPossible solution?
From:
To:
Comment #2
joelpittetHere as a patch
Comment #3
znerol commentedIs the issue title correct? It does not seem to fit the summary.
According to your findings the
contentproperty of the$contentparameter passed intohook_panels_pane_content_alter()can be a string or a render array. Is that correct?It is not a requirement to load a block as an Ajax/ESI fragment only because it contains a form. At least as long as it does not contain any user-dependent default values (e.g. the email address of the currently logged in user).
Comment #4
znerol commentedFound #2430693: Warning: Missing argument 2 for authcache_panels_cache_settings_form_submit() while trying to reproduce.
Comment #5
znerol commentedRegrettably I was not able to reproduce this with a mailchimp subscription block in a panels pane. Do you use a special panels renderer class? Can you figure out what is calling
hook_panels_pane_content_alter? (grep forpanels_pane_contentin your source tree, use a debugger or use the devel module andddebug_backtrace()).Comment #6
joelpittetSorry I was sleeping on the title name, was trying to combine the two of the error message and where it was. Not sure how the word settings got in there...
Comment #7
joelpittetThat is good to know, this form is probably safe to cache then... I'm curious how I'd go about excluding that block though. The panel pane doesn't have authcache settings so I'm not sure why it's getting cached in the first place...
Does it default cache all panes?
Comment #8
joelpittetre #5 I don't have any special panels renderer class, I am using panels everywhere... maybe that is special enough? Is the debug information enough in the issue summary gist? It is a backtrace.
Comment #9
joelpittetYes, here's where I've seen this before:
http://cgit.drupalcode.org/panels/tree/panels.module#n1266
Comment #10
znerol commentedInteresting. In this case it would be better to leave the rendering of
$content->contentup topanels-pane.tpl.phpand instead just attach the personalization fragment to the existing render array.Comment #11
joelpittetOh good call. I'll put that into production, thanks.
Comment #12
joelpittetSeems to be doing the job thus far;)
Comment #14
znerol commentedThanks!
Comment #15
joelpittetThank you @znerol