Parent / Child theme structure

[Toddses]

Currently the theme is meant to be a parent theme and hacked away from there, turning features on and off. I think we're going to run into a lot of issues trying to turn it into a parent theme that's meant to have a child theme built around it.

• features can't be easily turned off anymore
• we'll lose the gumby settings file, which is key to the framework customization
• we'll no longer be compiling the gumby sass into the styles.css
• because of that it will no longer be feasible to include gumby extensions by way of bower

I wouldn't want to say, start your project out by copying these files into your child theme. At that point it may as well be a standard theme.

tl;dr without some major refactoring, this theme will just not work in a parent / child structure.

[Toddses]

I opened this issue to discuss how we can potentially refactor to make child themes feasible.

[edheltzel]

Yeah I agree... we'll probably need to create another fork for the parent/child use-case. Maybe we create our BAMF theme that does a 101 things.

[Toddses]

To be honest I'm not even sure its a viable use case. Gumby is meant to be customized, extensions enabled and disabled on a per project basis. If we precompile gumby we lose out on the built in customizations and the ease of including extensions.

[Toddses]

That might be a better use case for a precompiled gumby. Build out an options framework for a BAMF theme.

[edheltzel]

agreed. We'll need to create a new milestone for that and figure out how we want to move forward.