I have Panelizer (2.x-dev Apr-29) setup together with Panels IPE. A default panel is provided for two content types. The default panel is exported using features and works like a charm until....

1. I create a node of type A or B
2. Click Customize this page (through IPE control)
3. Click Save
4. Click Customize this page (through IPE control)
5. Click Save
6. The panel is now emptied

If I between step 3 and 4 do a page refresh and then customize everything is still there.

Watchdog says "Notice: Undefined index: new-6 i panels_edit_display_form_submit()" after step 5 for each pane inside my panel that is supposed to be there.

I have debugged some and the pids being passed to the form submit on the second save are still the original ones from the default content. Since this no longer matches the pids retrieved from the database, the save fails.

I hope this was somewhat clear. Let me know if there is more information I can provide.

Comments

gooddesignusa’s picture

If you spin up a panopoly site on pantheon you will see it happens on there as well. following your instructions with the double save.

I was having this issue as well until I updated everything to the latest dev.
ctools 7.x-1.0+22-dev (2012-May-21)
Panelizer 7.x-3.x-dev (2012-May-16)
Panels 7.x-3.2+5-dev (2012-Apr-23)

Upgrading fixed that issue but I'm still having an issue that is very similar. For example hitting save causes one of my views to go away as well as a 'menu_block' pane that shows the current menu. If I refresh before I hit edit again its back. If I don't hit refresh before editing again those 2 panes read 'Placeholder for empty " (levels 2+)' or 'Placeholder for empty "View: header_media"'. Hitting save will now totally get rid of those panes. Even after hitting refresh they wont come back. You would have to manually add them again to the panel.
I think this issue and http://drupal.org/node/1520492 are related.

David_Rothstein’s picture

I just posted a Panels patch at #1520492: Saving a change in the IPE results in a blank page, fine after refresh, no error which might help with this issue.

Note that another way to experience this bug is that if you do the Customize -> Save -> Customize steps from above, but then instead of hitting "Save" again at the end, configure one of the newly-added panes (i.e., a pane you added during the first "Customize" step), you'll get a JavaScript alert box pop up with a bunch of garbage in it, but ultimately boiling down to this message: "Invalid pane id."

It's the same root cause as the bug described above (and which I can reproduce also), just another variation of the same underlying problem.

merlinofchaos’s picture

Status:Active» Needs review

Can you tell me if this patch affects the behavior?

merlinofchaos’s picture

StatusFileSize
new578 bytes

And by this patch I mean the one that's actually attached here.

pontus_nilsson’s picture

Status:Needs review» Needs work

I'm afraid that didn't help. The panel is still emptied on second save. Would it help if I provide a database with a setup where you can reproduce the error?

David_Rothstein’s picture

That patch looks like it only applies to 7.x-3.x (there is no $view_mode variable in 7.x-2.x)... Most of us have been experiencing the bug on 7.x-2.x.

I'm going to see if I can figure out a reproducible set of steps to trigger this bug (on 7.x-3.x, if possible). I understand the basics of what's causing it, but the site I'm seeing it on has a complex Panels configuration that wasn't set up by me, so I'm not yet sure the exact way you can get to it from a fresh installation.

David_Rothstein’s picture

OK, here are steps to reproduce:

  1. Fresh installation with Drupal 7.15, Ctools 7.x-1.2, and the latest Panels 7.x-3.x and Panelizer 7.x-3.x.
  2. Enable the Panelizer and the Panels In-Place Editor modules.
  3. Go to admin/config/content/panelizer and configure articles (plus the full page override view mode) to be panelized, and check "provide default panel" for the full page override.
  4. Save and click the "settings" link next to full page override, and change the renderer to the In-Place-Editor.
  5. Go to admin/structure/pages and enable the node view template.
  6. Create a new article, immediately click "Customize this page", add a new pane, click "Save", and click "Customize this page" again.
  7. At this point, trying to configure the newly-added pane gives the JavaScript alert error, and clicking "Save" again blows away all the panes on the article.
David_Rothstein’s picture

