Show actual Twig template path (FE) in debug mode
Description
When inspecting the frontend in debug mode, the correct paths for PHP templates are output so far like:
<!-- TEMPLATE START: templates/ce_list.html5 -->
...
<!-- TEMPLATE END: templates/ce_list.html5 -->
4.13.10: If I create a Twig template in 4.13.10 by extending a .html5 template like:
{# /templates/ce_text.html.twig #}
{% extends '@Contao/ce_text' %}
...
I then get:
<!-- TEMPLATE START: vendor/contao/core-bundle/src/Resources/contao/templates/elements/ce_text.html5 -->
...
<!-- TEMPLATE END: vendor/contao/core-bundle/src/Resources/contao/templates/elements/ce_text.html5 -->
5.0.2: If I create a Twig template like:
templates\content_element\text.html.twig
The FE does not show me the template path in debug mode at all.
Would expect the correct template paths to be displayed throughout in debug mode.
Already got this on my list. I'm still a bit unsure how to implement this, though. Or if it is actually doable.
Thoughts:
-
This can either be implemented in the code that calls
$this->render()- i.e. the fragment controllers could for instance wrap the output - OR it can be implemented as a node that gets inserted into the template's body during compilation.- The latter would also work for extended/included/embedded templates. We would need to make sure it does not break anything when using a template, though. And it might produce a lot of output…
- Alternatively the node could be inserted into the template's blocks - this would then probably work everywhere but might be a bit extreme.
- If there are no display nodes in a template, likely nothing should be output.
-
These are HTML comments - they should never be output by anything other than a HTML template (
.html.twig). However, due to BC constraints, we're only supporting this extension right now. So there might be some mixed output… -
What should the debug message actually contain? The file path, the logical name?
I think, I'll need more use cases to justify the decisions: When do you need this information? Or what are you trying to achieve and need support in?
Well, my first thought was that it was possible so far and therefore corresponding expectations exist. Basically, the path specification of the last, used template could be sufficient - so as before.
Concerning extended/included/embedded these, further details would be actually correct. But I also think that this could confuse more than help in this context (To be able to trace the hierarchy we already have a possibility: contao-console debug:contao-twig).
What's your actual use case where you need this kind of information?
If you work with the browser dev tools for the layout, this is helpful for the overview.
What do you mean by "helpful for the overview"? What exactly would you expect?
This sounds like you would want to see the outline of content elements, not anything more detailed. Is this correct?
If I understand correctly, we talk about this:

Contao does this in .html5 templates:
https://github.com/contao/contao/blob/5ced46dc042c8597771d4d2de5e9408b5b7ff31d/core-bundle/src/Resources/contao/library/Contao/TemplateInheritance.php#L151-L156
Twig doesn't, so if you use stand alone .html.twig template, there's no comment. If a Twig template extends from .html5 template, the comment shows path of that parent template.
Yes, I know how it works for the legacy templates. Twig works differently, the templates are structured differently. And, more precisely, there isn't such a thing as "a template" if you consider what is possible in terms of vertical/horizontal reuse (think of use for example or the block function with a foreign template as second argument or embedding templates and so on…).
I don't want to (or can't) reproduce the old behavior, I want to find a helpful solution. And for that we have to get back to what's actually the problem we are trying to solve.
I would say, the old <!-- TEMPLATE START: --> feature speeds up the scenario, where you want to correct a template, and with one or two clicks ("Inspect...") you can find out exactly which file you need to edit (or override).
On the other hand, Twig has really cool support in the profiler, which shows you the full hierarchy of the templates, their paths, and in case of extending – even which blocks are overridden. It just not showing it "in place", in the page source.
To be honest, I for one did not yet try to incorporate this feature in my workflow... I'll try to see if it helps to replace the old functionality.
Hint: https://youtu.be/ColU1MSzCEI?t=256 :slightly_smiling_face: As already listed, a simple "info" in this regard would already suffice. Should there be any further ideas in connection with Twig: Would be Great!