The Symfony Templating component provides the tools needed to build any kind of template system, including the loading of template files from multiple sources, monitoring them for changes and using multiple engines to render them.
In Symfony applications this component allowed using both PHP and Twig to create the templates. However, nearly all developers use Twig to create traditional templates or use the serializer to output data. That's why in Symfony 4.3 we've decided to deprecate the integration of the Templating component in Symfony applications.
This means that, starting from Symfony 5.0, we will remove support for using PHP
templates and PHP form themes. You'll need to use Twig for those templates. In
addition to deprecating several classes, services and service tags, the
hinclude_default_template configuration option has been moved to the
fragments section:
1 2 3 4 5 6
# config/packages/framework.yaml
framework:
# ...
- templating:
+ fragments:
hinclude_default_template: hinclude.html.twigAlthough the number of people using PHP templates in Symfony applications is minimal compared to Twig, if enough people would volunteer to work on an alternative solution, we'd consider the creation of a new PHPTemplateBundle that provides all the deprecated classes and support files. If you are willing to help, create an issue in the main Symfony GitHub repository to kick off the discussion around this.
Great news! 👍
Awesome...
That is unfortunate... we have long term migration plans for zend 1 projects to symfony and were planning to write a php template adapter for zend 1's phtml templates, this would be doomed now I suppose.
@Martin, we tried the same thing as you mention and eventually we got to the conclusion that it's better to just migrate to twig entirely (while migrating legacy app from ZF1 to S3).
For example, in order to support view helpers, you would have to recreate the magic from Zend or just drop their usage. We also had bootstrap 3 forms (with decorators, etc), so we had to load that "magic" of Zend forms into Symfony.
👍👍👍👍
I signed up for connect just so I could comment on this.
Why in the world would you remove PHP templating from a PHP framework? That is just the dumbest thing I have heard of.
Not everyone uses Twig. Why would you hitch your wagon to something that could go away or be replaced by the next new thing? Something that is so clearly a debatable choice for a development team. Use Twig if you like it, but if not PHP is always there - always has been.
Help write a package to support PHP in a PHP framework? For my team, it would probably be easier to just use a different framework. One that is not so opinionated.
I think this is a really stupid idea and I am disappointed that such a clearly one-sided decision was made.
@Justin if you used PHP templates in Symfony apps, we understand that you are upset about this proposed change. However, we made this decision consciously after asking lots of times to the community about their preferred language to create templates. What we've found is that the immense majority (in practice, almost all of them) use Twig.
Apart from that, what you said about Symfony being an opinionated framework is simply not true. In fact, Symfony is by far the less opinionated PHP framework. You don't have to take my word for it. Just look around the other frameworks and you'll quickly come to the same conclusion.
For example, you can configure Symfony using PHP, YAML or XML (YAML is only used by default for convenience; but everything is configurable with PHP and XML too). Meanwhile, other frameworks dictate the format you have to use to configure them. That's what being opinionated is all about.
We use EngineInterface render() to render some sections of templates and forms, for example when the form fields need to change/be dynamic based on some advanced criteria. We're now getting the deprecation warning.
Does this now mean that we have to use render( controller( ... ) ) from within the Twig template every time? Every time I use this it feels wrong as I feel it undermines MVC principles.
@Justin - we first tried to do everything in PHP and eventually realised that it would have been a lot easier to just use Twig, so we made the decision to rewrite all the templates. It is hands down much better - give it a try, you won't regret it.
Even though we're also using Twig in the company I work at, I get where Justin Bane is coming from. Now, the possibility of implementing a different template engine gets removed, so if ever a better templating engine comes along and we want to implement that, we're stuck with twig with no option to switch to something else.
I get that maintaining support for different types of engines requires effort that could be put into other things, but would it be such a bad thing to leave the option open for people to add their own templating engine?
@Rachel The option is still open. We are not removing the possibility to use another templating engine. Using a "new" templating engine also means supporting it throughout the framework (Forms, ...), which is a lot of work (the current Form framework integration for the PHP template engine has not changed in the last few years, whereas we had a lot of activity on the Twig one).
@fabpot I'm willing to help to rewrite a PHP template engine. Where should I start and who can guide me through the process?
I really like Symfony, but I really don't want to learn a new language (twig) for me or my team. As @Justin said, "Why in the world would you remove PHP templating from a PHP framework?"
We already have a PHP template engine (Templating component, which is still here and stable). What we removed is the integration with the framework as it was not maintained and not used.
I suppose you can still use whatever templating engine you want, you'll just have to integrate it into the framework yourself (or have a team to do it) which is fine. I changed my mind about this, I think it's a good change. If enough people still want to use PHP templating anyway, it will most likely come back eventually, just maintained by different people.
@fabpot Where should I start to implement this integration with the framework?
@Javier, actually you're wrong. I moved from Zend to Symfony with a job change and have found that Symfony is far more opinionated than Zend; even more so with Zend Expressive. I have always loved how flexible Zend allowed you to be - even as much as completely customizing the structure of the project (package by feature anyone?). The cost has always been "magic", which is what Symfony offers. Convenience and opinion come hand-in-hand, it seems.
This kind of change is ¯_(ツ)_/¯ but I really need more information about the alternative. What's the alternative to 'templating.name_parser' or 'templating.locator'? The deprecations just say "use Twig". Is that '@twig'? I'll be digging in the framework source to figure it out but deprecations in Symfony are rough.