Oh, and I should have mentioned that the patch in #4 unfortunately doesn't seem to change things at all here either.

sylus’s picture

Can confirm the exame same error as David_Rothstein's using the latest dev of Panopoly Distribution as well.

sylus’s picture

Version:7.x-2.x-dev» 7.x-3.x-dev
Status:Needs work» Active

Setting to active, also changes version to 3.x as seems to be what patches are being done on and can be delegated back to 2.x

mgifford’s picture

Would it help if we could set up a demo environment so that this is easier to test?

I'm not sure how to best move this issue ahead. There are some tight timelines ahead of us and a lot is sitting on this bug.

@merlinofchaos - please let us know if there is anything we can do to help get this patched up.

sylus’s picture

Looked into this a bit more myself and I think @merlinofchaos was correct in a related post (http://drupal.org/node/1520492#comment-6361028) where he mentioned:

However, there may be something special about going from a default panelizer to one that is freshly saved in the db that I haven't reproduced exactly.

David_Rothstein’s picture

@mgifford, if you're in need of a quick fix for this bug, the Panels patch at #1520492-7: Saving a change in the IPE results in a blank page, fine after refresh, no error should help.

It may not be the correct fix in the end, but it works and we've been running it a while ourselves with no problems.

sylus’s picture

Gave the patch a shot that David_Rothstein mentioned for Panopoly Beta 5 and still receive the problem.

lurkingbeast’s picture

I have the same problem, panelizer with default layout (a custom layout) and IPE.

What I noticed also was that in my admin/reports/dblog I get a Panels log entry,

Panels: saved display "%node:title" with display id 58

Eventhough I was editing a node with the ID 61.

Also, might be just my server settings or other mixup that I couldn't track down yet, but during those panelizer Saves I get an http fetch error due to wrong path names, it's trying to fetch a ctools css file like this:
open() "/var/www/mydomain/httpdocs/public:/ctools/css/fd848c65195e0b93d016a21b9f257121.css" failed

The path and the file exists, but the public: should've been replaced with sites/default/files.

mgifford’s picture

Has anyone tried this yet with all dev versions of the contrib modules? The last time this was tried was August 22nd which was almost a week before the latest dev releases of:

  • ctools - 2012-Aug-28
  • panels - 2012-Sep-07
  • panelizer - 2012-Sep-05

It might well be that someone's resolved this issue (possibly without intentionality).

merlinofchaos’s picture

This bug still exists even with all -dev versions.

merlinofchaos’s picture

Ok, testing indicates this patch to panelizer fixes most of the problem.

However, fixing this reveals another problem, which is that for some reason, when the panel is rerendered, it leaves the old form (which now has invalid pane IDs in it) and the next time you customize, you get 2 forms, and one of them does not work, while one does. The attached patch to Panels fixes that.

sylus’s picture

StatusFileSize
new165.68 KB
new126.7 KB
new155.2 KB
new125.79 KB
new116.63 KB

Hey @merlinofchaos I have tried out the patches and I think it improves things but still a few problems. So you are aware these are the versions of panels + panelizer with associated patches:

projects[panels][version] = 3.x-dev
projects[panels][subdir] = contrib
projects[panels][download][type] = git
projects[panels][download][revision] = 7a8bd4e
projects[panels][download][branch] = 7.x-3.x
projects[panels][patch][1735336] = http://drupal.org/files/1735336-repaint-draghandle-ipe-initial.patch
projects[panels][patch][1572202] = http://drupal.org/files/1572202-panels-ipe-panel-emptied-on-second-save.patch

projects[panelizer][version] = 3.x-dev
projects[panelizer][subdir] = contrib
projects[panelizer][download][type] = git
projects[panelizer][download][revision] = 1238e8c
projects[panelizer][download][branch] = 7.x-3.x
projects[panelizer][patch][1572202] = http://drupal.org/files/1572202-panelizer-panel-emptied-on-second-save.patch


Steps Taken from a Fresh Install (Drush Make + Drush SI of Github Repo)

Proceeded to a panelized node page (features) and clicked Customize this Page

step1

Rearranged some panes by Placing Node Tabs above Node Title

step2

Saved the Panelized Layout (Notice Some Panes now missing)

step3

Clicked Customize this Page

step4

Refreshed the Page (Looks Okay)

step5

merlinofchaos’s picture

Hmm. I had that problem while I was working on the patch, but I fixed it by making sure the contexts were re-added to the display, and that problem disappeared for me. I wonder why you're still seeing it. Hmm.

merlinofchaos’s picture

Status:Active» Needs review
StatusFileSize
new1.53 KB

Ahh, I think I see why. Try this update to the panelizer patch.

sylus’s picture

Sadly I still have the exact same set of issues.

Is there some db queries I could perform for you?

I should mention that my distribution if built off of Panopoly. When I get home I am going to try on a regular panopoly setup to confirm it has the same problems but think it will have the same issues.

Definitely appreciate your help on this though! ^_^

merlinofchaos’s picture

It's not really about the queries. The thing I was using to test that I was getting the right data, is to peer at the DID of the display using error_log (because it's hard to use dsm during ajax operations).

