View previous topic :: View next topic |
Author |
Message |
huh Smarty Rookie
Joined: 13 Dec 2011 Posts: 5
|
Posted: Wed Dec 14, 2011 3:47 am Post subject: Do Not Create Compiled Files |
|
|
Perhaps a continuation of this thread...
http://www.smarty.net/forums/viewtopic.php?p=64673
I'm in a situation where I'd like to distribute a project I'm working on. The project includes Smarty as the main templating engine. During the initial installation of the application I cannot assume that permissions will be correctly configured. I would like to configure it so that during the installation process compiled templates are not written as files to a directory.
In reference to the similar thead I linked above, can anyone confirm that solution is still valid or actually works for them? I tried the above solution by registering a resource type with the extended class, but that does not seem to make compiled files not be written.
I'd like to not have to actually modify the Smarty source to work around this problem. I originally abstracted a templating class in my own project so templating engines other than smarty could be used for the install process due to it forcing to write to disk like this. I'd like to strictly use Smarty for all templating aspects, but how do I work around this issue? |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Wed Dec 14, 2011 2:45 pm Post subject: |
|
|
The problem is that PHP needs to read its files from the file system. eval()ing is a huge performance problem, and security issue, so that isn't really a solution either.
That said, PHP 5.1 introduced two new streams, php://memory and php://temp. You might try one of those and see what kind of luck you have with it. php://temp will write files to memory and after a certain size start using the disk. php://memory will write everything to memory.
So something like:
Code: | mkdir('php://memory/templates_c');
$smarty->setCompileDir('php://memory/templates_c'); |
This is not tested nor recommended, it is just an idea The BEST solution IMHO is to have your installer test the directory permissions and alert the person installing that they need adjusted. Much like most other apps do such as wordpress. |
|
Back to top |
|
huh Smarty Rookie
Joined: 13 Dec 2011 Posts: 5
|
Posted: Thu Dec 15, 2011 2:19 am Post subject: |
|
|
mohrt wrote: |
That said, PHP 5.1 introduced two new streams, php://memory and php://temp. You might try one of those and see what kind of luck you have with it. php://temp will write files to memory and after a certain size start using the disk. php://memory will write everything to memory.
So something like:
Code: | mkdir('php://memory/templates_c');
$smarty->setCompileDir('php://memory/templates_c'); |
This is not tested nor recommended, it is just an idea
|
Unfortunately it seems that both php://memory and php://temp do not support several functions used within the Smarty_Internal_Write_File class (For example, mkdir() isn't even supported).
http://php.net/manual/en/wrappers.php.php
A memory stream for this would be really nifty if it would work though.
mohrt wrote: |
The BEST solution IMHO is to have your installer test the directory permissions and alert the person installing that they need adjusted. Much like most other apps do such as wordpress. |
Well, the installation page does warn you if the permissions are incorrect. You cannot proceed until it is fixed. The problem is that I'm maintaining a separate template system simply to get to the point where I can do this check. I'd like to get rid of this dependency and only worry about one templating system.
I'm contemplating just setting up a temporary directory in whatever sys_get_temp_dir() returns, and just using that until permissions are confirmed. I'm guessing the only time this would be problematic is on shared/hosted servers where permissions might be tight...I'm not sure. That is an unlikely scenario for what I'm writing though. |
|
Back to top |
|
huh Smarty Rookie
Joined: 13 Dec 2011 Posts: 5
|
Posted: Fri Dec 16, 2011 7:32 pm Post subject: |
|
|
mohrt wrote: | The problem is that PHP needs to read its files from the file system. eval()ing is a huge performance problem, and security issue, so that isn't really a solution either.
|
I ended up looking at the Smarty code and I was able to get it to not write compiled files by editing a few lines in smarty_internal_template.php and smarty_internal_templatebase.php. I added a variable to toggle it from the main smarty class. So essentially for the install I can then do "$smarty->compile_write_files = false" (defaults to true) until the checks are done.
Admittedly, the template I used to test was somewhat simple. So I still have to test a bit to make sure I haven't overlooked something. I'm not familiar with the Smarty code so I could have overlooked something trying to wrap my head around it.
The compiled vs non-compiled execution time is not very noticeable in my scenario. In a template that isn't very complex there was an average execution difference of roughly .04 seconds compared to writing compiled files. As far as security goes, what exactly is the difference between eval'ing the compiled code vs using include on the compiled code? I would think the end result and concerns would be the same? Perhaps I'm overlooking something glaring. |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Fri Dec 16, 2011 7:49 pm Post subject: |
|
|
google for php eval, you'll see plenty of info on the subject. I don't think there is any security issues per se, but I try to avoid using it. |
|
Back to top |
|
huh Smarty Rookie
Joined: 13 Dec 2011 Posts: 5
|
Posted: Sat Dec 17, 2011 7:14 pm Post subject: |
|
|
I know the general issues regarding eval, but in the context of the Smarty code it doesn't seem to me that it would be any less secure.
If it's a configurable option, and the default is set to write the compiled files, then I think it would be a nice option for a developer to have in certain scenarios, such as distributed software that includes Smarty as the templating solution of choice.
Anyways, in case anyone else is interested here is the patch I have. It seems to work fine for me so far. Not sure if I'm missing anything yet or if everything is in the right spot or done how it should be, as I've been a little busy. This is against the latest stable version of smarty (3.1.6)...
Patch Link |
|
Back to top |
|
rodneyrehm Administrator
Joined: 30 Mar 2007 Posts: 674 Location: Germany, border to Switzerland
|
Posted: Sun Dec 18, 2011 2:44 pm Post subject: |
|
|
A very simple solution to your problem would be to extend the internal file resource and simply make it recompiling:
Code: | require_once '…/Smarty.class.php';
class EvaledFileResource extends Smarty_Internal_Resource_File {
public function populate(Smarty_Template_Source $source, Smarty_Internal_Template $_template=null) {
parent::populate($source, $_template);
$source->recompiled = true;
}
}
$smarty = new Smarty();
$smarty
->setTemplateDir('./templates')
->registerResource('file', new EvaledFileResource());
$smarty
->assign('foo', 'hello world')
->display('test.tpl'); |
So there is really no need to touch smarty core code… _________________ Twitter |
|
Back to top |
|
huh Smarty Rookie
Joined: 13 Dec 2011 Posts: 5
|
Posted: Tue Dec 20, 2011 2:41 am Post subject: |
|
|
rodneyrehm wrote: | A very simple solution to your problem would be to extend the internal file resource and simply make it recompiling:
Code: | require_once '…/Smarty.class.php';
class EvaledFileResource extends Smarty_Internal_Resource_File {
public function populate(Smarty_Template_Source $source, Smarty_Internal_Template $_template=null) {
parent::populate($source, $_template);
$source->recompiled = true;
}
}
$smarty = new Smarty();
$smarty
->setTemplateDir('./templates')
->registerResource('file', new EvaledFileResource());
$smarty
->assign('foo', 'hello world')
->display('test.tpl'); |
So there is really no need to touch smarty core code… |
Thanks! That's exactly what I was trying to do to begin with Instead of looking at the main code I guess I should've looked closer at the resources classes. The only thing I'd be potentially concerned with is this solution breaking again down the road sometime.
But that really lets me simplify the templating in my project quite a bit.
Thanks again. |
|
Back to top |
|
|