Smarty v6

[wisskid]

It's been 3 years since work on Smarty v5 started. Time to plan for Smarty v6! Work is already underway, but I'd like the input of the community on what you think we should add and what we should leave out.

Some highlights I'd like to propose:

1. Drop support for PHP <8.2 so we can strengthen the application with modern language features and possibly support the nullsafe operator Support nullsafe operator #1015
2. Prepare for PHP9 support Provide a wrapper for strftime (to be removed in PHP9) see PHP9 support (strftime) #810
3. Switch from nocache blocks and attributes to a native {cache}...{/cache} block see Who is using nocache? #853 and Drop support for {nocache} block and nocache attribute #1199
4. Drop support for $smarty.block.child as this will greatly simplify the application logic and prevents potential loops when used together with $smarty.block.parent
5. Switch to auto-escaping see Escape Html - turn on / set a true by default #863
6. Security strengthening by limiting what PHP code a template can call and centralizing security checks in one class Harden Security mode #1197
7. Make compiled template code portable across deployments by removing absolute filesystem paths, to support compiling templates using CI or other deployment strategies
8. Beautify compiled code so you could actually read and debug compiled template code if needed

Any thoughts? What would you like to see added to this list?

[pharixces]

I would like the ability to specify the priority of an extension (the higher the priority, the earlier an extension is being checked for a specific modifier/block/etc function). This way you can overwrite the internal functions with your own implementation if needed.

Maybe determine the corresponding extension for a modifier at compiletime instead of at runtime (now when a modifier is called it has to look trough all the extensions everytime iirc)

And maybe add a benchmark suite in CI so we can see what a release does for the performance of the engine? :D

[jonnybradley]

Nice idea, +1 for this

[marclaporte]

Thank you @wisskid for this initiative!

The Tiki community will help for testing as we did for Smarty 5: #920

[jonnybradley]

Absolutely, great to hear Smarty's planning for the future, thanks!

[matiasperrone]

I am totally onboard and I'd like to contribute

[Visualq]

Regarding the ideas Prepare for PHP9 support: I would advocate for deprecating the entire way Smary formats Datetime

Regarding the autoescaping, this is long overdue! These days it should be security first.

I would like to see the following added to the Smarty 6 codebase

Enforceable quality tooling

Introduce a mandatory quality pipeline containing, right from the start:

• PHPStan at level: max
• PHP-CS-Fixer using PER Coding Style 3.0
• Rector with an explicitly selected and reviewed rule set

A temporary PHPStan baseline may be needed during migration, but new violations should not be accepted and the baseline should only decrease over time. So basically this would mean the codebase is e.g. PHPStan level 5 but every new feature has to adhere to PHPStan level max.

New Rector rules should be introduced incrementally so that automated refactoring remains reviewable. Introducing Rector will also make supporting new major PHP versions a lot easier. We can also use Rector to validate the rendered templates.

Other ideas

• Perhaps can we introduce a migration flag/package to allow easier migration.
• Add PSR-6 / 16 to support a more general way of caching, templates aswell as partial templates. This could well support "Make compiled template code portable across deployments"
• Performance regression test suite