When I started the MADX MODX Add-on of the Month award a few months ago I did so for the underdog Add-ons and their respective MODX Community members. In other words, not for Mark Hamstra. Mark is one of MODX’s leading community members with over a dozen widely used extras and is well known for providing support to the MODX Community through his own website, the MODX Forums, and Twitter.
While he’s far from an underdog, his newest Add-on ClientConfig has won Add-on of the Month for January 2013 for one simple reason.
If it’s not installed on your MODX Revolution site, it should be.
- Overview -
ClientConfig makes it remarkably easy to allow your clients to easily manage system wide settings. You may be wondering, “Why not just use System Settings?” In that case, I’d have to sarcastically ask you, “Have you ever used MODX System Settings?”
System Settings are as great for developers as they are scary for clients. There’s really no way to limit which System Settings they have access to, and you don’t want your client having access to a bunch of things they don’t understand or need to be concerned with.
Simply install ClientConfig and follow the simple installation instructions and I assure you your client will be happily editing System wide settings in no time.
- Make the Switch -
Ok so you’re ready to make the switch, but your site already has a bunch of System Settings that are being used throughout your website. No problem! ClientConfig overrides both System and Context with the same key. It also uses the familiar [[++my_setting]] naming convention. So, all you need to do is create your ClientConfig settings with the same key!
- No More Hacks-
Now, I’m sure a few of you are thinking to yourself, “I got this other trick I do where I create a resource with a bunch of Template Variables that I use instead”. You’re doing it wrong. Site wide System Settings should be stored at the system level. Regardless of the language or framework, using a non-constant Object (such as a MODX Resource) to store settings that your system is dependent on to function is hacky at best. It’s a broken site at worst, when your client accidentally deletes your magical ‘Settings Resource’.
- With the Author -
• How did you come up with the idea for ClientConfig and when did you start developing it?
I was preparing my presentation about how to build extras for MODXpo Europe 2012 in Utrecht, and needed an actual use case with common elements to not waste time building something nobody would ever use. So when looking at my ULOAMEI list (https://trello.com/board/unofficial-list-of-awesome-modx-extra-ideas-uloamei/4f1b095c6ce9cdc226168a37) I was reminded of the idea of some sort of configuration component, which could replace a “configuration” resource (which semantically doesn’t make sense in the resources tree), or the system settings grid (which I don’t want clients to touch with a 10ft pole). ClientConfig would give site builders the ability to easily and transparently provide configuration for the end user, which I think was lacking very much before.
• MODX is know for having a “vanilla install”. Do you think something like ClientConfig has a place in the core, or is it best served as an Add-on?
Add-on. I’m a big fan of the vanilla install, and while I would love the ability to install vetted extras during setup, I believe the split between core and add-on is important to enforce.
• Are there any feature requests from the community that surprised you? If so, what are your favorites?
The amount of people asking about making the configuration context-specific was surprising - I didn’t realize contexts were used that often. I think in general the amount of requests and people using the tool has been really encouraging. Even before I tweeted or blogged about the release myself, there had already been about 20 bug reports and feature requests and the best blog in the world (Try Catch of course!) had already featured it :)
• ClientConfig overrides System Settings. Does it also override Context Settings?
Yes, and it should override user settings too. Basically as soon as MODX initiated the context etc, the clientconfig settings are being set. If you give it the same name as an existing setting, that value will be overriden.
• Would there ever be a need to call ClientConfig settings uncached?
Nope, unless it references other settings in its value that may change before the clientconfig settings are changed… but now we’re talking about setting-ception. ClientConfig handles its own cache, so there are no unnecessary database lookups and the cache is regenerated when you save a setting or group.
• Is there a roadmap for ClientConfig?
There’s not a solid roadmap, and a lot of the ongoing development is based on what the users are asking for. In future releases I’m hoping to improve the UI/UX, add more input types and potentially add the ability to use TV input types as well.
• Some people say this is your most useful Add-on yet. Would you agree?
Personally I think configuration is good, but I would choose VersionX as my most useful add-on to date, as the content is so much more valuable than configuration. It’s definitely way up there though. :)