Saving a change in the IPE results in a blank page, fine after refresh, no error

Yes I have the same problem. Even if you dont add any content and plainly hit the "save" button, the ajax causes everything to go blank. I am using 7.x 3.2 version and not the dev.

Ok let me clarify a bit on my comment.

If you add any custom content from IPE, then everything is fine. However as you start adding things like fields, comments etc then you see these things getting disappeared after hitting "save" button. The custom content remains untouched, but everything else disappears. I hope I am clear.

Yes, I have the same problem.
I have activated the "node_view" page. When I select "Customize this page" and then hit "save" the node content disappears.
The

I was having the same issue until I upgraded everything to the latest dev.
ctools 7.x-1.0+22-dev (2012-May-21)
Panels 7.x-3.2+5-dev (2012-Apr-23)
I'm having a similar issue where panes are also going away but hitting refresh before edit fixes them. If I do not hit refresh before editing I also see the place holder text for an empty pane. Hitting save will totally remove those and a refresh wont bring them back. I explained more in detail on this post http://drupal.org/node/1572202#comment-6025588 which I think is related.

I think it has something to do with the panes refreshing / loading and because the url is different sometimes they dont get the correct information. Maybe something to do with context? Thats all over my head.
For example a views pane with a contextual filter set to the current NID using 'Provide default value': 'Content ID from URL' . This renders fine when viewing the node, but when your in the IPE it looks fine but when hitting save it goes away. I used dpm to see what was being passed to the contextual filter and it was blank after saving from IPE. Hitting refresh brought it back.

This is weird.

The problem looks like it's not translating temporary IDs to permanent IDs upon save. But it's supposed to be. I'll have to dig into this more deeply.

I seem to be having this problem with version 7.x-3.2 as well.

If people are seeing this with Panelizer enabled, then it sounds like it could be related to the issue mentioned above (#1572202: IPE changes aren't shown after second save without page refresh).

I was seeing something like that and debugged it for a while. Basically the issue turned out to be that for a newly-created panelized node, depending on your IPE configuration it is possible to have the node created (and ready to be used with the IPE) but without a record having been created in the {panelizer_entity} table yet (or without a complete record having been created).

When that happens and you click the "Save" button in the IPE, Panelizer's hook_entity_update() implementation will wind up saving the Panels display without modifying the entity itself to reflect that, but rather only modifying a cloned copy. It happens via this code in Panelizer:

      // If this is a new entry or the entry is using a display from a default,
      // clone the display.
      if (!$update || empty($entity->panelizer->did)) {
        $panelizer = $this->clone_panelizer($entity->panelizer, $entity);
      }
      else {
        $panelizer = $entity->panelizer;
      }

       // The code below this modifies $panelizer to have the new displays...

Ultimately, through a complex series of objects which reference each other, this means that the IPE display object doesn't get updated either, i.e. in this code in Panels:

    // Otherwise it was submitted.
    if (!empty($form_state['clicked_button']['#save-display'])) {
      // Saved. Save the cache.
      panels_edit_cache_save($this->cache);
      // A rerender should fix IDs on added panes as well as ensure style changes are
      // rendered.
      $this->meta_location = 'inline';
      $this->commands[] = ajax_command_replace("#panels-ipe-display-{$this->clean_key}", panels_render_display($this->display, $this));
    }

When panels_edit_cache_save() is called above (ultimately triggering Panelizer's hook_entity_update()), $this->display is never updated to reflect the new state of the system, and thus it gets returned to the client side without the new pane ID, ultimately leading to the disappearing content.

The attached Panels patch fixes the issue for me, though I'm not really convinced it's the right solution. (I looked for a solution inside Panelizer, but couldn't find a way to do it that didn't break other things; however, it's possible this is actually a Panelizer bug and should be fixed in #1572202: IPE changes aren't shown after second save without page refresh rather than here.) But here's the patch in case people want to check if it fixes the issues they're seeing.

Hm. I happened across this one yesterday as well. Thanks for the patch, David, this at least gives me a place to start in figuring this one out.

Upgrading to major, this is a pretty big flaw. My suspicion is that is indeed a bug in Panels, not Panelizer, but I will just have to step through and see what's getting lost to be sure.

Actually, I take it back; this is different than the issue I ran into myself. Even more fun!

For example a views pane with a contextual filter set to the current NID using 'Provide default value': 'Content ID from URL'

The problem here is that when it rerenders, that information (the content ID from the URL) isn't actually available. And there's no way to get that information to the pane, so I don't think that's even going to be fixable.

After some research, there are two separate problems here.

1) The one I saw yesterday is similar to what was reported here. After a save, the IPE forces a complete rerender. However, arguments are lost, so context derived from arguments revert to placeholder values. This is probably fixable, but I have to figure out how to preserve the argument information. However, as said above, I don't think there's anything I can do about things that acquire information directly from the URL. The workaround would be to try and acquire that information from context instead, but I realize that's not always possible.

2) What David Rothstein identified involves some pane IDs getting lost. However, I'm unable to duplicate that in a quick test (3 successive saves without reloads successfully added panes). 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. To that end I have an experimental patch that may fix it. Since that is a panelizer patch I'll post it in #1572202: IPE changes aren't shown after second save without page refresh and work that there.

