CiviCRM Community Forums (archive)

We ran into a problem where Smarty wouldn't seem to create new directories or compiled templates in templates_c.

So for instance, just deleting all the contents of templates_c (a recommended solution to some problems) would result in most of CiviCRM just not rendering correctly and absolutely nothing new being created within templates_c.

If we kept templates_c as it was, most pages would render OK but a few would render improperly, with the main part of the page not showing up at all.

It turned out that those were the pages that didn't have a subdirectory already created under templates_c to hold their compiled template file.  So when Smarty would try to create a new template and then create a new subdirectory of templates_c to store it in, the process would fail (silently, unfortunately) and we were left wondering why those pages just didn't work.

I first thought of permissions problems but after chmodding everything under templates_c to 777 there was still no effect.

It turns out the problem was the Smarty uses open_basedir to determine whether or not it can create a specific directory (see core.create_dir_structure.php under the Smarty subdirectory).

In our hosting environment, for whatever reason, open_basedir didn't include the main html directories (even though php can indeed create directories there, no problem).  So even though Smarty could create directories there, it was using open_basedir to erroneously figure out that it *couldn't*, and then not even trying.

Solution was to add a value to define open_basedir in the main .htaccess file:

php_value open_basedir /nfs:/tmp:/usr/local:/etc/apache2/gs-bin:/home/00000/domains/ourdomain.com/html/:/home/00000/data/tmp/
The first part (/nfs:/tmp:/usr/local:/etc/apache2/gs-bin) is the open_basedir as defined by default on this host.  The rest is the part we added to allow Smarty to create directories.  The 00000 and ourdomain.com parts are specific to our account.  (This could be narrowed down to improve security, I presume.)

I think open_basedir can also be defined in php.ini rather than .htaccess, though I haven't tried that.

You can check what open_basedir to on your system with a bit of code like this:
<?php
        echo ini_get('open_basedir');
?>
If you're using open_basedir (ie, it's non-empty), your templates_c directory must be a subdirectory of one of the paths given in open_basedir.  More info about open_basedir here and info from the Smarty forums here.

This is in CiviCRM CiviCRM 3.2.0, which uses Smarty ver 2.6.26, all under Drupal 6.19.

Interesting.  From the way I am reading this, it sounds like you might want to report this to smarty as well?

Yes, it's definitely a flaw in Smarty.  I don't know how you'd really want to do this in the ideal world, but definitely not this way.  However, the approach would work if php's open_basedir setting worked as advertised (ie, that php can open/change any file unless it's listed in open_basedir).  So it may be somewhat unusual that in our hosting setup, open_basedir is used but doesn't include some paths that php can, indeed, access.

Also when it happens, there is no error reporting--it just silently fails.  Makes it a bit tough to track down.

FWIW, Smarty says this: Note, if you are using open_basedir then template_c (and/or cache) must exist in a path reachable with that setting.

Yes, we're on mediatemple as well, so it might be some quirk of their gridserver thingamajig.

Where in the htaccess file did you add this line?

Thanks,
Josh