Upgrade to Smarty4....
Now that we have upgraded many sites to Smarty3 & seem close to ironing out the issues I had a go at Smarty4 and was able to get it working. The extra fixes were entirely in our core compatibility layer so the challenges of moving a site from Smarty2 to Smarty4 are now equivalent to moving to Smarty3.
https://smarty-php.github.io/smarty/5.x/upgrading/#removed-php-constants
One annoying thing we did was name our Smarty mixin & the define in a version specific way. In fact there is nothing v2 specific about our mixin and the methodology of defining CIVICRM_SMARTY3_AUTOLOAD_PATH
works for Smarty4 as well as it does for Smarty3. If it wasn't for those naming issues I would recommend we simply replace the contents of packages/smarty3 with the Smarty 4 library.
However, given where we are I recommend we
- merge Smarty4 into packages here https://github.com/civicrm/civicrm-packages/pull/380
- add a new define
CIVICRM_SMARTY_AUTOLOAD_PATH
- respect it but fall back toCIVICRM_SMARTY3_AUTOLOAD_PATH
if present - update our demo sites / build sites etc to Smarty4
- update all our messaging to encourage people to use Smarty4 not 3 (but if they have already switched to 3 don't further message as being off Smarty2 is enough to flush out any extension or issues that would impede our medium term plans to put Smarty4 in vendor & stop shipping Smarty3
Note that Smarty4 hard-fails on {php}
tags in tpls whereas Smarty3 has a backwards compatibility layer that would have supported it, had we chosen to enable it, which we didn't.