I am adding a variant to the node-edit page for a specific content type. I am getting this error:

Warning: Invalid argument supplied for foreach() in panopoly_admin_panels_pane_content_alter() (line 79 of /srv/bindings/f98ba85cbbfc42ceac5e8bb4fe4bbcaa/code/profiles/panopoly/modules/panopoly/panopoly_admin/panopoly_admin.module).

Any ideas what to do to make this go away?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dsnopek’s picture

I have also seen this error appear for the same reason: saving a variant on the node-edit page in page manager. I haven't had time to dig into it and find the cause, though.

lsolesen’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Could you please try with rc5?

liza’s picture

same error, for the same reasons, but line 91:
Warning: Invalid argument supplied for foreach() in panopoly_admin_panels_pane_content_alter() (line 91 of C:\xampp\htdocs\www.bylizasabater.com\profiles\panopoly\modules\panopoly\panopoly_admin\panopoly_admin.module).

lsolesen’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I cannot reproduce this in rc5. Please reopen if you think that the error still persists.

lsolesen’s picture

Version: 7.x-1.0-rc4 » 7.x-1.0-rc5
gocreate’s picture

I can confirm that this issue still exists. I'm using the latest distribution of Panopoly that comes with Pantheon; as far as I know this is current.

My full error is:

Warning: Invalid argument supplied for foreach() in panopoly_admin_panels_pane_content_alter() (line 91 of /srv/bindings/somepath/code/profiles/panopoly/modules/panopoly/panopoly_admin/panopoly_admin.module).

I made only two changes and it started occurring. The first change was to revise the layout on the existing page at node/%node/edit. The second change was to rewrite a link in a Views content pane so that I could link directly from the edit form to another node's edit form. It occurs specifically when I switch between edit forms, or go from an edit form to a node view. It does not occur when I link from a node view to a node edit form.

If there's a fix I've missed in my research, please let me know. If not, and there's something I can do to help reproduce, I'm happy to oblige.

Thank you,

Dwight

dsnopek’s picture

Status: Closed (cannot reproduce) » Active

Re-opening! I've seen this one too.

liza’s picture

CAN WE PLEASE HAVE SOMEONE TAKE A LOOK AT THIS BUG?!?! am having this same exact message in a multi-textarea nodeform i've created.

Warning: Invalid argument supplied for foreach() in panopoly_admin_panels_pane_content_alter() (line 91 of C:\xampp\htdocs\www.bylizasabater.com\profiles\panopoly\modules\panopoly\panopoly_admin\panopoly_admin.module).

it appears every time i save or re-save a node or when i make a database backup with the DEMO module.

lsolesen’s picture

@liza you are very welcome to debug this issue. This is open source and people are working on it in their sparetime and is kind enough to share their work.

dsnopek’s picture

@liza: While I've seen this warning, unfortunately, I can't reproduce it consistently. I'll only see it once or twice and then never again. If you can provide step-by-step instructions to reproduce the error starting from the latest Panopoly from Git, that would help a lot!

Also, this message, is (as far as I know) completely harmless. It's a PHP notice at only the warning level. In all the situations I saw it, nothing broke - the node edit page still worked fine. If you're worried about users seeing it, you can route error messages only to the log. To do this, go to: Configuration > Development > Logging and errors.

Anyway, since I don't have instructions to reproduce and this message is harmless (as far as I can tell), it's a low priority for me personally. There are a number of other issues which DO cause fatal errors or security vulnerabilities, which I'll most likely look at before getting to this one during the small amount of volunteer time that I have to give to Panopoly each week.

If you want to expedite this, please post instructions to reproduce like I described above, or find a developer who is capable to debug the problem and entice them to dig into it for you and post a patch.

Sorry, I couldn't be of more help at the moment!

liza’s picture

augh... look, maybe i shouldve asked a different way, but look at the amount of weeks between this comment, my first one and your dismissal.

i apologize for the tone but, as a none coder, i need more than a "can't reproduce". why? what were you looking for? how did you try to reproduce the problem?

i actually didn't reply to your dismissal and tried to solve the issue. then, coincidentally, after i deleted a disabled pane from the form, the problem disappeared. now the error messages are back and with a vengeance. it appears in every single instance of the site.

i will go back again and flog myself with my setup, but instead of dismissing people with a "cant reproduce", please tell us what to look for and if you can't, engage us a bit more beyond a one sentence dismissal. that way, we will be all working together and helping those who after us may encounter this problem.

dsnopek’s picture

@liza: I attempted to send you a personal message via the contact form on your Drupal.org profile. Did you get it? Would you be interested in having a short call to discuss? Please let me know, thanks! :-)

liza’s picture

@dsnopek

thanks for following up and i apologize for the confusion, but i should have addressed my reply (and frustration) to LSOLESEN and not you. sorry about that.

as to your reply, that's actually quite helpful, but i have to ask: if it isn't a critical issue, why is it flashing as a "terrible error that may have things go ACK!"? is there a way to "downgrade" the error message?

