It'd be better if you told us why you are using Smarty in the first place. I suspect a lot of places use it simply because they've heard a lot of other places use it.
My company also uses Smarty, but we're planning to move away from it. (Currently evaluating Mustache.php)
Smarty's parser/lexer is horribly slow. The 3.1.x branch has caused problems for us, such as corrupted compiles and broken nested blocks [1]. As evidenced by the article, the developers don't seem to know what they're doing. You should see the workaround for people with custom error handlers -- registering another error handler on top that checks the source of the error against registered template and cache directory paths!
sounds about right. I don't think anyone would choose Smarty for actual technical reasons at this point. I personally think plain PHP makes a far superior templating system. Smarty is slow, doesn't "protect" designers from any complexity because it's complex itself and is yet another thing to learn.
Otherwise PHP itself is a template language. That is why you start it with <? tag.
Just keep short tags on [it's off by default on new installations but ON by default on all hosting sites] and you got a better template engine than smarty.
PHP does not support HTML escaping and is therefor not secure by default. At least twig escapes HTML by default (I am not up to date with PHP so the others might too).
You do not want to type <?php echo htmlspecialchars($var, ENT_QUOTES) ?> every time you want to output data. (Yes, I know it could probably be written shorter but my PHP is rusty. My point still remains though, you have to remember to type it every time.)
I think my solution back in the day was just to include the template files by running a function, something like showTemplate($templateName, $templateVars). The function takes an array as an arg so only these values are available to the template context (apart from the many global vars of course).
You can then run this entire array through htmlentities or htmlspecialchars before doing include().
this is exactly how many modern frameworks do it. your response body is assembled and cached as your application executes, along with any variables it needs, and before the template is rendered the variables are sanitized.
I think it's good this way, it forces the developer to think about the implications of escaped vs unescaped output. The way I see it, having htmlspecialchars/htmlentities applied automatically by a template engine is a close relative to the magic quotes; it abstracts something esential for the developer to know.
