[wp-hackers] Grandchild themes

[Mike Schinkel]

On Jun 7, 2011, at 5:09 PM, Nathan Rice wrote:
> If you feel like you have to segregate your mods, doing so is pretty simple
> with the CSS @import and PHP include/require methods. You can be quite sure
> that we're not going to be overwriting your entire child theme via an
> automatic update of any sort.

My preference is not to modify other's plugin or theme code unless absolutely not an option not too.  Modifying code breaks my development processes and my workflow that treat external versioned bits of code as sacred. I'm actually backing that "sacred" aspect into my automated processes.

But please just take my input as one data point, I may be the only one that thinks this way.  Or maybe there are many others who think the same way (although probably not many on this list) and if so you are eliminating those prospects as customers simply by your choice of architecture.  But yes, all things are trade-offs.

> What we NEVER want to do is be in the business of making those methods the
> *standard* mode of modification. In our experience, abstracting the majority
> of functionality and standard output into the parent theme, and leaving the
> child theme to modify and style that output has been a near perfect balance
> for our users. They feel like they're getting the benefits of a solid parent
> (Genesis) with the ease of modification that comes with a more traditional
> theme.

FWIW, I think that probably works really well for the segment of the market that selects themes for their own use or for the use of small budget projects. It probably does not work as well for larger budget projects where agencies are called in to build sites for larger organizations. Maybe the market you are serving is where you'll make the most money? (And I can't pretend to know what's best for your business.) 

But for my use-case where I use version control to manage projects and I segment my code from others it doesn't work. I only mention it as a data point for theming companies to consider.

> I was convinced that users would have a hard time with the Genesis concept,
> but to my surprise, we've evidently stumbled on something that users really
> love. My guess is that grandchild themes, or any attempt to synthesize that
> concept, would disturb the balance of an otherwise extremely popular
> methodology.

What makes more sense to me would be to package a Genesis Framework with each of what you currently call Child Themes thus letting me create child themes from them.  Much like what Justin Tadlock wrote:

http://justintadlock.com/archives/2010/08/16/frameworks-parent-child-and-grandchild-themes

A theme could even "bootstrap" the framework into a shared location so that multiple framework-dependent themes could be installed and share the one framework.  But, that's just my two cents and since I'm not running StudioPress I understand that these ideas probably won't make it into your products, but maybe others who write theme frameworks will try them? FWIW.

-Mike