in the meantinme, as i had to continue working; i may have discovered accidentally what's triggering it: CKEDITOR and/or FILTER FORMATS. basically if i create a node with CKEDITOR off, the error occurs. if CKEDITOR is on all the textareas where it's embedded, then the error disappears. i haven't tested further to see if it's a fluke. just noticed while copyediting the site.

dsnopek’s picture

@liza Thanks for response! I'm glad that we were able to reconnect. :-)

if it isn't a critical issue, why is it flashing as a "terrible error that may have things go ACK!"? is there a way to "downgrade" the error message?

This is a great question! The way PHP notices get displayed in Drupal leads lots of users to think that something big is broken, when maybe everything is fine. :-)

Unless you change the settings in Configuration > Development > Logging and errors, Drupal will show any PHP notice as a Drupal error message. However, not all PHP notices are equal! They can occur as several different levels: warning, notice, error, etc.

If you look closely at the message, you'll see that this one is a warning, because it starts with "Warning:" and notices will starte with "Notice:", etc. This means the developer did something that isn't great, but the PHP interpretter can truck on anyway.

You can actually configure in your php.ini which error levels get reported at all:

http://www.php.net/manual/en/function.error-reporting.php

So, if you wanted to make it so that only PHP notices at the error level got shown, you could modify your php.ini to have:

error_reporting = E_ERROR

And it will no longer generate error messages for pesky notices and warnings. :-)

I hope that helps!

lsolesen’s picture

@liza This issue was originally created for rc4. As I was not able to reproduce it following the description in the issue text on rc5, I thought the issue could be closed - leaving room to reopen if it still existed. IMHO not that terrible, but maybe it was too quick. :)

Another question, why are you using CKEditor, when Panopoly is designed to use and bundled with TinyMCE.

liza’s picture

@lsolesen

TinyMCE doesnt support all the WYSIWYG features and filters am using. i would have to go thru my notes to see which are those. but now that you've mentioned that, since I have both CKEditor and TinyMCE enabled as options, i'll switch the order and see if that may be the issue. i cant do testing at the moment though. am rushing to get things done so further testing & reporting will come later.

evilehk’s picture

Version: 7.x-1.0-rc5 » 7.x-1.1
Status: Active » Needs review
FileSize
773 bytes

When adding a page title element to a node edit form panel, the warning message "Warning: Invalid argument supplied for foreach() in panopoly_admin_panels_pane_content_alter()..." is thrown. In Panopoly 1.1 the warning is thrown from line 91 of panopoly_admin.module. As dsnopek points out you will not see the warning message if your php settings have error_reporting set to E_ERROR. I experienced this message after visiting a node edit page that had the "Page Title" element. The message actually appears on the next page after visiting the edit form and not on the edit form itself (unless you hit refresh).

To reproduce on a fresh install of panopoly:
1) Go to the panel settings page and select the "Panel pages" tab (admin/structure/panels/settings/panel-page)
2) Select the "Allow Other content" vertical tab and make sure "Page title" is checked. Press save.
3) Go to admin - structure - pages (admin/structure/pages) and click edit in the "node_edit" row to edit the Node add/edit form panel.
4) Click on the 'Content' vertical tab.
5) Either in the content or sidebar region, click the cog and choose 'Add content'.
6) In the Add content window that appears, pick the 'Page Content' tab and add the 'Node title'. I accepted the default settings but adding settings here is optional. Click 'Save'
7) Back at the panel edit page, click "Update and save".
8) Go to the edit form of any content. The next page you visit will display the warning message.

In ctools, the node title is rendered by the content type plugin. The callback function returns the title as a string. The panopoly_admin module implements ctools panel_pane_content_alter hook which looks to hide the title of the administrative pane if there is no content. This check assumes the content returned is an array.

I initially patched node_title.inc of the ctools module to return a markup renderable array which did solve the problem. However, a string is a perfectly acceptable return value and the issue is with the panopoly_admin hook assuming an array and not with ctools. Therefore, I made a patch for panopoly_admin that adds a check that the content is an array before attempting the logic to hide the title. The patch is attached.

liza’s picture

Version: 7.x-1.1 » 7.x-1.2
Component: Code » Admin
Status: Needs review » Reviewed & tested by the community
FileSize
971 bytes

HEY @evilehk! i completely forgot to acknowledge this patch and RBTC it because i see it wasn't included in the new release and the bug had reared, once again, it's ugly head. since i had to apply your patch by hand for 1.2, i just re-rolled it.

  • Commit 4c289d7 on 7.x-1.x by dsnopek:
    Update Panopoly Admin for #2051967: Error when changing node-edit page.
    
dsnopek’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, @evilehk, for the explanation of the problem and the great instructions to reproduce on a fresh install of Panopoly! It was super helpful in reviewing your patch.

And thanks, @liza, for testing the patch and marking it RTBC.

The patch has been committed:

http://drupalcode.org/project/panopoly_admin.git/commit/7beafc08e156da5b...

Status: Fixed » Closed (fixed)

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