In a post on the MODX forums a Forum user (Snow Creative) commented on the option to use plain variables instead of the getOption() method. This led to an interesting discussion of the pros and cons of the two methods that I thought was worthy of a blog post.
In my article, I used the example of a snippet that displayed a message next to new resources on the site. In the article, I suggested the following way to access variable values passed to snippets via the scriptProperties array:
$newOutput = $modx->getOption('showNew', $scriptProperties,
'<span class="new_resource">NEW!</span>', true);
But as Snow Creative pointed out, that's not the only way. Variables passed from a snippet tag also show up in snippets as already-set variables. This happens because when MODX processes snippets or plugins, it uses this line of code:
extract($scriptProperties, EXTR_SKIP);
(The EXTR_SKIP above tells PHP not to overwrite an existing variable if there is a collision.)
Since $scriptProperties is an associative array, the extract() function takes each element and creates a variable named for the key, set to the value. In other words, if you have this tag:
[[MySnippet? &size=`60`]]
In your code, there will be a variable named $size with the value 60.
This method will not set a value for $size if the user forgets to put that property in the snippet tag (getOption() will), or mistypes it, but you can check and set it yourself with code like this:
$imageSize = ! isset($size) {
$imageSize = 60;
} else {
$imageSize = $size;
}
This does in five lines of code what getOption() does in one, but you can also use the ternary operator to do it in one, like this:
$imageSize = isset($size) ? $size : 60;
There are some advantages to this method. For one thing, it's slightly faster, since it avoids the function call to getOption(), though the time difference is quite small. It also protects against a possible problem with getOption(). If the property is not set in the snippet tag, getOption() will look for a setting (a System, User, Context, or User Group Setting) with the same name, and it will use the value of that setting if it finds one.
On the other hand, it provides no method for handling a setting that is set, but empty. In some cases, you'd want to use that empty setting, in others, you'd want to use a default in that case. For example, a numeric value of 0 is considered empty, but might be valid for your snippet or plugin. The getOption() method handles this with its final (optional) argument. If it's true, it will use the default if the setting is set but empty, if it's false, it will use the empty value.
Doing this with the simple variable would mean more lines of code, and for me, it would be code that's more error-prone and difficult to understand. Something like this:
if (!isset($size)) {
$imageSize = 60;
} elseif (isset($size) && empty($size) {
$imageSize = 60;
// or
$imageSize = '';
} else {
$imageSize = $size;
}
The getOption() method would replace the code above with a single line.
Personally, I almost always use getOption(). I find it taxing to have to create specific code to do what I want with isset() and if(empty()). You may not.
I'm familiar with the available System Settings, so I can avoid using them as properties when I don't want the System, or other Setting to be used. If a property might duplicate a custom setting a developer has created, I use a prefix for the property, usually the name of the extra or a shorthand version of it followed by an underscore.
You will also find that in venerable MODX snippets like getResources and Wayfinder, and in much of the core code, getOption() is used to handle the $scriptProperties array, and other associative arrays.
Using getOption() also allows you, in a single line, to avoid a PHP error if the property has been removed or mistyped in the snippet tag, since in that case the local variable won't exist.
I recently had a CMP crash from something similar. Any displayed error will usually crash code that expects a JSON response. You could argue that setting error_reporting(0) would solve that, but I like to set it to E_ALL during development.
Also, using the local variables makes PhpStorm yell at me about using undefined variables unless I stop and create a PhpDoc comment telling it to shut up.
I have a live template in PhpStorm for creating the getOption() call, so I generally prefer doing that, but as with many things in MODX, it's a matter of personal preference.
Bob Ray is the author of the MODX: The Official Guide and dozens of MODX Extras including QuickEmail, NewsPublisher, SiteCheck, GoRevo, Personalize, EZfaq, MyComponent and many more. His website is Bob’s Guides. It not only includes a plethora of MODX tutorials but there are some really great bread recipes there, as well.