Filter out sub-theme's .tpl files for parent themes

Can't reproduce. I setup a custom theme with what you described and node.tpl.php is used as expected.

But while testing, another oddity popped up. Placing sub-themes within sub-folders will cause the parent theme to read the sub-theme's .tpl files. This is because drupal_find_theme_templates() will scan the theme's entire directory for templates.

We'll need to filter that out.

I don't think we actually want to do this filtering; at least, not as a global filter. It's actually quite valuable that we can split template files up into subdirectories.

I had always assumed that we would enforce the rule that sub-themes all have their own directory. They aren't really sub-themes anymore; they're full themes with a dependency. They have no motivation to be shipped together; and if they are, they can always be shipped like so:

theme: foo, with sub-themes foo-bar and foo-baz:

foo/foo/foo.info <-- master theme
foo/foo-bar/foo-bar.info <-- child of foo
foo/foo-baz/foo-baz.info <-- child of foo

We should instead be very clear on how sub-theme directories should be structured when they are packaged together; then all will be well.

I believe we should won't fix this, but I'll wait for dvessel's comments.

Well, thanks for clearing that up. I have no issues with that myself but all the existing themes using the old sub-theme structure will be in for a surprise. Not to mention what core does and I imagine people using that as their model will get confused..

I'll leave this open for now since I'm not sure myself. If we leave it as is, then I'll add it to the docs.

Is there some reason that putting these .css file additions in the .info file not acceptable? The sub-theme system here was built more on the concept of inheritance, not of sharing.

There are other ways to do that, too.

But also, if you end up enabling some kind of filtering, you're going to destroy a feature that could also be highly beneficial.

@merlinofchaos, how about selectively filtering for sub-themes? I totally agree, what we have now is very useful but due to legacy it could affect a lot of themes. I haven't checked, just a guess.

I'll work on a non-intrusive patch so we can keep what we have now but still filter for these situations.

What this does now:

When the active theme (foo) is a base theme:

foo/node.tpl.php                         < read
foo/templates/comment.tpl.php            < read
foo/foo-baz/node.tpl.php                 < sub-theme filtered
foo/foo-baz/templates/page.tpl.php       < sub-theme filtered

When active theme (foo-baz) is a sub-theme:

foo/node.tpl.php                         < ignored as usual
foo/templates/comment.tpl.php            < ignored as usual
foo/foo-baz/node.tpl.php                 < read
foo/foo-baz/templates/page.tpl.php       < read

I'm fairly confident this will work no matter how deep the hierarchy goes. Please review.

And the structure Merlinofchaos pointed out in #4 will work too.

IMHO, I think it makes total sense to prune directories that have .info files in them that aren't the base theme's. The alternative is to create similarly-named .tpl.php files in the parent theme, which can be somewhat of a pain.

+1 on the patch. Applied it (RC1) and it properly skipped files from sub-themes.

Ok, hard to argue with that logic. I didn't think it'd be that easy to filter out just subdirs with a .info file.

Looks good to me, and fractile81 tested it successfully.

Looks reasonable, thanks, committed.

@hass: In the testing I've done with CSS-only themes (does this designation matter at this point with .info files?) in D6, all of the parent theme's .tpl.php files are being used unless there's an equivalent one supplied by the sub-theme.

hass: I'm not quite sure I understand your question exactly, so I'm going to give an example that I think addresses what you're looking for, and you can correct me if it's not right:

I have theme 'foo' and theme 'foo-bar' whose base theme is 'foo'.

foo/foo.info 
foo/foo-bar/foo-bar.info

If I have no tpl files in foo-bar at all, then foo-bar will automatically use tpl files from foo. Any tpl files actually in foo-bar will get precedence when using the foo-bar theme, however. So let's say I have this:

foo/foo.info 
foo/node.tpl.php
foo/page.tpl.php
foo/foo-bar/foo-bar.info
foo/foo-bar/page.tpl.php

When using the theme 'foo':

theme('page') --> foo/page.tpl.php
theme('node') --> foo/node.tpl.php

When using the theme 'foo-bar':

theme('page') --> foo/foo-bar/page.tpl.php
theme('node') --> foo/node.tpl.php

Exactly.! but there's one thing I missed in the patch since I'm not so good with loops. :)

With foo being active and foo-bar being dependent on foo:

foo
foo/foo-bar             < filtered

foo/foo-bar/foo-bar-baz < unfiltered
  ==or==
foo/foo-bar-baz         < unfiltered

The last two being dependent on foo-bar won't filter out the templates. It only processes the immediate sub-theme as it's structured with .info files.

This should be an easy fix. Only this part needs to be rearranged. Should be simple but I'm guessing it needs to use a while loop and I totally suck with those.

  // Collect sub-themes for the current theme. This allows base themes to have
  // sub-themes in its folder hierarchy without affecting the base theme.
  global $theme;
  $sub_themes = array();
  foreach (list_themes() as $theme_info) {
    if (!empty($theme_info->base_theme) && $theme_info->base_theme == $theme) {
      $sub_themes[] = dirname($theme_info->filename);
    }
  }

As long as $sub_themes is fed a list of paths, it'll work. It's not so complete ATM.

That was silly. No need to check for sub-theme. Just make sure the current theme isn't included in the list.

  // Collect a list of themes directories not owned by the current theme.
  // This is to prevent the active base theme from reading sub-theme templates
  // when they are placed in a sub-directory of the base theme.
  global $theme;
  $filter_list = array();
  foreach (list_themes() as $theme_info) {
    if ($theme_info->name != $theme) {
      $filter_list[] = dirname($theme_info->filename);
    }
  }

forgot to remove a line from debugging.

Hrm, nevermind that patch. That would ignore base templates when the sub-theme is active. duh!

Any help with #19?

How about this approach?

- It checks explicitly against the file's directory rather than relying on a search/replace
- A / is suffixed to directories to make sure you only match the desired sub-theme directories

I would think removing the string-functions would also boost the performance of the check. Thoughts?

This patch is untested, and is only a modification of a previous patch file. It's really meant more for illustrative purposes.

fractile81, that wouldn't work. in_array() needs an exact match for the values. I used strpos & str_replace instead since it can detect partial matches. Performance isn't a problem. It's only done once when the registry is being rebuilt.

This isn't as important anymore since having multiple levels of inheritance wasn't supported before but it still annoys me knowing that there's a hole which should be easy to fix. :) I'll try updating this later. Any other input would be appreciated though.

Okay, this does it. It builds a complete list of interdependencies. Needed two loops, one to map immediate children then another to merge everything together. Fully tested and it's rock solid.

Mind reviewing please?

Same as before cleaned up a bit.

So, anyone mind testing? I've tested this myself and it's solid. Although minor, the idea that sub-themes can be structured within base themes, it's easy to fall into a trap where your lead to believe 2nd level sub-themes should behave the same.

Hass, especially your complicated theming could potentially run into this problem. :)

Thanks, committed.