[wp-hackers] Grandchild themes

[Otto]

On Wed, Jun 8, 2011 at 1:12 AM, Mike Schinkel
<mikeschinkel at newclarity.net> wrote:
> 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.

Just thinking out loud here...

Ideally, it should be a fairly straightforward mechanical process to
turn a child theme into a non-child by simply combining it with its
parent theme. Off the top of my head, this should work for almost all
cases:

1. Copy all files except style.css and functions.php from child to
parent, overwriting any dupes.

2. Copy child's functions from functions.php into parent's
functions.php. If naming conflicts arise, child function wins. If
designed properly, child should have no naming conflicts (don't use
pluggable functions folks, they're evil. Filters and action hooks work
better).

3. Copy rules from style.css into parent. Dropping them at bottom of
style.css should work. Imports of other style files can be copied,
just not the import of the parent's style file.

That should work for pretty much any child theme, I'd think. Perhaps
there's a few edge cases I missed.

Note: A "framework" is not a separate entity, nor would I consider it
one. I'd distinguish between a "framework" being "a starting point to
build a theme on top of" vs. a "parent theme" which is a theme that
you want to use but make minor modifications to via a child theme.
Frameworks have themes built on them, but they don't have that done
via child themes. And "minor" modifications is obviously debatable, as
with CSS you can completely change the entire look and feel of a theme
without touching one line of PHP code.

Note that while we don't currently allow child themes in the extend
repository, that's certainly coming eventually, so it's something that
will have to be worked out. I would consider that a child theme which
is too "complex" being rejected or told to become a non-child theme.
Child themes, ideally, should only be limited to "minor" (there's that
word again) modifications. This leaves ample room for an end user to
modify and adjust them as needed. Child themes wouldn't be updated
often, unless the parent changed in a breaking way. That sort of
thing. And if that did happen, then the child should become a parent.

It would be an interesting challenge, BTW, for somebody to develop
code that converted a child into a parent automagically. :)

-Otto