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.
Problem/Motivation
We are currently using some deprecated code that will be removed or not workable in Twig 2.0.
Proposed resolution
- Make those updates now.
- Push our fixes upstream: https://github.com/twigphp/Twig/pull/1837
Remaining tasks
If/when Twig 2.x requires PHP 5.6, we will need to set the d.o packager to use 1.x and allow composer users to choose 2.x via #platform https://getcomposer.org/doc/06-config.md#platform
@see https://github.com/twigphp/Twig/pull/2229
User interface changes
n/a
API changes
TBD
Data model changes
Should be none.
Comment | File | Size | Author |
---|
Comments
Comment #2
star-szrThis should be all the changes needed but it'll be good to get a patch that actually updates to Twig 2.x with these changes also :)
Comment #3
star-szrActually there should be other changes needed for 2.x, I forgot about the unit testing stuff I found when testing.
Here's a patch with Twig 2.x that should show some fails.
If need be this can be split up but I don't see it growing to be a massive size. This patch is just #2 plus updating composer.json and running
composer update twig/twig
. The idea of this issue is to be able to get these changes in ahead of when we update to Twig 2.x.Comment #4
star-szrOops. New 1.x and 2.x patches.
Comment #9
star-szrRight so the Twig 2.x testing patch also needs to incorporate our new cache class otherwise it will fail badly. Getting very messy now, will be nice to get #2568171: Upgrade to Twig 1.22 and implement our own cache class in first.
Interdiff shows adding those cache class changes to the 2.x version.
Comment #10
dawehnerYeah let's wait on that first ...
Comment #11
star-szrgetTemplateClassPrefix() was also removed. Not sure any better way than this, we could add back in our own getter of course.
We override getTemplateClass() for performance reasons but it was reverted upstream because it broke some things for certain use cases outside of Drupal.
Comment #12
star-szrJust NR to get that last one tested, then I can move back to a testing issue to iterate on this.
Comment #13
star-szrComment #20
star-szrComment #21
znerol CreditAttribution: znerol commentedComment #22
star-szrWorking on this a bit now that #2568171: Upgrade to Twig 1.22 and implement our own cache class is in.
Comment #23
star-szrHere is some progress, still some failures in the 2.x version.
The interdiff is applicable to both 1.x and 2.x patches, but there was a reroll involved too.
#2571817: Remove race condition handling in TwigEnvironment::loadTemplate(), it's fixed upstream now is highly related and should probably go in first.
Comment #25
star-szrMoving the without filter callback to where it should live and removing the now unneeded require_once from TwigEnvironment, hooray!
Comment #28
star-szrThanks @joelpittet for the hint here, I just find it odd that we never had to do this before. Haven't figured out why just yet.
Comment #31
star-szrRerolls. The 1.x patch was auto-merged, the 2.x patch was generated by taking the 1.x patch, updating core/composer.json (thanks to @webflo on IRC for the help, need to add @dev because the root composer.json has a different minimum-stability rule), and running
composer update twig/twig
from the root. loadTemplate() from TwigEnvironment doesn't need to be removed in the 2.x patch anymore because #2571817: Remove race condition handling in TwigEnvironment::loadTemplate(), it's fixed upstream now is in now.Comment #34
star-szrGot too excited by the auto-merge.
For reviewers the Twig 2.x patches are just here to make sure they're green, not to be committed or even really reviewed necessarily.
Comment #36
star-szr#2416857: Add an active_theme_path twig function added a usage of \Twig_Loader_String, this fixes it.
Comment #38
dawehnerI would suggest in general to split off all changes which would still work with the twig version we use in core in HEAD, so the remaining bits of this patch is as minimal as possible.
Why is this particular change needed. Does twig no longer supports to call to simple functions?
Comment #39
star-szr@dawehner thanks for taking a look! That's what the first patch in all these comments is, it's all the changes for HEAD and shouldn't need to be split further IMO because all those changes work for HEAD. The only difference between the 2.x versions of the patch is composer and vendor to prove that things pass and work.
If you can help us figure out why we needed to move twig_without() that would be great. It was moved for unit testing reasons. @joelpittet and I tried to figure it out in BCN to no avail. You can see the fail I'm talking about in the second patch on #23.
Comment #42
star-szrNow we have some similar hell it looks like, looking quickly I think it's with the format_date filter and not having the dateFormatter for unit testing.
So it looks like Twig 2.x is doing something different with extensions maybe.
Comment #43
star-szrWas poking around the other day and found initRuntime() for Twig extensions where we can load things. Not sure if that makes it any more unit testable though, maybe it does if we call that from our unit test? I don't know :(
Comment #44
joelpittet@Cottser moved the twig_without() move for better unit-testability to it's own child issue of this to help narrow this scope a bit.
#2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate
Comment #45
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI discussed this with the other committers, and yes to removing Drupal core usages of @deprecated Twig 1.x APIs being "rc target" material.
Can we do this in a few child issues though:
Twig_NodeInterface
usages: "rc target".ThemeRegistryLoader
to only throw an exception when told to: "rc target".Per #2591515-5: Move twig_without() to the TwigExtension where all the other filters are and deprecate, let's not do the changes that require moving
twig_without()
during RC. I think we can wait until 8.1 for that, since a Twig 2.0 release doesn't appear to be imminent (correct me if I'm wrong).Comment #46
star-szrOkay cool we have #2194155: Replace deprecated Twig_NodeInterface with recommended Twig_Node now as one child, getting kicked out of sprint venue but will make sure other issues get created.
Comment #47
star-szrMaking this a plan. The patch here has been split between all the child issues:
#2194155: Replace deprecated Twig_NodeInterface with recommended Twig_Node
#2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate
#2600152: Make ThemeRegistryLoader only throw an error when $throw is true
#2600154: Update our Twig code to be ready for Twig 2.x
And I also made #2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1 a child of this issue to maybe keep it simpler.
Comment #48
xjmComment #49
joelpittetFYI this is a bit of a pain at the moment.
jcalderonzumba/mink-phantomjs-driver
is explicitly depending on Twig 1.x. I had to remove it to actually test this.Comment #50
joelpittetComment #51
jibranPatch after https://github.com/jcalderonzumba/MinkPhantomJSDriver/commit/782892dbea4...
Comment #54
xjmComment #56
joelpittetComment #58
star-szrSaving commit credits and hiding patches, patches should be worked on in the child issues. Thanks!
Comment #62
catchComment #63
Gábor HojtsyHm, so looking at these issues, my understanding is #2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1 is to do all that needs to be done to update Drupal 8 to support Twig 2 as well as the only remaining child issue at #2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate and this issue would be updating to Twig 2 itself?
Reparenting to an issue that is not a duplicate of this issue :D
Comment #64
andypostLast child commited #2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate
I think this meta could be closed in favor of #2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1
Comment #65
Gábor Hojtsy@andypost: this issue is about updating to Twig 2 in Drupal 9. #2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1 is about supporting Twig 2 in Drupal 8. While the later is a requirement for this issue to happen, this issue has its own goal on top of #2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1.
Comment #66
Gábor Hojtsy#2572605: Make Drupal 8 optionally working with Twig 2, while keeping its dependency on Twig 1 landed, so this is unblocked in terms of making the actual change on 9.x once 9.x is open.
Comment #67
Gábor HojtsyThere is a testing issue now at #3032695: Manually test Drupal 8 with Twig 2 that is used to test how it goes.
Comment #69
xjmThis is a hard blocker for releasing 9.0.0-alpha1, so promoting to critical.
Comment #70
xjm@Gábor Hojtsy closed the issue in #67 as a duplicate of #3041076: Update Drupal 9 to Twig 2.
Comment #71
xjm@Gábor Hojtsy closed the issue in #67 as a duplicate of #3041076: Update Drupal 9 to Twig 2.
We need a patch here now for Twig 2 in 9.0.x core!
Comment #72
Gábor HojtsyClosing in favour of #3041076: Update Drupal 9 to Twig 2 since all other children are now done and that is where the patch is. Carried over credits! :)