CMSMS 1.12: why change Smarty {config_load} directory?

[fredp]

Hi dev team,

After upgrading a CMSMS 1.11.12 test site to CMSMS 1.12, I was surprised to find that my Smarty "config files" stopped loading on all {config_load} tag calls in templates and spreadsheets.

I investigated and found something curious on line 96 of lib/classes/class.Smarty_CMS.php:

Code: Select all

 $this->setConfigDir(cms_join_path($config['root_path'],'tmp','templates'));

So, it seems that all Smarty config files must be moved to the tmp/templates directory. I'm curious why it is better to require that config files be put there, rather than in the existing tmp/configs directory. What was the motivation for this change?

Once again, thanks for all your hard work!

[calguy1000]

The config dir was specified to tmp/templates in 1.11 when we upgraded smarty versions.

[fredp]

The config dir was specified to tmp/templates in 1.11 when we upgraded smarty versions.

Thanks for the quick reply. I see now that the change to tmp/templates is only part of the picture.

Since CMSMS' upgrade to Smarty 3, I've been using Smarty.net's recommendation of putting config files outside of the document root:

$config_dir
This is the directory used to store config files used in the templates. Default is ./configs, meaning that Smarty will look for the configs/ directory in the same directory as the executing php script.

Technical Note
It is not recommended to put this directory under the web server document root.
...

This, however, stopped working in CMSMS 1.12 because absolute paths are no longer allowed in template resolution (see SVN 9842 & 9843). Thus, Smarty code like this now fails:

Code: Select all

{config_load file="/home/username/.mysite.conf"}

I expect absolute paths will remain off-limits, so I decided to learn more about CMSMS-specific Smarty config directories under doc. root. I looked in the CMSMS documentation, release notes, and 1.1[12].x changelogs but didn’t find anything indicating which directories to use. So, I reviewed lib/classes/class.Smarty_CMS.php in more detail.

It seems that while admin pages must use Smarty's default config directory, tmp/configs, for config files (line 135), front-end pages must use tmp/templates for Smarty config files (line 96). I couldn't find an explanation for this curious front-end-only customization or why overloading the tmp/templates directory is a good thing. I can only guess--was the intention to block module developers from using the same Smarty config file for front-end and admin pages?

For now, I can live with the tmp/templates customization. But, I implore the dev team to reconsider these implementation choices. Smarty config variables are an important language feature, but you're making the learning curve steeper for new users trying to use Smarty in CMSMS--you've blocked Smarty users from using both Smarty.net's recommended config dir location (outside doc. root) and the Smarty default location (tmp/configs) and, unless I missed something, haven't documented where users (or module developers) should put their Smarty config files.

[markS]

Hello,

I've just been upgrading some of the cms I look after to 1.12 and I think I've run into a related issue with this too, but this is on the admin side.

In a few of the custom modules I've created I've extracted a form into its own template and used a smarty include so that it can be used in multiple places, seems a sensible use of templates and minimises the places I need to edit if changes need to be made.

In the php I'll do something like:

Code: Select all

$smarty->assign('templatePath', dirname(__FILE__)."/templates");

or 

$smarty->assign('templatePath', "./templates");

and then in the outer template I'll call the form template like:

Code: Select all

{include file="$templatePath/admin_entry_addedit_form.tpl"}

In 1.12 this now throws an error. Full or relative paths, it doesn't appear to matter.

Is this a bug? Is this deliberate? Is there a workaound I can apply that doesn't involve me re-adding the inner template in all the places I've already taken it out of?

Thanks for any insight you have on this.


Regards,
Mark.

[Jo Morg]

In 1.12 this now throws an error. Full or relative paths, it doesn't appear to matter.

Is this a bug? Is this deliberate? Is there a workaound I can apply that doesn't involve me re-adding the inner template in all the places I've already taken it out of?

It is as designed. Nothing outside the allowed template directories should be accessed from the templates themselves as it is a security risk. There are however legitimate methods available to module developers to access other directories from their own modules and modules' templates: Custom Template Resources.
This would allow the inclusion of templates from other paths without direct access to the file system from the template itself.
As an example, after registering a template resource mytemplates the inclusion line would be like:

Code: Select all

{include file='mytemplates:admin_entry_addedit_form.tpl'}

Where these templates are stored is handled by the custom resource class, and can be virtually anywhere...

[markS]

Hello,

Thanks for the response. I appreciate what's been done but it appears a bit harsh to prevent access to a template resource from the same folder as the enclosing template, no? I mean that module template folder is obviously trusted enough to be able to be used in a ProcessTemplate call, but not to be used for an include. I must admit I don't get the logic.

Anyway, I've taken a look at the custom template resource information you linked to but I'm unable to get it working within the context of the cms.

Currently it always returns an error along the lines of: Unable to load template mytemplate 'template_name.tpl'

Do you know if any part of the cms implements something like this or of any modules which need to do the same thing - it's always useful to see a working example.


