Problem/Motivation

One of the things that #3064854: Allow Twig templates to use front matter for metadata support made clear is that our current implementation of Twig makes a lot of assumptions; specifically around not being consumed outside of Drupal. This makes it more difficult for 3rd party software to consume Twig templates (originally intended for core/contrib) as doing so requires a specific environment and varying extensions created for use in Drupal.

Current 3rd party implementations are left to recreate/mimic said code on their own, e.g.: https://github.com/pattern-lab/plugin-drupal-twig-components

It would be nice if they could simply require a single Drupal component that allowed them to integrated more easily.

Proposed resolution

Move our current Twig environment and extensions into the \Drupal\Component\Twig namespace; providing a way to tie into core (when it's present) or gracefully fail when it's not.

Remaining tasks

TBD

User interface changes

None

API changes

TBD

Data model changes

None

Release notes snippet

TBD

Comments

markcarver created an issue. See original summary.

aleksip’s picture

aleksip
Primary language Finnish
Location Finland
commented
Related issues: +#2664570: Move Attribute classes under Drupal\Component

@markcarver Thank you for creating this issue! I am very interested in helping make this happen. Do you have any thoughts about the way to tie into core? Something like class_exists() to detect available core classes?

An alternative that comes to mind is to create an AbstractDrupalTwigExtension with concrete implementations of getFunctions(), getFilters() etc. referencing abstract functions. The component could then have a ComponentDrupalTwigExtension subclass with non-core implementations and core would have a CoreDrupalTwigExtension subclass with core implementations.

markhalliwell’s picture

markhalliwell
Primary language English
commented

I'm not entirely too sure yet. Twig is very tightly coupled to certain services at the moment.

This issue is more of a placeholder to revisit after 9.0.0 has been released as anything done here will likely change things up quite a bit. Hopefully, we can do it in a way that is BC which seems possible given how strict Symfony/Twig is with their APIs.

If I were to venture a guess, I would say that the component version would contain the base methods that "do nothing" (when core services aren't available). And the core version would subclass said component and add in the necessary services as to not break the existing Twig service/class implementations in core.

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 9.0.x-dev » 9.1.x-dev

These would be minor-only changes. Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. Thanks!

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.