MODX Staff
$out= "<p>This is a test of nesting content in a snippet.</p><pre>[[++site_name]] [[++site_url]]</pre>"; return $out;
<?php
function script8_0_1($scriptProperties= array()) {
global $cms;
if (is_array($scriptProperties)) {
extract($scriptProperties, EXTR_SKIP);
}
$out= "<p>This is a test of nesting content in a snippet.</p><pre>[[++site_name]]
[[++site_url]]</pre>";
return $out;
}
?>
...
if ($instanceResult= @ include_once($this->scriptFileName)) {
$this->instanceOutput= $scriptName($this->instanceProperties);
...
MODX Staff
I chose the wrapper function because I read in the PHP docs today that you in fact can define classes and functions inside of functions, which I previously was not aware of. That’s actually very cool, and helped produce what I think is a fairly elegant and robust alternative to eval(). In fact, I think the wrapper function is an added security benefit, as it also protects the globals and locals from the class method in which it is being included. The one drawback is that it will allow access to all properties and methods of the Element class, but I cannot come up with a scenario where this would be a vulnerability or disadvantage; in fact it might bring into play some very interesting design possibilities when adding a robust event structure in place, since PluginElements extend the functionality of ScriptElements and will also make use of this feature.
I do have one question though. Why have a wrapper function in the include file? Why not just have a if not in MODx die line at the top of the file. I just wonder if the wrapper function wouldn’t cause headaches with variable scope and other things. Can you define classes inside of functions?
If you were to ditch the wrapper function I suppose you’d have to use output buffering or $modx->output or something like that. I’m not convinced either way but I thougt I’d throw it out as food for thought.
I thought about this, but what harm is there in calling such a script directly (they are in script files with obscure names based on various primary keys in the object model? All it does is produce the function, which could be called only out of context and would simply not work without the surrounding class structure. The whole system depends on one single global element, $cms, and this is essentially assurance that nothing can be done anywhere in the class structure without a valid $cms instance. But I’m no security expert...so I could be overlooking something important here
The one thing you want to be especially careful of is that someone couldn’t call the php file directly and that you couldn’t get at the source code by having it in a non-php file.
MODX Staff
I chose the wrapper function because I read in the PHP docs today that you in fact can define classes and functions inside of functions, which I previously was not aware of.
I thought about this, but what harm is there in calling such a script directly (they are in script files with obscure names based on various primary keys in the object model? All it does is produce the function, which could be called only out of context and would simply not work without the surrounding class structure. The whole system depends on one single global element, $cms, and this is essentially assurance that nothing can be done anywhere in the class structure without a valid $cms instance. But I’m no security expert...so I could be overlooking something important here
MODX Staff
And since the new API will be completely OO I’d assume that there will be a lot less varriables floating around that would have to be accessed by a snippet and more object properties and methods would be able to be used (for instance being able to define a new instance of the language object instead of counting on a $_lang variable), so scope should not be such an issue.
