Needs work
Project:
Panopoly
Version:
7.x-1.x-dev
Component:
Magic
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 May 2014 at 14:20 UTC
Updated:
17 Dec 2014 at 02:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mcrittenden commented+1 for making this an option. The panopoly_admin settings page seems like a good fit (and I guess panopoly_magic would work too, especially since that's where the CSS currently lives).
Comment #2
dsnopekYeah, I agree, this is a super useful feature and I'd love to get it back. :-)
It was removed from Panopoly in 1.0-rc5. Unfortunately, I haven't been able to track down the issue. Here's the commit that did it:
http://cgit.drupalcode.org/panopoly_magic/commit/?id=7dc1a5e7fd93dfc584a...
However, the issue number in the commit message is wrong. :-/
If anyone can find the original issue, it'd be great to see what the problems were that prompted it's removal!
Comment #3
mglamanNo idea what this is from, but Google found this: https://drupal.org/files/issues/auto_complete_and-2231879-1.patch & https://drupal.org/files/issues/auto_complete_and-2231879-2.patch
Which led me to: #2231879: Auto complete and throbbers for AJAX elements
So Kalatheme had it originally, looks like maybe ported from there directly into Panopoly?
Bing was useless, as was DuckDuckGo, Google has 4 results with "Remove the Save as Default Option"
Comment #4
mglamanWell, here's a patch to get it back in, pretty useful piece of Panelizer.
Comment #5
mpotter commentedI believe one of the reasons it was removed is because it didn't actually work correctly. Panelizer supports having multiple layouts for a node/content type. This gives a "list" option in Panelizer where you can add different layouts that can be selected for the node.
The "Save as Default" (if I remember correctly) always overwrites the *Default* layout, rather than the layout specifically selected for the node. So using the Save As Default can have huge unintended side-effects of overwriting the default layout, which isn't actually the layout being used/modified on the node.
The same problem actually happens with the "Revert to default" button. It reverts to the default layout, rather than the originally selected layout. But this is less of a problem because it's easy to just edit the node and reset the layout back to the original.
But when Save As Default is used and overwrites the default, there is no way to go back or undo this change. It can essentially break the entire site requiring a database restore. Until this can be fixed in Panelizer, I recommend leaving this button disabled, or at least add an option to Panopoly to hide/show this button, or assign it a different permission.
If this issue has been fixed in Panelizer recently, then let me know and I'll review it.
Comment #6
dsnopekAha, thanks for the insight, Mike!
Even if the problems with Panelizer aren't fixed, we could make this a configurable option because some sites don't use multiple Panelizer defaults, so it's a risk they could choose to take.
But, yeah, ideally, it'd be great if any problems were fixed in Panelizer because this is really cool functionality.
Comment #7
mglaman+1 on making it a button. I can see where this can cause headaches -- too bad there isn't page display revisions. Also, if the button is missing and note used some people may forget it exists and try to improve its functionality.
Comment #8
caschbre commentedI like the idea of making it a configuration option. Default it to not enabled to avoid folks accidentally using it the wrong way. And then add a big red flashing warning next to the checkbox that enables it describing exactly what it does.
Comment #9
mglamanGiven the above statements, moving this to "Needs Work" so we can work on a setting and/or review how this feature is working now.
Comment #10
mglamanThere is now a patch in the Panelizer queue that fixes the Save Default functionality (at least in my tests.) #2328615: \PanelizerEntityDefault get_default_panelizer_object() method returns null when config exported.
Comment #11
mglamanHere is a Panopoly Core patch to patch Panelizer with fix mentioned in #2328615: \PanelizerEntityDefault get_default_panelizer_object() method returns null when config exported., which should allow us to remove the CSS hiding save default :).
Note: Need both patches in order to test functionality.
Comment #12
mglamanThe above patch fixes the fact Save Default wasn't working in 3.1, however realized it doesn't resolve mpotters concern. If the Panelizer is exported to code there is no problem (component can be reverted), however if the Panelizer is not in code it will be forever lost.
Comment #13
damienmckennaI've committed mglaman's patch in #2328615: \PanelizerEntityDefault get_default_panelizer_object() method returns null when config exported..
PS, if you uncover other bugs in Panelizer that are affecting Panopoly, please open an issue in Panelizer's queue (maybe tag them "Panopoly" so they can be more easily found?) and I'll work on it.
Comment #14
dsnopekThanks, Damien! We'll try to remember to tag as "Panopoly" in the future. :-)
Comment #15
mglamanReferencing #2354437: New revisions should always clone a custom display as this may be a step towards fixing mpotter's concerns.
Comment #16
mglamanHiding patch from #11 as it's now in its own issue #2374941: Patch Panelizer to fix exported configurations and "save as default."
Comment #17
PI_Ron commentedBrilliant. Thanks for this massive usability improvement.