Extend Twig_Loader_Filesystem instance to get .twig templates paths with hierarchy for theme dependencies

Any reason to have current theme_registry or is there some battleplan to fix it with new EntityConfig?

We do not actually need extend findTemplate()
Looks like we just have to rewrite twig() function from twig.engine

with $loader->addPath($path) after creating $loader instance

function twig($reset = TRUE) {
  static $twig;
  if (empty($twig) || $reset) {
    // We will have our own loader.
    $loader = new Twig_Loader_Filesystem(DRUPAL_ROOT);
    $twig = new Twig_Environment($loader, array(
        'cache' => DRUPAL_ROOT . '/compilation_cache',
        'cache' => FALSE,
        'base_template_class' => '\\Drupal\\Core\\Template\\TwigTemplate',
        // @TODO: REMOVE ME!!!!!!!!
        'autoescape' => FALSE,
        'strict_variables' => TRUE,
    ));
    $twig->addNodeVisitor(new TwigNodeVisitor);
    $twig->addTokenParser(new DrupalHideTokenParser());

    $functions = array('t', 'attributes', 'drupal_attributes', 'drupal_render', 'render', 'myrender', 'hide', 'show', 'unset', 'count');
    foreach ($functions as $function) {
      /* @TODO We decided to always use filters at DrupalCon Munich. */
      $twig->addFunction($function, new Twig_Function_Function($function));
      $twig->addFilter($function, new Twig_Filter_Function($function));
      // @TODO remove URL once http://drupal.org/node/1778610 is resolved.
      $twig->addFunction('url', new Twig_Function_Function('url'));
    }
    $twig->disableStrictVariables();
  }

  return $twig;
}

better title and

My proposal for todo

1. find all template paths for current theme
2. find all template paths for parent themes
3. find all core template files for core stark theme
4. cache it or store into config() or EntityConfig
5. addPath() with founded paths

typo and status

title typo

Updated issue summary.

Updated issue summary.

Updated issue summary.

+1 for #5

Updated issue summary.

Introducing a new static instance or singleton doesn't sound like a very smart plan when drupal is making the transition into a DIC system.

For Symfony2 the including of templates from bundle1 in bundle2 is solved by extending the include tab with a given structure.

something like this : incude "@bundle::Folder:folder:template.twig

I guess a system like this could work in drupal too, just need to substitute bundle for theme.

In the override of the include, we just need to check if the to be included file excist and include it. Perhaps the theme registry (if it survives into d8) could be injected into the twig environment, so it becomes easier to see if the requested incude file actually is part of a twig theme instead of traversing all themes and such.

As I understand bundle in Symfony it is like module in Drupal? So, U mean to search templates in modules?

incude "@bundle::Folder:folder:template.twig

Such syntax looks like not good due to theme dependency system
If one theme is child for another(parent) handling with ...folder:folder... is weird
I vote for #5 cause

include "foo.twig"

children
and

include "foo.twig"

parent(inactive, overridden) theme
is more simpler and better to undestand for front-end designers

Introducing a new static instance or singleton doesn't sound like a very smart plan when drupal is making the transition into a DIC system.

