Problem/Motivation
When a template is "not found" and we are using the string loader in the Twig loader chain, instead of a useful error/exception you will just see the name of the template you called on screen.
Supplementary to that concern:
Newer versions of Twig say this about the Twig_Extension_StringLoader class:
This loader should only be used for unit testing as it has many limitations (for instance, the include or extends tag does not make any sense for a string loader).
The main reason this was added was to support inline templating: #2289999: Add an easy way to create HTML on the fly without having to create a theme function / template, see also #2317557: renderInline not compatible with twig_auto_reload.
However it very likely presents some issues the way we are currently using it, some of which are highlighted in this upstream issue: https://github.com/symfony/symfony/issues/10865
Proposed resolution
Discuss how we can factor out the string loader from the loader chain or be smarter about how we use it in the chain.
Remaining tasks
- Discuss
- Patch
User interface changes
n/a
API changes
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | interdiff.txt | 566 bytes | star-szr |
| #24 | 2369981-24.patch | 4.09 KB | star-szr |
Comments
Comment #1
joelpittetI'm game for removing this loader from the chain and just adding and removing it when using the inlineRender method:)
Comment #2
lauriiiI also agree that we should only load Twig_Extension_StringLoader class when we actually use InlineRender method. I might start working on this in few days if I have time.
Comment #3
dawehner... just curious, do we have an actual problem with it? Both examples given in that comment are kind of pointless, given how we use inline templates.
They are simple templates anyway, nothing which would use extends or includes.
But sure, if this cleans up the code, just add it dynamically, we do have pretty good test coverage now, so we can refactor the internal details.
Comment #4
star-szrThe bigger issue is this (from the IS):
Comment #5
joelpittetMoved that concern to the top of the Issue Summary, rewrote a few things and re-titled for a bit of clarity on what we are trying to solve, hopefully that is of some help?
Comment #6
star-szrJust want to give this a bit of a bump now that #2291449: Add Twig template inheritance based on the theme registry, enable adding Twig loaders is in.
Comment #7
star-szrWe need to show real errors/exceptions when calling templates that don't exist, bumping to major.
Comment #8
fabianx commentedThere is a very simple fix possible.
It is kinda a hack, but it is very simple and should work well:
Have every inline template, thing calling directly to the string loader, be start with:
'{% ILT %}' . $templateIt is unlikely any filename will ever start with that or any other MAGIC string.
Comment #9
star-szrInteresting, something like that could certainly work so that we can properly differentiate inline templates. Nice way of framing the problem at the very least. Thanks @Fabianx :)
Comment #10
star-szrPlaying around with this today.
Comment #11
star-szrInitial patch to test #8 using a special comment:
{# inline_template_start #}It's worth keeping in mind that the string loader is last in the chain, so even if you happened to put this comment string in a template file, it won't go through the string loader. All this patch does is whitelist inline templates only when they start with
{# inline_template_start #}.Regardless of the fix we agree on, we need a test here to ensure the "Template … is not defined" Twig_Error_Loader exception message shows up, I'll work on that while testbot chews on this one.
Comment #12
star-szrTest, interdiff = test-only patch.
Comment #14
star-szrBit of a follow-up to improve things further now that I am seeing the exceptions: #2430981: Unnecessary notices when twig_render_template() catches \Twig_Error_Loader exceptions
Comment #15
fabianx commentedNice, that works for me :).
RTBC, does this need beta eval? (I re-classified as a bug, because that is what it is).
Comment #16
alexpottMissing a class docblock that explains why we are doing this.
Comment #17
star-szr:)
Comment #18
star-szrHere's the docs update. Thanks @alexpott for catching that!
Comment #19
fabianx commentedThis is nit picking, but the comment does not make sense when not saying this is intended to be used within a chain loading fashion.
Comment #20
star-szr@Fabianx, sure - that was in the back of my mind when writing it. I'll get that updated. Thanks for reviewing!
Comment #21
star-szrSpent some time with the docs, hopefully this makes more sense!
Comment #22
fabianx commentedRTBC, docs look great now!
Comment #24
star-szrFunny, that is showing the notices that #2430981: Unnecessary notices when twig_render_template() catches \Twig_Error_Loader exceptions takes care of.
A bit of digging reveals that #2378883-32: Convert existing drupal_render() KernelTestBase tests to PHPUnit tests deleted common-test-render-element.html.twig stating "that is now mocked behavior", but that doesn't seem to be the case, at least not fully. So adding that template back should make this come back green.
Comment #25
fabianx commentedNice that this bug fix now showed that we did indeed hide bugs with this in HEAD.
Back to RTBC!
Comment #26
alexpottThis issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 0bf30e2 and pushed to 8.0.x. Thanks!