Extending the system settings

hi everybody!

I’ve been using a plugin to extend the system settings with your own variables, and I’m looking for feedback on whether that’s a good idea or if there are issues that I haven’t considered.

I’ve come to loathe mixing certain static stuff like ids and member groups into snippet params, phx, etc, as well as wanting to be able to flag things, like turning comments on and off with ease. I haven’t come across anything like this, maybe it’s not a good idea, or perhaps there is another way?

This plugin will add a new tab labeled ’Settings’ that should show up in Tools/Configuration, before the ’File Manager’ tab.

I think this idea makes portability of pages from one site to another much easier as well, so you don’t have to get in and reconfigure things in multiple places.

It seems to work pretty well, but I have just noticed a strange issue... I’m testing on a fresh bare bones install of MODx 0.9.6.2 with no other plugins, snippets, chunks, tvs, or modules. I created a system setting with a setting_name of ’mo_money’ = setting_value ’mo problems’. In the content of my document, I added this...



’mo_myvar’ has not been created yet. The only foreign and `mo_` setting that has been created is ’mo_money’. When I run the page, [(mo_myvar)] was being replaced with ’mo problems’, and [(mo_money)] is blank. So the output is...



Weird. When I create ’mo_myvar’ and set it to ’bad penny’, each setting gets the correct value as expected.



I have been using this code in a couple sites with about 20 settings each and I haven’t had any issues. I don’t have any extraneous tags though either. I would have thought tags without a value would simply be removed, but it seems to be replacing incorrect instances. I’ve played a little more and when I test it seems like it replaces the first match it considers ’close enough’. Very bizarre. Any ideas? Once all tags actually map to a setting, everything works as expected.

The day I go to post about it, clean it up a bit and test it, I see this weird issue come up!

Anyway, code is attached... all feedback is appreciated!

Updated to force setting names to lowercase, as required by system_settings convention.

I love it!! I dunno anything about the issue but I love it THANKS!!

I’ll let others who know more about the 0.9.6 code comment on the advisability of doing what you’re doing.

You’ll be happy to hear, though, that MODx Revolution has just what you want. In Revolution, snippets have their own "system settings" called "properties." You create, delete, and set them in a grid like the System Settings grid -- it’s in a tab on the snippet editing page.

They’re easily available in the snippet code and are overridden by snippet pararameters sent in the snippet call. Better yet, snippets can be distributed with the default properties already set.

You’ll be happy to hear, though, that MODx Revolution has just what you want. In Revolution, snippets have their own "system settings" called "properties." You create, delete, and set them in a grid like the System Settings grid -- it’s in a tab on the snippet editing page.

This is not unique to revolution. Snippets have had "properties" for quite a while, although they don’t have a convenient grid to create them.

You could just as well use session vars, no? Or create placeholders. At least if you only need it in the frontend.

Anyway: I just created two custom system setting vars and they displayed fine (as long as you use foo_bar - when using camelCase it doesn’t seem to work). Maybe it was just a cache issue.

@ganeshXL : You can’t use camel case in system_settings for setting_name as the convention is all lower, no spaces. I’ve updated the plugin code so this is fixed for you on input now. I don’t think my issue was cache related, I cleared it multiple times trying to confirm. That’s what I thought as well.

@BobRay: You’re right, snippets have properties, but this is a central place to control things, and can be used as parameters between multiple snippets, phx calls, whatever.

For example, [+phx:mo=`[(mo_my_user_groups)]`:then=`...`+]. You can use this all over your site, and the ’mo_my_user_groups’ gives you one place to update it. If you had this group statically assigned in 16 different places, I’d rather update it once than 16 times. Yes, you can search and replace with phpMyAdmin, but I guess I’m suggesting this as an alternative way to set things up.

If I set up pages for news, archive, feed, etc, and use my own `mo_` vars rather than static doc ids for the parameters, I can export those pages and my `mo_` setting into a new site, drop in the plugin and map the new doc id values very easily, all on one page. I can use these same vars in custom plugins, etc. without having to go back into each one to make changes.

The intent is to provide an option for dynamic settings that can be accessed from anywhere in the system with ease, and managed in one central location. You could do this all manually with phpMyAdmin and your own system settings, but this plugin makes it a bit more convenient since it is right in the manager.

Perhaps these are bad examples, but things change over the course of development and from site to site, so this is meant to help accommodate that in certain situations.

I hope others can see or provide examples where this could be handy? We use snippets, chunks, TVs, etc, so I’m not sure why we wouldn’t want to create our own ’system settings’ in certain situations?

Quote from: TobyL at Nov 15, 2008, 05:51 PM

You’ll be happy to hear, though, that MODx Revolution has just what you want. In Revolution, snippets have their own "system settings" called "properties." You create, delete, and set them in a grid like the System Settings grid -- it’s in a tab on the snippet editing page.

This is not unique to revolution. Snippets have had "properties" for quite a while, although they don’t have a convenient grid to create them.

Right, but having the grid kind of makes it a new ball game and having them set for you at install is just icing on the cake.

Quote from: lucky at Nov 15, 2008, 10:28 PM

@BobRay: You’re right, snippets have properties, but this is a central place to control things, and can be used as parameters between multiple snippets, phx calls, whatever.

It sounds like a reasonable use of System Settings to me if you want them available across various users, snippets, documents, etc. Just remember that they are available everywhere for everything and have the potential for collisions and bogging down the system somewhat if you go wild with them.

Also handy in this regard are Context Settings. If you need a setting that is going to be used by more than one snippet, or used in places other than snippets, it’s brilliant.