Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Follow-up to #2864031: Update twig/twig from v1.25.0 to v1.32.0
Follow-up to #2862254-17: Update non-Symfony dependencies before 8.3.0
Problem/Motivation
8.4.x has had its Twig version updated - see #2864031: Update twig/twig from v1.25.0 to v1.32.0
But there are regressions - https://github.com/twigphp/Twig/issues/2447 - our current constraint means that composer controlled projects get the latest version and experience bugs.
Proposed resolution
Change Twig constraint to >=1.23.1 <1.27
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#2 | 2869528-2.patch | 454 bytes | alexpott |
Comments
Comment #2
alexpottWe have know regressions on 1.28.0 and I think @lauriii discovered something in 1.27.0 too. The current locked version is 1.25.0 on 8.3.x
Comment #3
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedAlternative solution would be to get Composer-managed projects to use webflo/drupal-core-strict. Of course, not all (few?) projects will be using this at the moment, so directly modifying composer.json as is done here is a good idea.
c.f.: https://github.com/drupal-composer/drupal-project/pull/264
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commentedComposer seems to have some problems using drupal-core-strict in some instances. See notes in the issues linked from the PR above for details.
Comment #5
joelpittetCould we look at fixing BC regressions upstream? One was committed recently I noticed.
Hopping to move forward but may this patch is meant to be a stopgap?
Comment #6
dawehnerI totally agree we should work with the twigphp community to fix these versions upstream. In the meantime though it is useful to not introduce problems for existing nites.
In general I believe that explicit specifying which versino of a package Drupal relies it in order to function correctly is a good idea.
The only small fear I have: When we limit the core version here, we will have a problem potentially when there is a security issue coming out.
Comment #7
alexpott@dawehner well right now we have a huge problem if a twig security bug occurs. We'd probably have to fork and merge the fix to our supported version :(
Comment #8
dawehnerWell either that or we include composer patches. Would that be a feasible alternative?
Comment #9
joelpittetPatching seems like a good approach to big security bugs, but for regressions in the 1.x Twig specific problem, fixing upstream regressions seems better because leave upstream open for improvements and bug fixes. If upstream isn't receptive to our changes then maybe this is the correct approach, but this would be similar to the forking idea just a stale fork(with bits of food left from dinner on it).
Comment #11
lauriiiThe upstream bugs have been fixed.