Panopoly Theme provides two things:
- A smattering of small theme customizations that really only make sense in the context of Panopoly, and
- A set of really awesome responsive Panels layouts.
I think it really makes sense for those two things to be seperated, since I think #2 would be very useful even outside of Panopoly.
Luckily for us, Radix Layouts includes all the same layouts as Panopoly, but is theme and distribution independent!
Here is what I'm proposing:
- Radix Layouts becomes a dependency of Panopoly Theme
- We turn all of Panopoly Theme's layouts into stubs that just call into Radix Layouts (to make it a seamless upgrade, no matter how the layout is specified: in code or overridden in the database)
- We put something in the release notes and contact all the child distributions based on Panopoly that we know, and tell them that the Panopoly layouts are deprecated in favor of the Radix Layouts
Later we can think about removing the old Panopoly layouts, but I'm not too worried about that. There will be no maintanence of them needed (because they are just stubs), CTools plugins are only loaded when used and the code weight will be minimal.
Do a quick test of every layout to check for regressions in the less commonly used ones Modify the "Panopoly Layouts" admin page from panopoly_admin to prevent the old Panopoly layouts from being re-enabled Update panopoly_theme.make to use radix_layouts 3.2 Add "(deprecated)" to the names of the old Panopoly layouts so that any other admin pages make it clear they are not to be used anymore