Regards,
Mark.

[Jo Morg]

I appreciate what's been done but it appears a bit harsh to prevent access to a template resource from the same folder as the enclosing template, no? I mean that module template folder is obviously trusted enough to be able to be used in a ProcessTemplate call, but not to be used for an include. I must admit I don't get the logic.

The module template folder is trusted and can be included in other templates by using a CMSMS own custom resource which can be called like this:

Code: Select all

{include file='module_file_tpl:<module_name>;<template_name>.tpl'}

Replace, of course, <module_name> and <template_name> by the respective names. No need to access other directories.
Additionally you can access the <cmsms_root>\tmp\templates\ for additional templates called like this:

Code: Select all

{include file='file:<template_name>.tpl'}

Anyway, I've taken a look at the custom template resource information you linked to but I'm unable to get it working within the context of the cms.

Currently it always returns an error along the lines of: Unable to load template mytemplate 'template_name.tpl'

Do you know if any part of the cms implements something like this or of any modules which need to do the same thing - it's always useful to see a working example.

Yeah, because of the limitations of LI2 (which needed a workaround) and given the fact that EasyList, being a fork of LI2, had the same issue, needed to use it's own template resource.
The code is a not much modified version of CMSMS own resource module_file_tpl:

Code: Select all

<?php
/**
* This class defines a new template resource
* and is basically based on the core own
* CMSModuleFileTemplateResource and CMS_Fixed_Resource_Custom
* CMS_Fixed_Resource_Custom fixes some weird stuff in smarty
* but as these are internal core classes, we just copy the code 
* and adapt it to our needs
* 
* Jo Morg 
*/
class EasyListTemplateResource extends Smarty_Resource_Custom
{
  /**
  * a fix to resolve an issue with smarty
  * 
  * @param Smarty_Template_Source $source
  * @param Smarty_Internal_Template $_template
  */
  public function populate(Smarty_Template_Source $source, Smarty_Internal_Template $_template = null)
  {
    $source->filepath = $source->type . ':' . $source->name;
    $source->uid = sha1($source->type . ':' . $source->name);

    $mtime = $this->fetchTimestamp($source->name);
    
    if ($mtime !== null)
    {
        $source->timestamp = $mtime;
    }
    else 
    {
        $this->fetch($source->name, $content, $timestamp);
        $source->timestamp = isset($timestamp) ? $timestamp : false;
        if( isset($content) ) $source->content = $content;
    }
    
    $source->exists = !!$source->timestamp;
  }
  
  /**
  * Our mechanism to deal with the templates
  * for the instances
  * 
  * @param mixed $name
  * @param mixed $source
  * @param mixed $mtime
  */
  public function fetch($name, &$source, &$mtime)
  {
    $source = null;
    $mtime = null;
    $params = preg_split('/;/', $name);
    if( count($params) != 2 ) return;

    $config = cmsms()->GetConfig();
    $files = array();
    $files[] = cms_join_path($config['root_path'],'module_custom',$params[0],'templates',$params[1]);
    $files[] = cms_join_path($config['root_path'],'modules',$params[0],'templates',$params[1]);
    $files[] = cms_join_path(EASYLIST_TEMPLATE_PATH, $params[1]);
    
    foreach( $files as $one ) 
    {
      if( file_exists($one) ) 
      {
        $source = @file_get_contents($one);
        $mtime = @filemtime($one);
        return;
      }
    }
  }
} // end of class
?>

Rename the class, include the file on the constructor of one of you modules and register it like:

Code: Select all

cmsms()->GetSmarty()->registerResource('mytemplates', new <myTemplateResourceClassName>() );

Adapt it to your needs, and don't forget to rename <myTemplateResourceClassName> to whatever the class is named.
And have fun.

[markS]

Hello,

Many thanks for the quick response. I'll take a look at the code and see where I went wrong!

Regards,
Mark.

[fredp]

That was an interesting digression regarding templates, but to get back to my original topic, Smarty config files, let me give a simple example to clarify:

On a CMSMS 1.11.12 site, my first CMSMS stylesheet contained the following:

Code: Select all

[[$cfgpath=cms_join_path(realpath(dirname($smarty.server.DOCUMENT_ROOT)), '.mysite.conf')]]
[[if ! #css_rev#]][[config_load section='css' file=$cfgpath scope='parent']][[/if]]
/* [[#css_rev#]] */

This would load the 'css' section of my Smarty config file and make those variables available for subsequent stylesheet processing by Smarty. This worked for both frontend pages and for backend pages (e.g. editcontent.php w/TinyMCE).

After upgrading to CMSMS 1.12, I moved .mysite.conf to $config['root_path']/tmp/templates/ and removed the file path from the [[config_load]] statement in my first stylesheet. Smarty, however, failed to find .mysite.conf in $config['admin_dir']/configs/, which then caused modules/TinyMCE/stylesheet.php to fail to properly load stylesheet information into the, now, not-so-WYSIWYG editors.

I did come up with the following workaround steps to get TinyMCE working again:
1) Create the missing directory $config['admin_dir']/configs/
2) Put a link/symlink to tmp/templates/.mysite.conf into the admin/configs directory