Yes, I agree with that
But as I know DIC is not ready yet
#1706064: Compile the Injection Container to disk
#1759152: Add a database service to the DIC
And If You can be more specific and provide for us a few examples how we can use DIC workaround - I`ll be happy with that

For now - singleton workaround works well and can be extended for multiple instances possibility between feature freeze and code freeze stages and do not looks like blocking issue for us till feature freeze

@vlad, Bundles are indeed the symfony equivalent of modules, but my comment was more from a syntax point of view.

@podarok,

Say you have a theme called 'bartik', and your own theme called 'thingee' which is a subtheme of bartik. With the naming structure suggested you could simply do something like.

{% extends '@bartik:node.twig' %} or {% include '@bartik:blocks:block_contact.twig' %}

Where I admit, it is more work to type in a template, but in a blink of an eye it is perfectly clear where the template is extended from, rather then make a magical system where you traverse themes underwater to see if it is a subtheme, and if the parent actually has the template you want to extend or include. Without our thrusty old theme registry it would mean that every time a change is made, the file system must do the traversing again and again. Performance wise, I rather would type a little bit more and spend my time educating new themers instead of telling them stories about magic includes.

As for an example on the DIC, must see if I can digg up some time next week, so I can see what the status is, cause I tought it was already functional, yet very slow cause it is not materialized to disk in a cache (like symfony2 does when you turn your application into production mode) Personally I would rather work on a long term solution, instead of focusing on a short term thing. But i can imagine the presure that is upon us as community, December is coming along awefully fast, and if we don't make it before then this whole twig in core is a no-go I presume?

the file system must do the traversing again and again.

Not with twig and its template compillation cache

only if you are in production mode, in development mode a template is always considered fresh and therefor recompiled on every hit. A minor issue perhaps, but from a developers point of view quite irritating and possible slow. Compare it to the now common practice of clearing the theme registry on every request.

But besides that, my point for extending the loader system with the @themename notation is more about the readablity of template code then performance. I believe drupal could use a little less magic and more clearabillty on where what comes from :)

Starting work on this

Seems we need something like:

{% include '...' with {
  x: y,
  preprocess: TRUE / FALSE,
} %}

and maybe run the preprocess function - if needed with the default being that preprocess is called, but for item-lists or table cells the output can be pre-formatted.

But maybe this is making it more complex and we should just ensure to always call the respective preprocess function. Maybe even re-add theme("item_list", { x:y }).

#17 make template designers crazy
can we make it more simple?

Thats the official way:

http://twig.sensiolabs.org/doc/tags/include.html

I don't think we should divert from it.

We just need to make sure that the preprocess functions are called properly.

#19 I got it

re:

We just need to make sure that the preprocess functions are called properly.

Can we discuss this point, and how to know what is "proper", like when does an {% include %}'ed twig file need or not need preprocessing?

Am I right to think that currently when we include a twig template we are *not* running preprocess on that, as we are circumventing theme() at that, template, level?

@22: That is correct.

In Symfony2 if preprocessing is needed on an include tag, render is used instead which creates a sub request.

#24: Interesting ...

This is the actual code that gets executed via twig render function. This in turn calls Symfony2 Actions templating helper.

https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/Framew...

Update from Hangout today:

* include will never call preprocess, but will be changed so namespaced templates can be loaded from the theme_registry.
* We will provide theme() for calling the full stack().

=> If you use "theme" you are in Drupal land
=> If you use "use", "extends", "include", "import", "embed" you are in twig land, but templates will be loaded via our special file loader.

---> Nice separation of concerns.

We still need to change the loader, so changing title back and re-opening and following the other one.

I guess the way templates are discovered changed inbetween D7 and D8? If not, I rewrote the D7 twig template discovery system yesterday to mimic a part of the way Symfony2 is handling includes.

Basically it comes down to a structure like this :

{% extend theme::path:to:template.tpl.twig %}

or without the path

{% extend theme::template.tpl.twig %}

or if you are in the same theme

{% extend template.tpl.twig %}

I addapted the Twig_Loader to use this system, with a fallback to the normal inclusion system. And the changes to the engine + loader will be commited into my D7-twig sandbox somewhere this evening (CET+1)

#31: Thanks a lot, I will pull the changes in :-).

That was exactly my plan as well, but doesn't Symfony use @namespace: instead of namespace::?

Just wondering ...

Edit: I am not yet seeing the changes. Have you pushed, yet?

Nope.. did not make it.. deadlines and work. And yes symfony uses the @ namespace to determine the difference, but i removed the @ because the theming structure in D7 is a lot less structured over various bundles.

I changed the system only to use the current theme and if available the base theme as possible source.

Planning to do the commit today, i actually blocked some time this afternoon to do this :)

Just to be sure, my implementation is for D7, and not a backport of the D8 system. I looked at that once, but it was a lot of work with in my humble opinion less to be gained for D7.

I have taken a look at your sandbox and am thinking of what I'll port to D8, so that is totally fine as I am aware of the differences.

Updated issue summary.

Unless I'm terribly mistaken, this has been fixed in Drupal core very recently. We now support to load templates from a given provider namespace, denoted by @provider/desired-template.

Unfortunately I'm not able to find the core issue right now, but nevertheless, closing as duplicate.