For my twig-D7 installation i've added a few extensions to twig, but where do you plan on having those in D8? Because they are not really a module so being in modules would be semanticaly incorrect and core/vendor would emply extentions being a part of core. Any plans on a /sites/all/vendor structure?

Hooking them in would become possible with something like 

autoload_register('Myvendor',drupal_root . 'sites/all/myvendor);
twig()->addExtiension(new Myvendor_Twig_Extension());

BTW awesome seeing twig moving towards core acception :)

Comments

jenlampton’s picture

jenlampton
she / her
commented

Hi ReneB!

We've been thinking about where to put the new twig files, and for now we've been adding them to the stark theme. Eventually, I immagine they will replace the current .tpl.php files, so some in system, others in their own modules, and then each theme files in the themes, of course. Nothing's for sure yet though, so if you have more ideas please keep sharing them here :)

rene bakx’s picture

rene bakx
He/Him/Smurf
Primary language Dutch
Location Netherlands
commented

That makes sense indeed. So I guess all it would need is a method to get the initialized and registered twig engine and then a module could add an extension on init. Saves the option to create yet another hook :)

  function mymodule_init(){
   getTwig()->addExtension(new MyModuleTwigExtension());
   }

or if you need multiple

  function mymodule_init(){
   $twig = getTwig();
   $twig->addExtension(new MyModuleTwigExtension());
   }

This way twig extensions become modules, and can live in their own environment. Dependencies could be managed trough the module system.
As for allowing themes to register extensions, somehow that doesn't feel okay to me. But then again, how often would a theme need to register an extension. A filter, now that's something I can imagine.

But that could use the same getTwig() method.

/** top of the theme */
$twig = getTwig();
$twig->addFilter('coolfilter', new Twig_Filter_Function('themename_coolfilter'));

function themename_coolfilter($string){
 return .... $string;
}
jenlampton’s picture

jenlampton
she / her
commented

I think that makes sense, if you want the Twig engine to work differently, then you need a module. A theme is just supposed to be responsible for the output, generally speaking.

tlattimore’s picture

tlattimore commented

Re #2:

As for allowing themes to register extensions, somehow that doesn't feel okay to me.

I totally agree. Adding an extension really steps over the bounds of what themes are intended for.

Would it be possible to adopt the 'libraries' (e.g sites/all/libraries) model for adding twig extensions? Though I am not sure twig extension constitute libraries. Is this what basically what you were implying in the original post for this thread, in regards to 'sites/all/vendor', ReneB?

jenlampton’s picture

jenlampton
she / her
commented

what about sites/all/extensions? or are new people going to mix those up with modules?

maybe sites/all/themes/extensions?

jenlampton’s picture

jenlampton
she / her
commented
Project: Drupal 8 with twig - abandoned sandbox »
Component: Code » Twig engine
Status: Active » Postponed
Issue tags: +Twig engine

moving to active twig sandbox, also postponing for now.

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented

2jenlampton
sites/all/themes/extensions looks reasonable for me
possibly we have to make decision about core/themes/engine/twig/extensions for core-wide extensions

Project: » Lost & found issues

This issue’s project has disappeared. Most likely, it was a sandbox project, which can be deleted by its maintainer. See the Lost & found issues project page for more details. (The missing project ID was 1750250)