[wp-hackers] Child themes, and DB options

[Tynan Colin Beatty]

Have a look at buddypress trunk, bp-themes/bp-sn-parent and
bp-themes/bp-default for some nice examples. The parent theme should utilize

{{{
locate_template( array( 'filename.php' ), true );
}}}
wherever you want to allow the child to override filename.php.
locate_template will search first in the child, and then in the parent.
In order to reference images in the parent directory, it is often desirable
to simply @import a stylesheet of the parent's.
Options should generally use your theme name, or some 2-3 letter version of
it, and not necessarily the basename of the path, and then your child can
easily reference the same 2-3 letter abbreviation. If you store your theme
options as a serialized array, all in one single option, this is
particularly simple.
peace~

On Thu, Sep 17, 2009 at 11:47 AM, [ ravi ] <ravi-lists at g8o.net> wrote:

>
> Hello all,
>
> a few questions (following up on my previous one regarding extending
> themes):
>
> If I understand it correctly, a child theme inherits template files from
> its parents (unless it has its own versions of those files). When such
> access happens, I assume include()s from the original/parent template of
> other parent PHP files will continue to work since the cwd() of the
> "includer" will be the parent template. So, if the child theme wants certain
> PHP files included in say the footer, then either it should copy over the
> footer.php and modify it, or the parent footer.php has to be relativised to
> the template (please forgive errors in the off the cuff PHP below):
>
>    if( is_file(TEMPLATEPATH . "/custom-footer.php") )
>        include_once(TEMPLATEPATH . "/custom-footer.php");
>
> Is this the right approach?
>
> By the same token, since the primary stylesheet (style.css) is located in
> the child theme, any relatives URLs in the style sheet (e.g: background:
> url(images/xyz.png) ....) will be resolved relative to the child theme -- so
> if the parent "images" directory contains icons and such, they will not
> appear in the child theme. Is that also true?
>
> Finally, for theme options in the DB obtained using get_option(), the child
> theme will use all the options set for the parent since it (by default)
> inherits the parent's functions.php and other files (where, typically,
> options are set, read and used). Unless, once again, the options names are
> relativised to the theme name. Yes? AFAIK, there is no well-defined theme
> identifier that WP uses, and the option name used by the theme in
> get_option(), etc, can be any arbitrary string. Assuming that's true, the
> one way of relativising the option name that immediately comes to mind, is
> to use basename(TEMPLATEPATH) and use that as the option name. Is this a
> good approach?
>
> Some background: why am I interested in all this? I want to be able to
> offer my theme users the ability to customise the theme and one neat way to
> do that (as suggested here) is to fork it into a child theme that they can
> then customise by editing pre-created and initially empty files in the theme
> editor (e.g: custom.css, footer-custom.php, etc). They can even add their
> own icons and background images and such, if I code up support for that.
>
> Thank you,
>
>        --ravi
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>