Have Panopoly Theme depend on Radix Layouts (rather than providing it's own)

The radix layouts assume a bootstrap theme. Everyone else is going to be SOL. The reason for this are the layout .css files included with panopoly_theme. These handle very basic responsiveness for the panopoly_theme layouts. By removing them the pages start to break.

According to Arshad, Radix Layouts bundles the Bootstap grid css, so it should work without actually using a Bootstap based theme. Looking at the code, this at least appears to be the case:

http://cgit.drupalcode.org/radix_layouts/tree/radix_layouts.css

Is it possible the radix_layouts.css isn't being loaded with the way we're doing the stubs for panopoly_theme?

Anyway, because this grid CSS is bundled, nothing should break. If it does, it's a bug somewhere.

Whoa, that's no good! Layouts definitely need to be nestable. I don't recall this being an issue with Radix Layouts 2.x, which I've tested in the past. It might be worth looking at what else is different between 2.x and 3.x (besides just the Boostrap version). But this does seem like a bug in radix_layouts.

@cashbre: Thanks for doing that testing and making the side-by-side screenshot, that's awesome!

Thanks, @arshadcn!

We're also going to need to remove the templates and CSS for the old layouts in panopoly_theme. @caschbre: You had some code for this working a couple months ago, right? I remember discussing it on IRC. It'd be great if you could update @arshadcn's patch to include that as well.

Actually, if you can just post what you had from before (even if its incomplete), we'll be sprinting all day tomorrow and can try to finish it up!

Sweet, thanks! I'm working on the rest of the panopoly_theme changes to turn the old Panopoly layouts into stubs and hide them from the user. I should have a patch to post for testing soon.

Ok! Here is my first pass at clearing out panopoly_theme and making the old layouts be stubs to the Radix layouts by default (even without the hook_ctools_plugin_post_alter() in radix_layouts).

Still TODO:

• Fix the styling when looking at the Radix layouts in the change layout dialog to match the way the Panopoly ones currently look
• Hiding the "Panopoly" category of layouts from the user so the Panopoly layouts are just there to provide backcompat
• Add a hook_update_N() to get radix_layouts enabled on old sites

I'm going to try and get both those things done today so we can test this at the sprint today!

Ok! Here are patches to panopoly_theme, panopoly_magic and panopoly_core to do the full set of changes. I haven't completely tested them, but I want to post them here so I can try on Travis-CI before doing too much manual testing.

I then did something (don't remember what) that kept the panopoly_theme layouts from being enabled again.

This sounds really interesting! I think we should do it. If you have any ideas on how you did that, that'd be great. Might be a patch to panopoly_admin because that's what provides the enable/disable layouts page.

The issue with Responsive Bartik is that it assumes a #main that is wider than .container. And every theme that does that might require small css fixes. But other than that radix_layouts should work with most custom themes.

Hrm. Well, we need Responsive Bartik to look right. Is there something we can put into panopoly_theme to fix this?

So, I ran the automated tests with the patches on this issue and got a bunch of failures:

https://travis-ci.org/dsnopek/panopoly/jobs/40349218

Basically, we depend on the regions having layout specific CSS classes like "bryant-sidebar". We might be able to work around this using the generic CSS names that are in there (like "sidebar" and "content") but I haven't tried it yet.

Ok, here is a patch that should fix the tests! Turned out to be way simpler than I thought it would. :-)

Here is a couple new iterations on the patches here. I decided to actually pull the CSS that modifies the way the Radix layouts look out of panopoly_magic and moved it into panopoly_theme, since those layouts come from panopoly_theme. Also, I had to add some CSS to undo some styling that Bartik and Responsive Bartik put on the ".sidebar" class which radix_layouts uses.

All that we need now is:

1. A new version of radix_layouts which fixes #2334871: Radix Layouts breaks Panopoly for nested panels (e.g. teaser lists)
2. More testing of these patches by people wo are not me :-)

Thanks, @arshadcn!

At BADCamp earlier today @cboyden got these patches setup on her dev site and we walked through it and it was working for her. In talking through it, I realized that we also need to update panopoly_pages to directly using the Radix Layouts, rather than depending on the stubs forwarding from the Panopoly layouts to the Radix ones. I'd also like to quickly do manual testing of each of the layouts just to double check that there are no regressions. I'll try to get this done at the airport right now, but no promises. :-)

