Hi,

I have a panel with visibility rules set for which node/view to display based on the url. I just noticed today that using ipe to edit the shared header text is causing all other views/nodes (besides the one being displayed while editing) to be deleted from the panel content settings.

I've come up with a workaround, but this is a major problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tustind’s picture

Second this... @eatsleepdev, what's your workaround?

eatsleepdev’s picture

@tustind,

The main reason I wanted to use visibility rules was so I could share a block of text across multiple pages. So instead, I added the text to one page and pulled it into the other nodes with some code that looks like this:

Load the node and panel content

	$panel = node_load('2502');
	$display = panels_load_display($panel->panels_node['did']);

Display the content. This content number is something you can get with print_r($display) (maybe theres a better way to get this number that I didn't realize)

	$display->content['108']->configuration['body'];
jumidi’s picture

Status: Needs review » Active
FileSize
2.16 KB

Hi.

This patch fixes the bug. It prints all the "panes" even when they are not visible, but it marks them with other classes in order to show them with other appearance. Only users that have permissions to use "in place editor" can view those hidden panes.

TODO: use javascript to show-hide the marked (class="hidipe") panes.

jumidi’s picture

Status: Active » Needs review
sdboyer’s picture

Assigned: Unassigned » sdboyer
Priority: Major » Critical
Status: Active » Needs work

oh. wow. this totally didn't occur to me when i wrote IPE. maaaajor problem. sorry it's taken so long to get to this. adding it to my plate now.

and, sorry, but #3 is not an acceptable solution, as including all rendered HTML is a potential security issue. even if it's not immediately visible, the content is still totally accessible. the approach i'll need to take is injecting the data for the panes into the form without ever showing them on the frontend, then doing some magic with positioning around invisible items.

overtune’s picture

Is there any progress on this issue?
Let me know if it's needs testing or something...

Elvar’s picture

Version: 6.x-3.9 » 7.x-3.3
Status: Needs work » Needs review
FileSize
2.31 KB

I have rerolled jumidi patch against 3.3, for those who desperately need it. :-)

joel_osc’s picture

Just wondering if the posted patch is 'acceptable' or is more work being done on this. If more work is being done then the status of this should likely be changed.

kasperg’s picture

Status: Needs review » Needs work

As sdboyer stated in #5 the posted patches are not acceptable solutions - rerolled or not. Reverting to needs work.

merlinofchaos’s picture

Status: Needs work » Needs review
FileSize
1.72 KB

Here is an acceptable alternative.

beeradb’s picture

Status: Needs review » Reviewed & tested by the community

I tested this with the latest build of Panopoly and it looks good. I was able to verify the pane deletion before the patch, and post-patch I see the empty placeholder for the pane in the IPE and the pane is retained after saving.

Marking RTBC.

Taxoman’s picture

Version: 7.x-3.3 » 7.x-3.x-dev
Status: Reviewed & tested by the community » Needs review

Such a serious issue needs more reviews.

sylus’s picture

Works for me as well ^_^

mgifford’s picture

The patch applies nicely to the git repo. I don't know panels well enough yet to effectively test this though.

Would be great to get this into dev.

populist’s picture

Status: Needs review » Reviewed & tested by the community

This also works for me and marking RTBC since we have a few different people reviewing which hopefully addresses the concerns in #12. Data loss is no good and would love to see this rolled in soon.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)
Issue tags: -ipe, -dataloss

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