We're looking into ways to let themers define their own Twig filters and functions, and one way to do it would be to allow themers to define their own Twig Extensions within their themes. This ought to be possible using a services.yml file, together with a patch such as the one at #1964156: Contrib cannot define additional Twig extensions, but it looks like these files are only supported by modules right now.

Is there any indication that services.yml files might be supported by themes?

Files: 
CommentFileSizeAuthor
#8 drupal-themes-dont-support-2002606-8.patch13.6 KBMark Carver
FAILED: [[SimpleTest]]: [MySQL] 56,485 pass(es), 5 fail(s), and 0 exception(s).
[ View ]
#8 interdiff.txt2.33 KBMark Carver
#6 drupal-themes-dont-support-2002606-6.patch13.43 KBMark Carver
FAILED: [[SimpleTest]]: [MySQL] 56,473 pass(es), 7 fail(s), and 2 exception(s).
[ View ]
#2 drupal-themes-dont-support-2002606-2.patch15.57 KBMark Carver
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new15.57 KB
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
[ View ]

Nope, that issue is unrelated. Here's a patch that will hopefully fix this issue

Status:Needs review» Needs work
Issue tags:-Twig, -theme system cleanup, -Stalking Crell

The last submitted patch, drupal-themes-dont-support-2002606-2.patch, failed testing.

Status:Needs work» Needs review

Status:Needs review» Needs work
Issue tags:+Twig, +theme system cleanup, +Stalking Crell

The last submitted patch, drupal-themes-dont-support-2002606-2.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new13.43 KB
FAILED: [[SimpleTest]]: [MySQL] 56,473 pass(es), 7 fail(s), and 2 exception(s).
[ View ]

Themes don't have to specify a THEME_NAME.theme file, which caused certain arrays to be empty and throw a PHP error. Also removed coder cleanup since it's not related to this patch. Also removed profiles from the theme array ;)

Status:Needs review» Needs work

The last submitted patch, drupal-themes-dont-support-2002606-6.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new2.33 KB
new13.6 KB
FAILED: [[SimpleTest]]: [MySQL] 56,485 pass(es), 5 fail(s), and 0 exception(s).
[ View ]

Fixed so test would validate

Status:Needs review» Needs work

The last submitted patch, drupal-themes-dont-support-2002606-8.patch, failed testing.

I give up, I can't for the life of me figure out why this last patch is failing. It's 5 small fails to seemingly unrelated tests. If anyone can please shed some light onto this?

Title:Themes don't support their own services.yml fileTheme *.services.yml files aren't detected

The failures on the latest patch are all locale related. Not sure if that helps though.

I tried to help Mark Carver here as asked in I18N IRC channel but after a long night of debugging I couldn't figure it out.

At least reporting the status.
I can't reproduce this when adding a new language, adding the config for the site name by hand and loading the page. It works and it is what the test does.
So I had to run the test all the time, as it seems for me the only way to reproduce the issue... But debuggin in tests is a little bit hard.
Either way the problem is somehow in the LanguageManager.php. The getLanguage() Method is returning sometimes the wrong language. I added many debug messages in this class and the output was similar to:

...
this->languages[language_interface] = en #1
reset() #2
this->languages[language_interface] = xx #2
this->languages[language_content] = xx #2
this->languages[language_url] = xx #2
isset(language_interface) return xx #2
isset(language_interface) return xx #2
notify load system.site (EventDispatcher)
isset(language_url) return xx #2
isset(language_interface) return en #1
isset(language_interface) return en #1
notify load system.site (EventDispatcher)
isset(language_url) return xx #2
isset(language_interface) return en #1
isset(language_interface) return en #1
isset(language_interface) return xx #2
isset(language_url) return xx #2
isset(language_interface) return xx #2
isset(language_interface) return xx #2
...

Just in the middle it returns from the $this->languages a different value then it sets before. I used spl_object_hash($this) to also add the hash (cutted above) of the objects. There are somehow two different LanguageManager initializiesed. #1 which has wrong values and #2 which works. I have no clue how THIS patch introdoces this behavior. But without the patch everything is working and its always the same hash.

Hopefuly it helps somebody to fix this issue as it took me the complete night to figuring this out.

I'd prefer to leave services to modules, at least until #1067408: Themes need an installation status. Without that this seems like opening a can of worms. A theme can always have a helper module that does the Twig extension.

Status:Needs work» Postponed

At first I thought the same, but I really don't think it makes much of a difference. This patch only detects enabled themes and adds them to the Kernel, along with any services they might want to register. Granted they might not be properly installed (per #1067408: Themes need an installation status) but I was able to successfully detect and register a service in a test theme.

I also respectfully and strongly disagree that only modules should provide services. #1964156: Contrib cannot define additional Twig extensions, allows Twig extensions via a service and I'm sure there are other "services" that will come to pass, could greatly enhance a theme's capability.

A theme can always have a helper module that does the Twig extension.

Doesn't this kind of defeat the whole purpose of putting Twig in then? Twig was introduced to help move theming TO themes. It seems rather counter-productive to not have themes define their own functions/filters that's specific to their theme. Plus I would really like to get away from "oh btw, to use this theme you have to also install X module". Why can't themes work out of the box?

An example of this would be any theme that uses a grid system. In Bootstrap, this would help replace a lot of the Bootstrap specific functions that were used in templates, ie: determining the spanX widths of the sidebars and content, since they vary. Yes... if it really came down to it, we could do all the calculations in hook_preprocess_page() and add extraneous variables to accommodate all these variations, but that seems silly and definitely doesn't feel like the right approach.

Also, considering #1964156: Contrib cannot define additional Twig extensions is marked "critical", I'd almost argue that this issue goes in tandem with we're trying to do with Twig in general.

Ok, been thinking about this and I can see how allowing any service could be detrimental. What if we were to parse the theme's services.yml file and only allow white-listed services? Any others that are detected in that file would throw and error saying that it needs to be taken out.

Ok talked to msonnabaum on IRC and he suggested that we move twig extensions out of services.yml and put the twig extension in the info.yml instead.

msonnabaum:

the service container is not an appropriate concept at the theme layer

twig.extension could be used to house the name of the class to use for extending twig in the info.yml file. I'm wondering if we can do this for both modules and themes then and refactor #1964156: Contrib cannot define additional Twig extensions to look for it in the info.yml instead of services.yml.

Issue summary:View changes
Status:Postponed» Active
Parent issue:» #2228093: [meta] Modernize theme initialization

From an architectural perspective, Twig extensions are "plugins" in Drupal's architecture.

If we'd (1) keep on registering the theme namespace and (2) discover twig extension plugins in each theme (and its base themes), would that be a potential solution?

For example, assuming a custom domain plugin namespace/directory (sans \Plugin):

/themes/bootstrap/lib/Drupal/bootstrap/Twig/MyExtension.php

Once the switch to PSR-4 has landed, that would become:

/themes/bootstrap/src/Twig/MyExtension.php

Thoughts?


Note: If those twig extensions are compiled/dumped in anyway, then they MUST be compiled into non-global, theme-specific PHP file, because the current/active theme can change at any time. — But I hope that this is not the case in the first place?