While testing I found weird styling issue with the "Add" button on the "Add content" dialog:

A change is probably necessary to some CSS in panopoly_magic...

Here are some updated patches! For panopoly_pages and panopoly_demo, it's switching to using the Radix layouts directly rather than the stubs in panopoly_theme. For panopoly_theme, I fixed an issue with the size of the layout icons on the change layout dialog. I still haven't figured out the issue in #35.

Looked through comments and my notes to add a "Remaining TODO" section to the issue summary. We're super close! I'll try to update the patches today, and then poke some people for additional help testing. :-)

Here are some updated patches! I've checked off the things in the issue summary that this fixes.

I also dug into the weird styling issue with the "Add" button on the "Add Content" dialog from comment #35. This is caused by Bootstrap making everything into box-sizing: border-box. Also found a number of other little styling issues connected to this change in the "Add Content" dialog: (a) fieldset/legend doesn't line up the way it should, (b) the scrollbar in the dialog isn't flush with the right side of the dialog.

We can definitely update our CSS to take this into account, but I'm a little worried about the affect this could have on unsuspecting themes. If someone has a theme that's coded with box-sizing: content-box in mind, and then we just switch every element to border-box it could create problems... I'm not sure what to do about it at this point, I'll need to think more on it.

EDIT: My original (a) above was a red herring - replaced it with a real issue...

I've added an issue to radix_layouts to try and figure out what to do about the box-sizing: border-box problem: #2373565: Restrict box-sizing changes to just the layout classes?

I'd love some input there!

I started going through each layout one-by-one, to try and find any regressions or issues. Unfortunately, I did find a couple little things:

1. #2374625: radix_sanderson and radix_sanderson_flipped have the same icon!
2. #2374631: radix_webb and radix_webb_flipped are reversed!
3. On radix_taylor and radix_taylor_flipped in responsive_bartik, the "Half Column" region has some unexpected bottom margin. I think this is responsive_bartik applying special styling to the ".content" class. This should probably be fixed in panopoly_theme, along with the other bartik fixes. (Note: I've since found more layouts this affects, like radix_harris - but those two example are enough to dig into the problem)

So, I've updated the list of TODO to cover these remaining things! If anyone else has the time to run through all the layouts and check them, it would be much appreciated, since I only had time to do it relatively quickly.

Hmm. I thought more about point (3) above in #43 and I think it would be best to try and fix that problem in radix_layouts, so I opened a new issue there: #2374637: Prefix classes with commonly used names, like content, sidebar, header, footer?

I appreciate input on that one, because I'm not totally sure about it!

@arshadcn: Thanks so much! Sorry, I got busy on Friday and then was away from the internet all weekend. I'm going to look at this now!

Woohoo! Everything looks great. :-) I'm uploading one last patch which removes some responsive_bartik hacks that are no longer necessary (since Arshad committed #2374637: Prefix classes with commonly used names, like content, sidebar, header, footer?) and updates to the latest radix_layouts.

I'm going to run this all through the tests on Travis-CI one last time (hence why the patch uses radix_layouts from Git) and assuming that's good, I'll finally commit this once Arshad does the radix_layouts 3.3 release!

Thanks again to everyone who helped working on this and testing, and especially to Arshad for all his hard work on radix and radix_layouts!

Well, it's good I decided to try with Travis-CI, because I need to update the panopoly_test patch and I found some minor CSS class name inconsistencies in radix_layouts. The new panopoly_test patch is attached and here is an issue for the radix_layouts: #2376635: Minor class name inconsistencies

Here's the next Travis-CI build:

https://travis-ci.org/dsnopek/panopoly/builds/41252637

Alright! Travis came back and everything is now looking good. So, all that we need now is #2376635: Minor class name inconsistencies to committed and radix_layouts 3.3 to be released. :-)

Committed! Huzzah! Thanks again everyone. :-)

Just in case, here is the Travis-CI build for the final committed version (which I did modify a little on commit - mostly switching layouts to the radix version, which I missed on my last pass through):

https://travis-ci.org/panopoly/panopoly/builds/41297212

I'll see you all over in #1987386: Include Radix theme in Panopoly ;-)