[wp-hackers] Grandchild themes

[Eric Mann]

Really it all comes down to a matter of preference.  Justin totally sold me
on *not* using "grandchild" themes quite a while ago.  But I still like the
Genesis model of using an advanced theme as the parent and building a child
theme based off it.  If StudioPress was pushing out rapid updates to their
child themes I'd be more concerned about that model, but I typically use one
of their themes as a base and build off it (with a different name so clients
don't accidentally break things *if* an update does come out).

A while ago I was a fervent advocate for grandchild themes.  I even started
putting together a patch for WP to allow it.  It wasn't until I got deep
into things that I realized just how bad of an idea it was.

Firstly, if we allow grandchild themes, why not great-grandchild themes?
 Once grandchild themes are on the table, you have to either limit it
somewhere or not limit it at all.  And once you allow for more than just a
parent-child relationship you run into other issues.

Say there's a bug on an archive page.  Is it caused by your grandchild
theme?  By the child theme?  By the parent theme?  By the framework that
ships with the parent theme?  Tracking down issues when multiple developers
and multiple development patterns are involved isn't just hard, it's nearly
impossible in some cases.

You also are stuck maintaining several separate systems on the site.  Rather
than just a theme, you have a theme, it's parent, and it's grandparent.  If
a client (user, paying customer, yourself) accidentally deletes or breaks an
ancestor of the active theme, you have problems.  On multi-user sites this
introduces a lot of potential instabilities into the system.

Finally comes distribution.  Right now, people are distributing both parent
themes and child themes.  If grandchild themes were allowed, I could see
people distributing those as well.  Imagine the confusion from an end-user
perspective if they were to purchase (or receive for free) a theme that
depends on another theme that depends on another theme that depends on
Genesis.

So while on the one hand I agree that it would be convenient to allow
grandchild themes, it would also introduce a whole slew of potential
nightmares that I doubt any of us would want to deal with.

Also, your proposed workflow of modifying a Genesis-based child theme
*isn't* going against best practices.  As Nathan pointed out, they're rarely
(if ever) updated and are mostly stylistic modifications of Genesis.  Think
of the child themes StudioPress sells more like starting points for your own
projects than standalone products.

On Tue, Jun 7, 2011 at 2:09 PM, Nathan Rice <ncrice at gmail.com> wrote:

> Mike,
> 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.
>
> 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.
>
> 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.
>
> Justin,
> We seriously considered this as a possible COA for Genesis, but decided
> against it for the reasons I stated above.
>
> ------------------
> Nathan Rice
> WordPress and Web Development
> www.nathanrice.net | twitter.com/nathanrice
>
>
> On Tue, Jun 7, 2011 at 3:09 PM, Mike Schinkel
> <mikeschinkel at newclarity.net>wrote:
>
> > On Jun 7, 2011, at 8:40 AM, Nathan Rice wrote:
> > > I can't speak for other companies, but we at StudioPress rarely update
> > child
> > > themes, and never really recommend you "upgrade" them. Genesis is the
> > > framework, and you're never supposed to edit that. But child themes are
> > > meant to be edited. Usually, child themes are very simple, mostly just
> > CSS
> > > tweaks, and the registration of a few widget areas, etc. There are
> > > exceptions, and we're working on a solution for those, but for the most
> > > part, you're safe just editing the child theme directly.
> >
> > Something to consider: we decided against actively using Genesis because
> of
> > this issue.
> >
> > I view it as a best practice not to modify other's packaged code (themes,
> > plugins, core, etc..) Further, modifying a child theme means that we
> can't
> > see our isolated changes separate from the shipped child theme.
> >
> > Because of these issues we decided we can't use Genesis. Instead we use
> > other themes where we can create a child theme of our own.
> >
> > Take that as one market research data point. FWIW.
> >
> > -Mike
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>