Problem/Motivation

The Bootstrap base theme (3.x) is incompatible with the Component Libraries module, which allows you to put template files in a different location than the templates directory. This allows templates to be shared between Drupal and a component library (style guide). The reason seems to be code in the Plugin\Alter\ThemeRegistry class, which scans for templates only within the templates directory.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

None.

Data model changes

None.

CommentFileSizeAuthor
#10 2951575-10.patch1.31 KBmarkhalliwell
#2 bootstrap-components_compatibility-2951575-2-d8.patch812 byteseelkeblok

Comments

eelkeblok created an issue. See original summary.

eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented
Status: Active » Needs review
StatusFileSize
new bootstrap-components_compatibility-2951575-2-d8.patch812 bytes

Here's a very naive patch; simply scan the entire theme instead of just the templates directory.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Category: Bug report » Feature request
Status: Needs review » Closed (works as designed)

This issue doesn't sense to me.

I think you misunderstand how that module operates and what it does.

Component Libraries merely registers additional Twig namespaces.

The reason the theme registry specifically only looks at templates because that is where templates that follow core's theme hook naming patterns should live.

That has nothing to do with component libraries.

If you custom component library twig templates aren't being discovered because they live outside templates, then you should define the path to where they live in your theme's .info.yml file as described on the project page.

eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented
Status: Closed (works as designed) » Needs review

Thanks for the reply. I think I do understand how that module operates and I've done all that. The problem happens because I override a template that is also overridden by the Bootstrap theme. However, the template, in my subtheme, lives in a different directory. When debugging the alter code, what I see is that my template is found correctly and the path is correct, right up until the point the alter code in Bootstrap is ran. At that point, for each theme hook the code for some reason does a double check whether the template exists and overwrites the template path. Because it only scans in the templates subdirectory of a theme, it doesn't find the template for my subtheme and ends up overwriting the template path with the location from Bootstrap itself.

I can verify Bootstrap to be the cause by removing Bootstrap as the base theme from my subtheme. Obviously styling is al screwed up, but I can see that my template is used then.

Status: Needs review » Needs work

The last submitted patch, 2: bootstrap-components_compatibility-2951575-2-d8.patch, failed testing. View results

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Needs work » Closed (won't fix)

Again, this isn’t a bug.

If you’re overriding a template from the base theme, then that is a theme system template, not a component library template.

It should live in the same place as it does in the base theme, if only for continuity.

eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented

I see your point. It makes for a confusing experience, though, that it works fine with just core and components, but it breaks with this base theme.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Category: Feature request » Bug report
Status: Closed (won't fix) » Needs review
Related issues: +#2821420: drupal_find_theme_templates() searches candidates that are never have templates and are duplicates, +#2817103: Theme registry doesn't find templates in subfolders for self-defined theme hooks

So this appears to be a (relatively) recent core change that only applies to sites running 8.4.0+.

What's confusing is that there wasn't a change record for this. I've now remedied this.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Title: Incompatible with Component Libraries module » Templates limited to "templates" directory of sub-theme
Assigned: Unassigned » markhalliwell
Status: Needs review » Needs work

Also, the above patch is reversed.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Needs work » Fixed
StatusFileSize
new 2951575-10.patch1.31 KB

  • markcarver committed be175e6 on 8.x-3.x 
    Issue #2951575 by markcarver, eelkeblok: Templates limited to "templates...
markhalliwell’s picture

markhalliwell
Primary language English
commented
Assigned: markhalliwell » Unassigned
eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented

Yeah, I figured the patch was probably reversed when it failed to apply, but did not look into it yet. Thanks for figuring this out.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Category: Bug report » Feature request
Status: Closed (fixed) » Needs work

After I made my initial investigation, #2821420-11: drupal_find_theme_templates() searches candidates that are never have templates and are duplicates I'm re-evaluating this issue.

I don't think core actually does what I thought it did after all.

As you can see here, the registry still defaults to the /templates directory of a theme:
http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Theme/Regist...

// Prepend the current theming path when none is set. This is required
// for the default theme engine to know where the template lives.
if (isset($result[$hook]['template']) && !isset($info['path'])) {
  $result[$hook]['path'] = $path . '/templates';
}

This issue/commit should probably be reverted.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Needs work » Fixed

The above patch/commit hasn't seemed to do any long-lasting damage, so I'm just going to close this.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Fixed » Closed (fixed)