With php[-unicode], the mbstring extension is disabled: ... $(use_enable unicode mbstring ) ... Then: Dec 15 00:05:36 [apache2] PHP Fatal error: Call to undefined function mb_convert_encoding() in /blah/blah/blah/smarty/templates_c/bb509dfa0bfe4bbc28dbf912392f392ac9875736.file.header.tpl.php on line 69
Created attachment 392724 [details] smarty-3.1.21-r1.ebuild I'll revbump to fix this if no one objects. I've also cleaned up the usage instructions (now a lot simpler), and fixed the LICENSE which changed somewhere along the way.
The situation isn't as clear-cut as I thought. The mbstring detection in Smarty is automagic, at runtime. But if php[unicode] is present when someone visits your site, the cached template that is generated will use the mb_foo functions requiring php[unicode]. If you later reinstall php *without* USE=unicode, then all of those previously-generated templates will begin to crash. For that reason, I think it's best to require php[unicode] unconditionally. Here are the steps to reproduce: 1. Install PHP with the mbstring extension 2. Install smarty 3. Clear out your templates_c directory. 4. Restart apache 5. Visit your site, on a page that uses escaping 6. A cached template is stored in $smarty_dir/templates_c that makes use of mb_convert_encoding. 7. Reinstall PHP, this time without mbstring 8. Restart apache 9. Visit the same page 10. 500 error, missing mb_* functions.
Created attachment 392864 [details] smarty-3.1.21-r1.ebuild Added a comment to the ebuild's RDEPEND.
13 Jan 2015; Michael Orlitzky <mjo@gentoo.org> +smarty-3.1.21-r1.ebuild, -smarty-3.1.21.ebuild: Revbump fixing LICENSE and missing RDEPEND, bug #532618.