Moving back to active; the NR patch here is probably not a true fix, and I'm handling that issue back in 1572202 anyhow, for now at least.

After a save, the IPE forces a complete rerender. However, arguments are lost, so context derived from arguments revert to placeholder values. This is probably fixable, but I have to figure out how to preserve the argument information. However, as said above, I don't think there's anything I can do about things that acquire information directly from the URL.

See also #1621014-1: Contextual links and other JavaScript behaviors on panes don't work after clicking "Cancel" in IPE and subsequent comments, which appears to report something pretty similar. (That's another issue which, like this one, is about two different bugs that are easy to confuse because they have similar symptoms - maybe we need to do a bit of issue queue cleanup).

As I suggested there, would it be possible to fix these URL-related issues by faking $_GET['q'] when Ajax requests are made for the pane content?

For item #1 in #10 above, I'll be handling that in #1772834: Panels IPE Save Drops Context Specified in Page Manager which should have a patch shortly.

#2 will be handled in #1572202: IPE changes aren't shown after second save without page refresh.

Both of the items in #12 are fixed -- is there anything left in this issue? I don't believe so, but feel free to re-open if I'm wrong.

is this not the same issue as this: #2092447: ipe requires page refresh to properly show flexible layouts - which still exists with latest -devs of panels/ctools.

Please don't reopen an issue just to ask if it's the same as something else. Thank you, though.

Damien, that was just how i word things.. i am pretty sure it is the same issue and therefore it is silly to open a new issue when this one is not closed. opening a new one loses the history of what has been done to date on the issue.

so basically get shit for re-opening and get shit for creating duplicates.. nice.. lol

but that's cool. i'll leave this closed if you guys aren't interested in getting this fixed.

liquidcms: There's no reason to take an attitude. If the problem still exists then sure, reopening it is fine, but also then close the other one so there's only one issue per topic.

From liquidcms in #2092447: ipe requires page refresh to properly show flexible layouts:

before i describe the issue a couple qualifications.
- i am not sure if this is specifically related to flexible layouts
- not sure if this would be considered a bug; it may just be a known limitation

- i have created a couple layouts using the panels add flexible layout
- i have assigned these to a category: Home
- all layouts have multiple columns

when i am using the IPE to switch layouts; when first selecting new layout the regions all display in a single column:
- actual layout: http://screencast.com/t/58YUiR80P7m
- selecting in ipe: http://screencast.com/t/Nbx9ddyL2g

and then once the new layout has been selected and i immediately open the customize this page editor, the layout is still displayed as a single column: http://screencast.com/t/Y8adsAxFCYEN

when the content choices are saved; still appears as single column: http://screencast.com/t/W3GFOfSsu

but on page refresh, the correct layout is shown:
- http://screencast.com/t/xE98NXLvphK3
- http://screencast.com/t/7lTjx5dpBFW

in contrast to this issue; the "fixed" (i guess hard coded?) layouts that are built in to Panopoly do not have this issue.

Tagging for easy reference.

I've got this issue currently, with latest versions of everything and it's definitely not fixed. To clarify, I have to reload the entire page after every IPE save to see the content.

See #2824874-2: Fake path for better context when rendering panes with IPE which fakes the path to provide better context when rendering panes.