Grandchild themes and optimal network architecture

I’m trying to create a versatile WordPress network . In order to speed up development, I imagine I’ll need to channel projects to different themes at an early stage. At the core of my network install I’d like to have three or four themes, pre-configured to handle a specific class of website.

What’s more, I’d like each of these themes, though configured differently (as far as content-types, page templates, and layouts), to use the same basic functions, markup and general best practices (think html 5 boilerplate). In essence, each of these core themes should be a child theme of some parent that fits my basic technological requirements.

Read More

The problem is that when it comes time to actually create specific websites, I would like them to each be a child of an appropriate core theme.

In essence, I’m running into the problem of granchild themes as brought up in this article:

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

If you’re not familiar with it, it argues that a lot of parent themes are wrongly considered frameworks, and that WordPress is not built to accommodate grandchild themes.

So my question is this:

Is it better to duplicate a theme (no parent-child relationship) to create my few core themes and deal with updating them manually as needed, or should I have each core theme be a child theme of some parent and create an artificial (not wordpress native) grandchild inheritance system for the actual websites I create.

I look forward to hearing your thoughts

Related posts

Leave a Reply

2 comments

  1. There are a lot of specific to figure out, but your basic options are to handle it:

    1. In runtime. Stuff common core into plugin or just load it from same directory for all core themes.

    2. In development. Set up a version control, make a script that will check out common files to all core themes.