New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What would you like to see as major changes that would lead to a BC break for the next major release of Twig? #3951
Comments
I really like the askama approach to make template type safe, and a little out of topic, it would be great if twig had an up-to-date formatter (maybe with a prettier plugin maintained by core team) |
I like that you started removing usage of This will allow concurrent Twig renderings using fibers. |
I would like to see a focus on component based templating over overriding/inheritance. For that macros need an improvement specifically the need to import them separately in every block. Would be great to support ux html component syntax natively for creating components. A type checker plugin (pslam/phpstan) would be nice to have as well. |
Support for step debugging via source maps would be nice. |
Plugin / Theme Structure like Shopware built around Twig. We had to built something as well and it feels bad to just copy if this could have been solved directly. And twig is already strong in multiple inheritance. |
Static type support for generated php to increase performance and predictable execution. I already tried to approach it but optimisation levels were commented as too breaking. So we could break it here. #3928 |
Still be able to use Twig without pulling a lot of more dependencies. E.g when you merge the twig symfony bridge into the twig package and in a small project just want to get some templating, you don't get the whole dependency clutter from the framework bundle. I don't use laravel/blade because you always get so much laravel stuff with it. I just want something small that can do inheritance and autoescape. Otherwise I would just use php right away. I see benefits in merging some code from expression language as twig has to parse expressions as well and has "just" some nodes on top. |
Change the null-coalescing operator to an empty- (or falsy-) coalescing operator. All the time I have a variable that is empty but not null, and I want to do EDIT: I expected some 👎🏻 reactions but I'd like to hear an explanation for them |
Some type of script block to write multiple statements without typing {% %} for every line would be nice. Something like this: {% script %}
set counter = 0;
set color = "#33b5e5";
set list_items = [{ ... }, { ... }];
if (some_var is same as true)
set list_items = [...list_items, { ... }];
endif
{% endscript %} |
Definitely two things: Removing entirely the
|
Its called the null coalescing operator for a reason. The whole php community is moving towards more strict typing, let's not create unexpected results by changing a well known concept like |
Add the possibility for global macro inheritance. Import in base template and available in all inheriting templates. Maybe a |
It's called that because that is what it does. If it did something else, it could be called something else.
Twig is not PHP. It is written in PHP, it compiles to PHP, but it is its own language with its own goals. (inb4 "Your idea would be an ’own goal!’”) I don't believe its goal is merely "Enable back-end OOP PHP experts to write 1:1 PHP code in fewer characters".
This thread is specifically about breaking changes. Anything accepted from this thread will be equally unexpected to the person who compiles an old Twig file with the new version without reading the new docs.
Shall we deprecate the Anyway, I won't say any more, this is clearly a non-starter. I don't think it should be, though. I'm full-stackish, I can write clean and pretty and strictly typed OOP PHP myself, but I don't think those same sensibilities should be uniformly applied to a template language meant to make front-end developers' lives easier. |
I agree with most of the points @75th is raising, but let me add a bit of fuel to them:
This should be in the front page of every article and documentation dedicated to Twig. Twig is not "a templating language for PHP" for a good reason: the definition does not make sense. No language can be a language for another language. I'm sure that said this way, everybody would agree that it makes no sense. Twig is a language, with compilers dedicated to be run by different runtimes (PHP, Ruby, NodeJS, browser runtimes...). And as such, it can - and must in my opinion - make its own decisions.
This should definitely raise some concern: that the ternary operator is not strict but that the nullish coallescing one is is something that it not consistent and goes against @reinierbutot "The whole [...] community is moving towards more strict typing". If one is strict, the other must be strict. If one is not, the other must not be.
Absolutely correct: @reinierbutot, if your position is "just make sure the data sent to the template is correct", then why these last years have seen more and more functions and filters added to Twig that are dedicated to manipulate and generate data instead of just outputting data? Why do the formatting filters exist? The backend knows everything required to send appropriately formatted dates or numbers or currencies or countries to the templates, so why were these formatting features added if "just make sure the data sent to the template is correct"? Why do the date creation function exist? The backend knows how to create a date and should send dates to the templates, right? I think we must not forget that a templating language main purpose is to process plain text. So, yeah, @reinierbutot, I agree with you that we must "make sure the data sent to the template is correct". But you have to admit that it is not the direction that Twig has been taking - and it is getting worse and worse everyday (eg the infamous |
In template inheritance, variables set outside blocks in child templates should have priority over these declared in base template https://blog.srsbiz.pl/2021/07/scope-of-set-in-twig-templates/ |
As someone coming from extending applications built-upon a framework I sometimes do not have the option to change the data, that I get. "Have no option" means no services in DI, no events in event dispatcher or as in "no data returned from a controller but rendered directly". There is always the vendor patching way but I try to focus on something maintainable. Example: when someone is giving me a doctrine entity for the template I just get a DateTimeInterface property, that could be not yet timezoned or formatted. And I think this is good. So when I have a data cache, the entity can be held in the cache independent to who renders the entity. Another example: Sometimes data is expressed twice. So when I display a date human readable, I have often have a structured data part, that expresses the same date but in a machine readable format. So I'd rather have the date once in the template data and be able to format it whenever I need it in whatever format I need it. This is the part, that gives me flexibility in changing templates of others. |
@JoshuaBehrens I get your point and I agree - but it says a lot about how backend are (not) specified - and mainly driven by the frameworks instead of by the requirements - and how frontend developers are left behind even today. My point is that if one says that "data sent to the template is correct", then it makes all the filters and data manipulators of Twig not legit. |
I would love the ability to statically analyze twig templates with phpstan/psalm. Twig templates are one of the remaining vulnerable parts of codebases to breaking changes and not knowing it. |
@ericmorand @75th thanks guys. So you want It does actually feel more like the Twig way. I'll be looking forward to using this new falseycoalescing operator 😂 |
@reinierbutot, well, I don't have a PHP setup ready but even in JavaScript, the behaviour of the ternary and the nullish coallescing operators are not consistent - or maybe they are but it is not obvious to me: console.log(null ?? 5); // 5
console.log(null ? 4 : 5); // 5
console.log('' ?? 5); // <empty string>
console.log('' ? 4 : 5); // 5 As you can see, |
Maybe not a BC break and even maybe discarded already, but what about allow to pass an object as context when rendering a template? |
Ohh, crap. I must confess: I didn’t realize that So, request withdrawn. (for that matter, it might have been nice to have it be |
The fact that the default default value of the default filter (wow, that sounds complicated) is - function _twig_default_filter($value, $default = '')
+ function _twig_default_filter($value, $default = null) |
Having new extension points somewhere between Parser and Lexer could facilitate Twig/LiveComponent maintenance and unlock some new features :) |
Very personal wish, but I'd love to have "private" templates (as in "not possible to override" with the multi-paths system, or extends) |
I almost forgot... those are also old wishes of mine, but i can't remember / understand why i marked them at "not doable" if set / ifsetThe equivalent of PHP
BreakAny method to "exit" while in loops, but ideally also inside blocks |
Strict typing for example using === instead of same as (faster DX) |
I'd like to be able to combine a set and if statement. {% if count = post.comments.count %}
There are {{ count }} comments.
{% endif %} instead of {% set count = post.comments.count %}
{% if count %}
There are {{ count }} comments.
{% endif %} |
I find adding properties to objects to be complicated and hard to read. I'd like to be able to add an element to an object without doing the merge, e.g. instead of {% if options.depth is not none %}
{% set options = options|merge({'depth': currentOptions.depth - 1}) %}
{% endif %}
{# update the matchingDepth for children #}
{% if options.matchingDepth is not none and options.matchingDepth > 0 %}
{% set options = options|merge({'matchingDepth': currentOptions.matchingDepth - 1}) %}
{% endif %} I'd like to be able to simply set an object property. {% set options.currentDepth = currentOptions.depth - 1 %} It'd be even better if there were a way to combine the if statement with the set {% set options.currentDepth = (currentOptions.depth) - 1 if options.depth is not none %}
{% options.depth is not none ? set options.currentDepth = (currentOptions.depth) - 1 %} Just brainstorming on the if / set, but the ability to set a single property would be really nice. |
Clearly a must have even if it's not directly linked to twig codebase ! Extending this check to twig bridge render arguments would be perfect. It's a bit off, but with sf router we have the same vulnerability when you change an arg name. How are you managing it ? |
I don't know if it is a BC, but a support for promises would be great. I have some ideas how it would be possible to work without making another HTTP call (as I do now), but the implementation is beyond my skills. Another wish would be Twital syntax like: <ul t:if="users">
<li t:for="user in users">
{{ user.name }}
</li>
</ul> |
@zmitic how would your syntax proposal work exactly? For example, how would you use it there? {% for index in 1..10 %}
.foo-{{ index }} {
z-index: {{ index }};
}
{% endfor %} |
Not a BC break, I would like to have the template path to be rendered in dev mode in the source code so that when inspecting the code in the browser, I can see the template of the block, similar to what Drupal does." <div>.....
<!-- @twig templates/components/button.html.twig -->
<button>
My button
</button>
......
</div> I know there is the toolbar, but I think it is more convenient to have this information when inspecting. Thanks |
you can use <!-- {{ _self }} --> |
Does that mean adding this manually to all files? And then remembering to remove it before committing to git, as I only want to display it in the development environment. |
@alinceDev the hard part about that is that Twig is not specific about HTML (if you render something else, using HTML comments will just break everything). And even in HTML, comments are not allowed in all contexts. So this is unlikely to go in the core. |
This could done in a third party package by wrapping the loader and prepend the template when the template contains an HTML tag. |
As someone who often switches from PHP to Python and back, I'd like to keep the Twig vs Jinja differences small for any future evolution, both in concept, syntax and implementation. I'm not sure what top 3 changes that might require, but I'm sure you can think of some based on current/future feature set of both... And since I sometimes have to deal with the same templates in Javascript as well, please keep twig.js up to date too :-) |
date filter that return null if value is null instead current date, as its much more error prone than null.
At the moment its possible to achieve this with a ternary operator but its much more logically if you just can chain the default filter |
|
I think this has already been mentioned earlier, but I'll still add my 2 cents. Something I miss is embed-style capabilities in a more local scope. I'd imagine doing this neatly would affect BC. Something like this but more thought through: {% embeddable Marquee %}
{# Same content as in a normal .twig file for embedding, so it's easy to move into a separate file if needed later #}
<marquee>
{% block content %}
Default content
{% endblock %}
</marquee>
{% endembeddable %}
{# Using same embed block as a classic embed, but with a named embed #}
{% embed _self.Marquee %}
{% block content %}
<blink>A blink inside a marquee!</blink>
{% endblock %}
{% endembed %}
{# Maybe even add macro-like import functionality, which would make them more or less replace macros #}
{% import 'my_embeds.twig' as Embeds %}
{% embed Embeds.Blink %}
{% block content %}
Blinky!
{% endblock %}
{% endembed %} |
Functions written in Twig that work like macros, but return a value instead of printing something. {% function restructure_data(data) %}
{% set output = { title: data.post_title } %}
{% if data.body is not empty %}
{% set output = output|merge({description: data.body}) %}
{% endif %}
{% return output %}
{% endfunction %} |
Add support for HTML "attribute" expressions. For example
Or at least add support in Parser/Lexer/Tokenizer to write Extension supporting this syntax - able to parse HTML and add more syntactic sugar. |
@cuchac Twig is not an HTML superset, it is a templating language. How would Twig be able to detect "HTML"? Would the following template be valid, and if not, how is Twig supposed to detect that the use of .foo twig:for="user in users" {
{{ user.name }}
} |
@ericmorand Hello, there are many examples of PHP template languages that supports such syntax. Many frontend developers prefer such "attribute" control statements. For example https://phptal.org/, https://latte.nette.org/, https://github.com/goetas/twital, ... Twig already knows about file type - it applies different escaping to variables in HTML and JS. I will happily write extension that supports such syntax, but as far as I know, there is no support for parsing context outside twig tags. Look what Twig UX Components had to do - https://github.com/symfony/ux/blob/2.x/src/TwigComponent/src/Twig/TwigPreLexer.php - they had to write complex custom parser to hack components syntax like Every extension that wants to use such HTML-dependent syntax would have to create custom parser, introduce many bugs and probably break other extensions. If internal tokenizer/lexer/parser will have support for HTML syntax, or some external extension will provide it with support from core, many valuable extensions can be created. For example let's close frequent XSS errors by activating JS escaping whenever |
That's my point: it would make Twig an HTML parser, opinionated in favor of just one syntax among the infinite possible things that Twig is able to output. Arguably, why not propose syntactic sugar for CSS - and thus make Twig a CSS parser too?
This is arguably not the purpose of Twig - or any templating language - to handle post-processing of this sort. We already have a fair amount of HTML post-processors - available for every technological stack existing - dedicated to achieve such things as detecting / fixing XSS issues. Don't get me wrong: in my opinion, the danger here is to end-up with an unfocused engine that tries to support everything. |
@ericmorand I'm not suggesting to make Twig HTML-only parser. CSS syntactic sugar would be great, same as JS and HTML syntactic sugar. But everything as extension, optional. That is the point of extensions. |
"it would be great if twig had an up-to-date formatter (maybe with a prettier plugin maintained by core team)" One vote for this. |
Actually https://github.com/VincentLanglet/Twig-CS-Fixer is the best option |
I think Twig-CS-fixer will fix coding standard issues in twig code, not format .html.twig files for web app and symfony UX components. Ex, this code will be fine for Twig-CS-fixer.
I know twig code is not "only" dedicated to render html, and can be used inside yaml or other, but I suspect most of twig usages fall into templating for html output inside web page or email. Each IDE's support is own opinionated plugin and set of rules for linting, indenting etc... (https://twig.symfony.com/doc/3.x/templates.html#ides-integration), so in a team with several developer and designer, it's almost impossible to be consistent. Anyway, not something that would lead to a BC break as stated in the subject for this issue. |
I'm 99.99% sure @VincentLanglet won't bite anyone adding a new rule to handle indentation levels :) |
He won't bite, but it seems that this is not trivial: VincentLanglet/Twig-CS-Fixer#47 |
I've added a reference to the tool in #4017 |
Changing the default value of the |
@MauricioFauth would not do that. I find the current solution in Symfony awesome. Strict Variables for Dev environment and on Prod no strict variables. Specially for Dynamic Systems like Content Managements templates devs forgot a lot of times to give all variables in into there includes templates as the reuse it on different parts and on strict variables the production side would end then in a 500 error. So think its currently a great balance with depending on require strict variables only on DEV environment. |
@alexander-schranz my experience with that is that disabling |
@alexander-schranz I'm also using it this way ( |
@stof Understand that, but think the best way would for prod would be |
possibility to render two templates at the same time. this requires that twig stops echoing strings, and instead collects them into a buffer, and stop using ob_start() .. etc. ref: #3599 |
We've started working on the next major Twig release. As announced last year, this new version will probably land under the Symfony mono-repository.
For the first time in Twig history, I'd like to fix the major issues that would be BC breaks and that we've never done.
This issue acts as a community wish list for things you want to see in the next major version that could lead to BC breaks (hint: like operators precedence).
Feel free to comment and vote.
The text was updated successfully, but these errors were encountered: