[wp-hackers] Child themes, and DB options

[Otto]

Few points:

TEMPLATEPATH is the path to the parent theme directory. Always.

STYLESHEETPATH is the path to wherever the style.css file you're using
is. In a child theme, this would be the child theme directory. If
you're not using a child theme, then the value would be the same as
the TEMPLATEPATH.

So, a theme should use STYLESHEETPATH for all things, unless it wants
to absolutely specify itself for a file (which a child cannot
override) in which case it would use TEMPLATEPATH.

For loading a php file (which you want to allow a child theme to
override), locate_template() should be used.

-Otto
Sent from Memphis, TN, United States


On Thu, Sep 17, 2009 at 11:56 AM, Tynan Colin Beatty
<junsuijin at gmail.com> wrote:
> 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
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>