Settings are site-wide variables that can be used by either the MODx Core or by 3rd-Party Components to provide site, context, or user-level customization. The trick here is the override behavior that applies in the hierarchy: Contextual Settings (if present), override any of the System Settings. User Settings (if present) override any of the Context or System settings obeying the hierarchy of System -> Context -> User
See the following for more information:
They can be referenced at any point via their Tag, for example, for the 'site_start' Setting:
The hierarchy to remember is:
Let's say I set the System Setting named 'use_editor' to 0. However, I created a Context Setting called 'use_editor' for the 'mgr' context and set it to 1. This would mean that any time I'm in the mgr context, the setting would be 1, overriding the System Setting.
Further, I've got a user named 'johndoe' who I don't want to use the editor. I create a User Setting 'use_editor' for his user and set it to 0. Now, John Doe's "use_editor" setting will be 0, overriding the Context Setting.
Settings can also be specific to Namespaces, as well. This allows you to easily group your settings for each of your different Components.
Getting settings is simple in MODx Revolution; simply use getOption. For example, to get the setting 'site_start', simply:
Now, all settings are overridable by Context and User, as described above, and getOption respects that. So, if in the above code example, if you had set site_start as a Context Setting that overrode the System Setting, getOption will respect that - but only if you're executing the PHP in that Context that has the Setting.
For example, if I were using that code block in a Context called 'boo', and I had added a Context Setting for site_start in the 'boo' Context, and set it to 3, the above code would output '3'.
Now if I were in the 'web' context, and site_start was still '1' (from the System Setting), getOption would return 1.
getOption supports 3 parameters:
1. The key of the setting
2. An array to search first before looking for the setting
3. A default value should the setting not be found.
So, for example, if I were in a Snippet and wanted some default properties at the top, I could use getOption. Snippets automatically pass in an array of all the Properties attached to that snippet (or specified in the Tag call) via the $scriptProperties array. So, you can use that array to check for default properties. This example sets a default value to the 'showPublished' property should it not be specified:
Now, assuming the Snippet doesnt have showPublished as a default property, if you called the Snippet via the tag call:
showPublished will be set to true. If it did have the default Property attached to it that set the value to 0, or the showPublished property was specified as 0 in the tag, then showPublished would be 0.
- Only use getOption if you're reading an existing setting from the DB, not if you need to update the option.
- getOption uses the settings cache (it's much faster)
- getOption will also check User -> Context -> System settings (allowing you to override system settings with context and further with user settings)