Posted by tim.plunkett on April 8, 2012 at 3:40am
18 followers
| Project: | Panels |
| Version: | 7.x-3.x-dev |
| Component: | In-Place Editor (IPE) |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Clean install of D7, panels, ctools. Enabled page_manager, panels, and panels_ipe.
I enabled the node view panel page, set up a variant for the article node type that comes with core, and added the node content to one pane.
Then from the node page itself, using the IPE, I added the field_image field to another pane, and hit save.
The page looses its content, the IPE bar at the bottom still shows. A regular refresh shows the content was changed correctly.
Nothing in watchdog, or JS console. Notices are set to display.
Comments
#1
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.
#2
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.
#3
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 that holds the node content looks like this before I click "Customize this page":
<div class="panels-ipe-portlet-content">After I have clicked "Customize this page" and saved, it becomes like this:
<div class="panels-ipe-portlet-content panels-ipe-empty-pane">Placeholder for empty ""Node being viewed" content"</div>I use Panels 7.x-3.2.
Anyone has some idea what this can be?
Thanks.
#4
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.
#5
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.
#6
I seem to be having this problem with version 7.x-3.2 as well.
#7
If people are seeing this with Panelizer enabled, then it sounds like it could be related to the issue mentioned above (#1572202: Panelizer default content and IPE, without page refresh panel is emptied on second save).
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:
<?php
// 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:
<?php// 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: Panelizer default content and IPE, without page refresh panel is emptied on second save rather than here.) But here's the patch in case people want to check if it fixes the issues they're seeing.
#8
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.
#9
Actually, I take it back; this is different than the issue I ran into myself. Even more fun!
#10
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: Panelizer default content and IPE, without page refresh panel is emptied on second save 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.
#11
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?
#12
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: Panelizer default content and IPE, without page refresh panel is emptied on second save.
#13
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.
#14
Automatically closed -- issue fixed for 2 weeks with no activity.