While this works, it appears overly complicated, error prone, and less secure. Perhaps the advantages of the recent "config dir" changes are worth it. I don't know. Without knowing the original design goals, it's hard for me to even suggest alternative implementations.

Generally, I try to follow "Einstein's Razor": Make things as simple as possible, but not simpler. So, I'm asking for dev team to reevaluate their implementation choices regarding Smarty config directories and see if there might not be simpler solutions available.

Hope this helps,
--Fred P.

[Jo Morg]

That was an interesting digression regarding templates

Two consequences of the same bug fix. And it was a bug fix that made security better rather than worse.

document root:

$config_dir
This is the directory used to store config files used in the templates. Default is ./configs, meaning that Smarty will look for the configs/ directory in the same directory as the executing php script.

Technical Note
It is not recommended to put this directory under the web server document root.
...

This, however, stopped working in CMSMS 1.12 because absolute paths are no longer allowed in template resolution (see SVN 9842 & 9843).

This was a needed change and, in terms of security, I can understand that Smarty technical note in systems exclusively driven by Smarty (where there is no real CMS script involved) since these files can contain sensitive info that shouldn't otherwise be accessed. In the CMSMS environment storing sensitive information in smarty configuration files doesn't make sense and the Tech Note doesn't apply.
I don't use TinyMCE (and hardly ever use MicroTiny) so I can't say I have experienced issues like that in WYSIWYGs, however the fact that that workaround worked was because it was preying on a bug, or a security whole. Happens on some circumstances and I've seen it in modules development too.
I'm not even sure that it was the right solution for the problem or if there any or better ones.
We may, eventually think of letting users define an extra config entry for the location of one extra Smarty path for config files or for templates, but I'm also not sure this is the correct solution.

Just to lighten up the topic a bit:

Generally, I try to follow "Einstein's Razor": Make things as simple as possible, but not simpler.

This could never be verified as an Einstein paraphrase ... maybe because simpler than possible is, well... impossible?! (I'm joking; I simply could not resist...)

Back to serious:
I'm not sure why would you want to use $config['admin_dir']/configs/... it should always be tmp/templates in any circumstance... and if this doesn't work with TinyMCE, it should probably considered as a bug in this module, not an issue with CMSMS core.

[fredp]

Thanks for your reply. I appreciate your considering and discussing this matter. I think, however, you misunderstood my earlier post(s). I suspect we agree more than disagree.

...
I'm not sure why would you want to use $config['admin_dir']/configs/... it should always be tmp/templates/ in any circumstance... and if this doesn't work with TinyMCE, it should probably considered as a bug in this module, not an issue with CMSMS core.

First, I do not "want to use" $config['admin_dir']/configs/.
Second, perhaps the intention was that tmp/templates/ always be used, but that is not the case. As I indicated in an early post, if you compare line 96 to line 135 of lib/classes/class.Smarty_CMS.php, then you will see that admin pages specify a different Smarty config directory:

Code: Select all

if(cmsms()->is_frontend_request()) {
  $this->setTemplateDir(cms_join_path($config['root_path'],'tmp','templates'));
  $this->setConfigDir(cms_join_path($config['root_path'],'tmp','templates'));
...
else if(cmsms()->test_state(CmsApp::STATE_ADMIN_PAGE)) {
...
  $this->setTemplateDir(cms_join_path($config['root_path'],$config['admin_dir'],'templates'));
  $this->setConfigDir(cms_join_path($config['root_path'],$config['admin_dir'],'configs'));;

Let me restate my concerns in the form of questions for the dev team:
1) What is gained by CMSMS specifying two different Smarty config directories for frontend and backend?

2) Why is tmp/templates a better location for Smarty config files than the Smarty default location of tmp/configs/?

3) How should new users to CMSMS determine where they should put their Smarty config files?

...
I'm not even sure that it was the right solution for the problem or if there any or better ones.
We may, eventually think of letting users define an extra config entry for the location of one extra Smarty path for config files or for templates, but I'm also not sure this is the correct solution.

Fair enough. Again, thanks for your input! My concern here is that the current implementation may have introduced unintended complexity. If, however, this complexity is itself by design--best solution to solve a problem or meet some goal--and not an unintended side effect, then I have little issue with it other than that it should be documented so that new users know what to do.

...just trying to help keep the "Simple" in CMS Made Simple.

edit: code formatting

[Jo Morg]

I think, however, you misunderstood my earlier post(s). I suspect we agree more than disagree.

Apparently .
I see your point, from your last post, and I'll try to figure out if there is any gain from the different Smarty config directories for frontend and backend. I'll get back to this thread soon.

..just trying to help keep the "Simple" in CMS Made Simple.

All constructive contributions are most welcome.