Creating user settings via the API

32 Posts

glcreations Reply #1, 14 years ago

Does anyone have a test bit of code for creating a custom user setting, that's say a textfield in MODx revo?

Just so I know then how to do such a task.

Thanks

[img width=500 height=56.666666666667]http://i3.photobucket.com/albums/y81/GraemeLeighfield/Forum/glcsig.png[/img]

☆ A M B ☆
24,524 Posts

sottwell Reply #2, 14 years ago

Is this for the front-end, or a Custom Manager page in the Manager?

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

32 Posts

glcreations Reply #3, 14 years ago

I don't quite understand what you mean sottwell...

If you go into the manager, and update a user, there is a tab called "Settings" and from there you can "Create a new setting".

I would like to know how to do that - via the API.

[img width=500 height=56.666666666667]http://i3.photobucket.com/albums/y81/GraemeLeighfield/Forum/glcsig.png[/img]

483 Posts

Fuzzical Logic Reply #4, 14 years ago

This is not easy via the API. Creating System Settings via the API has specific requirements that must be met prior to the Setting being created. The primary concern is the Lexicon. A Setting in MODx requires two entries in the Lexicon before it will be accessible. That said, it will be readable, but it will not be writable. Then, it requires you to refresh the cache.

Is the UserSetting an override for an already existent SystemSetting or ContextSetting?

Website: Extended Dialog Development Blog: on Extended Dialog
Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".

863 Posts

Lucas Reply #5, 14 years ago

Easiest way is to use runProcessor() on the existing system/setting/create processor.

Not tested but should give you some idea:

$properties = array(
    'key' => 'my.setting',
    'name' => 'My Setting',
    'description' => 'Setting description...',
    'xtype' => 'textfield',
    'namespace' => 'namespace',
    'value' => 'a default value',
);
$response = $modx->runProcessor('system/setting/create', $properties);
if ($response->isError()) {
    return $response->getMessage();
}
$setting = $response->getObject();

// refresh cache
$modx->cacheManager->refresh(array(
    'system_settings' => array(),
));

☆ A M B ☆
24,524 Posts

sottwell Reply #6, 14 years ago

He's talking about custom USER settings, not system settings. It's the user_settings table.

My response was to determine whether this field will appear in a form on the front-end, for example a user registration form, or if it's to be part of a custom Manager page.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

483 Posts

Fuzzical Logic Reply #7, 14 years ago

User Settings, Context Settings and System Settings ultimately mean the same thing. A User Setting overrides a Context Setting or System Setting, if present. Context Settings override System Settings if present. They all have similar requirements.

Further, unless specified, they use the same Lexicon keys, etc... I stand by my previous statements. If you are not overriding a System Setting, you must have the Lexicon keys in place... Then you must also clear the cache.

Website: Extended Dialog Development Blog: on Extended Dialog
Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".

☆ A M B ☆
24,524 Posts

sottwell Reply #8, 14 years ago

Hm. Looks like I've been laboring under a misapprehension of what the user_settings table was for even in Evo for a long time! I always thought it was just a table for storing user-defined extended fields.

Well, even so, it still makes a difference whether this would be in a custom Manager page or on the front-end. [ed. note: sottwell last edited this post 14 years ago.]

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

863 Posts

Lucas Reply #9, 14 years ago

Ah yeah, user settings. It was pretty early.

So just run 'security/user/setting/create' instead, it's pretty much the same but you'll need to pass a user id in the $properties array:

$properties = array(
    'fk' => 6, // user id
    'key' => 'my.setting',
    'name' => 'My Setting',
    'description' => 'Setting description...',
    'xtype' => 'textfield',
    'namespace' => 'namespace',
    'value' => 'a default value',
);

User settings are stored in the user_settings table. But I wouldn't think the code would be much different run from a front-end snippet instead of a back-end processor?

483 Posts

Fuzzical Logic Reply #10, 14 years ago

The code is no different, you are correct. I think the confusion that susan was having is that she was thinking of extended fields, not user settings which are totally different.

Website: Extended Dialog Development Blog: on Extended Dialog
Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".