What this patch should be doing is making sure that when clone_panelizer is called in hook_entity_update(), the new display is propagated back to the display cache so that when it is rerendered in panels_renderer_ipe::ajax_save_form(), it has the correct display. So the way to check on this is to try to follow the did. It takes a circuitous route to hook_entity_update through panelizer_panels_cache_save() and back to ajax_save_form()

There isn't really any query you can run. The whole issue is that when Panels IPE is re-rendering the display upon save, it is rerendering the wrong display which has invalid pane ids in it.

sylus’s picture

Thanks for the detailed explanation!

I'll try to use your explanation and stepwise through xdebug and see what I can find :)

Will report back here shortly ^_^

sylus’s picture

Just wanted to mention I did try Panopoly and it does have the same problem for only the first save. Though it does have no missing panes after a save and for all subsequent saves does not seem to have any problem. Perhaps the initial problem is just related to panelized node being in code (features) and after the first save the panelized layout then being in the database makes everything work.

As an aside is there something special about page_title and page_tabs being used in a panelized node full page override that they are the only elements that disappear after saving using Panels IPE? Looking at the error log it shows they appear as an empty value whenever I save, yet when I refresh they appear again. This is probably a separate issue so I filed it here: http://drupal.org/node/1780742.

Zach Harkey’s picture

I'm having the same problem but I'm not using IPE or saving twice — it happens when I create new revisions.

See: #1784032: "Create new revison" causes panelizer to revert to defaults

populist’s picture

Status:Needs review» Needs work
StatusFileSize
new108.08 KB

I tested the patch in #21 and it solves the major problem of double saving the IPE destroying the page!

There does seem to be an issue, which might be related to #25, that occurs with overridden default panelizer pages. To replicate you do this:

-- click "customize" on a panelizer node that is in default state
-- click "save"
-- click "customize" (without a page refresh)

then you get the IPE controls showing up over the image field and some of the IPE buttons generate errors:

merlinofchaos’s picture

populist: The patch in #18 to Panels should fix that, I think.

populist’s picture

I think the problem I am seeing with #27 is related to some wierd edge case with reattaching the JS when overriding a Panelizer default.

I did some digging and noticed that the wierd display of the page is because the page doesn't have the wrapper class "panels-ipe-editing" which adds the padding/borders. Since this is added in this.initEditing and depends on $('div#panels-ipe-display-' + cache_key), my guess is cache_key needs to be reset in cases where we go from Panelizer default -> overriden Page.

populist’s picture

Status:Needs work» Needs review
StatusFileSize
new1.79 KB

Fixed it! I updated the patch from #21 to set the cache key and success.

merlinofchaos’s picture

Status:Needs review» Fixed

Fixes applied to both Panels module and Panelizer module and pushed.

jeremiahtre.in’s picture

*Catches self, before falling over, in an utter, astounding manner*

Status:Fixed» Closed (fixed)

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