Child Themes And Theme Frameworks

[chipbennett]

It doesn't matter how they distribute it really, the problem is that as long as the current theme infrastructure remains the same, and theme frameworks 'hog' the primary theme slot, then it never going to be ideal.

Still, nothing is set in stone, and I am sure that WordPress will evolve to address these issues.

Ah, but it *does* matter. The issue is getting rid of the "Generic" Theme that ships with the Framework core.

Look at StudioPress' Themes: they sell the Genesis Framework (presumably with a Generic Parent Theme), and then sell the real design work as gorgeous Child Themes of the "Generic" Parent Theme that uses the Genesis Framework.

What they should instead do is de-couple the Genesis Framework from the "Generic" Parent Theme, and then drop that "Generic" Parent Theme entirely.

Simply sell the Genesis Framework by itself, and then sell what are currently "Child" Themes instead as Parent Themes.

That's all that's really required.

[dgwyer]

As long as peops can modify/extend themes without having to alter original theme code, that could be updated at some point, then everyone will be happy.

[andreasnrb]

The elastic guys started calling their stuff template engine instead instead because of the whole theme framework dilution. I've on numeroues occassions expressed my utter distaste for how many wp devs have approached the theme framework concept.
Theme frameworks ought to be plugins or a dropin in a themes folder. My AoiSora plugin takes thats approach when it comes to plugins and eventually themes will probably be a template engine. Its a plugin framework that can be updated independently. Its the bases of a number of my plugins and other PHP related projects. DRY.

Perhaps there should be some information on the subject of complex parent themes (frameworks) in the Codex and things to take into consideration when using them? The nbr of complex parent themes seems to be increasing. Everyone seems to want to make one.

[andrea_r]

Look at StudioPress' Themes: they sell the Genesis Framework (presumably with a Generic Parent Theme), and then sell the real design work as gorgeous Child Themes of the "Generic" Parent Theme that uses the Genesis Framework.

What they should instead do is de-couple the Genesis Framework from the "Generic" Parent Theme, and then drop that "Generic" Parent Theme entirely.

They sell the theme framework and it comes with an *example* child theme. Not a parent theme. You can get Genesis and create a child theme, or alter an exisiting one right out of the box.

It's not a framework in the same way that Hybrid is a framework. Genesis *is* the parent theme.

Child themes don't really get a lot (if any) updates, and Brian's moving most alterations into either options or thru the use of code in functions.php or via the Simple Hooks plugins. For a good 80% of the users, that's all that is needed. A new version of Genesis comes up, everyone upgrades, theme changes stay.

[chipbennett]

They sell the theme framework and it comes with an *example* child theme. Not a parent theme. You can get Genesis and create a child theme, or alter an exisiting one right out of the box.

It's not a framework in the same way that Hybrid is a framework. Genesis *is* the parent theme.

Fullstop.

This is the problem, with respect to intended use of Child Themes.

Child themes don't really get a lot (if any) updates, and Brian's moving most alterations into either options or thru the use of code in functions.php or via the Simple Hooks plugins. For a good 80% of the users, that's all that is needed. A new version of Genesis comes up, everyone upgrades, theme changes stay.

The whole point of Child Themes is to enable the end user a way to modify a distributed Theme in a way that allows those customizations not to be impacted by changes to the distributed Theme.

So, while what StudioPress is doing is a fantastic solution for his many happy customers (and more power to them in that regard!), it is still a mis-use of the Child-Theme concept. If it works for Brian and his customers: great. He shouldn't change a thing. But if his users want to be able to take advantage of Child Theming in order to have upgrade-proof modifications to Brian's Themes, they're simply out of luck.

[wpmuguru]

But if his users want to be able to take advantage of Child Theming in order to have upgrade-proof modifications to Brian's Themes, they're simply out of luck.

The point that you are missing in what Andrea said is that the child themes are rarely updated. What is updated on a regular basis is Genesis. Genesis is the layer between the child theme and WordPress. So, when WordPress 3.1 is released, Genesis will be updated, not the child themes. A good theme framework is like the hardware abstraction layer in an OS. You don't have to update your applications every time a new piece of hardware comes out. That update is done in the OS.

From an architectural standpoint, you can do it either way (framework part of the parent theme or separate from same) but saying one is the right way and the other is the wrong way is only a personal preference. Justin Tadlock explained why he did the Hybrid framework the way he did and for the goal he had in mind I completely agree that he did it the right way. But there is no advantage to doing it that way for a commercial theme business. If someone is using the same parent theme for all the child themes and have a separate framework, then they have two software products to maintain/update instead of just one (which is a distinct disadvantage).

[chipbennett]

The point that you are missing in what Andrea said is that the child themes are rarely updated. What is updated on a regular basis is Genesis.

Oh, I'm not missing that point at all. I understand it entirely - just as I understand that his customers are happy with this implementation. (And, in the end, that's all that's really important.)

My counter-point is that this implementation is contrary to the intended use of Child Themes, which is to enable end users a means to create update-proof Theme modifications.

Genesis is the layer between the child theme and WordPress. So, when WordPress 3.1 is released, Genesis will be updated, not the child themes. A good theme framework is like the hardware abstraction layer in an OS. You don't have to update your applications every time a new piece of hardware comes out. That update is done in the OS.

And how then do end users who want to implement update-proof modifications to their Themes do so?

They can't.

From an architectural standpoint, you can do it either way (framework part of the parent theme or separate from same) but saying one is the right way and the other is the wrong way is only a personal preference. Justin Tadlock explained why he did the Hybrid framework the way he did and for the goal he had in mind I completely agree that he did it the right way. But there is no advantage to doing it that way for a commercial theme business. If someone is using the same parent theme for all the child themes and have a separate framework, then they have two software products to maintain/update instead of just one (which is a distinct disadvantage).

I don't see how it's any different whatsoever. Regardless of how often the Genesis Framework might get updated, AgentPress, Church, and Mocha don't necessarily have to get updated any more or less frequently whether they are a Child Theme or a Parent Theme.

But again, my point isn't whether one method is better or worse from a business-model perspective, but rather that what is being done currently is contrary to the intended use of Child Themes, which (again) was to give end users a means to modify their Themes in a way that preserves their modifications when the Parent Theme is updated.

Again, it doesn't make one method right or wrong.

Clearly, Brian has found an ample market of users who are not concerned with update-proof modifications to their Themes. And that's awesome. Any time a business model finds a match with an unmet need, everyone wins.

Perhaps I should have prefaced my previous comments with: if Commercial Theme Developers want to ensure that end users retain the ability to modify their Themes in an update-proof manner.

If Commercial Theme Developers don't have that objective, and their customers don't have that objective, then none of what I said matters. :)

[Ryan]

The point of Genesis (I assume) is to ensure that Child themes don't need to be updated. So it indirectly does achieve the goal of making the users modifications upgrade-proof (or at least to a point).

[chipbennett]

The point of Genesis (I assume) is to ensure that Child themes don't need to be updated. So it indirectly does achieve the goal of making the users modifications upgrade-proof (or at least to a point).

Er, huh? It doesn't make much sense to say that removing the ability for users to make ugrade-proof modifications achieves the goal of making user modifications upgrade-proof.

I think the more accurate way to say that is that the point of Genesis is to replace/eliminate the need for user modifications.

And that's all good. After all, Genesis has some absolutely gorgeous Child Themes.

[wpmuguru]

Er, huh? It doesn't make much sense to say that removing the ability for users to make ugrade-proof modifications achieves the goal of making user modifications upgrade-proof.

Chip, no one (other than you) said that Genesis removed the ability for users to make upgrade proof child themes.

You have been arguing with three people in this thread. Two of them work with Genesis and Genesis child themes on a daily basis and two of them are forum moderators.