What do you see in the xtype field for that System Setting in the DB?
The name and description fields for settings are handled in a weird way. In fact, there is no name
or description
field in the System Settings table in the DB. They are automatically generated keys that are based on the key of the setting. They don’t exist outside the process of rendering the panel, but they look like this for a setting with a key of greeting
:
setting_greeting
setting_greeting_description
In the default.inc.php
lexicon file, you’d see something like this:
$_lang['setting_greeting'] = 'Greeting';
$_lang['setting_greeting_description'] = 'This is the greeting'
When MODX loads the System Setting edit panel, it uses the setting’s key to generate the two keys for the name and description, looks those keys up in the lexicon file, and puts the values found there on the screen in those two fields.
In your config file, you usually want simpler values, since that’s what the user will see. They can see the key and they know what settings they’re looking at (just a suggestion). Prefixes are unnecessary since MODX will only be looking in your own lexicon file, so there’s no need to mix dots and underscores (which, might confuse you later on).
'key' => 'hcaptcha_site_key',
'name' => 'Site Key',
'description' => 'Site key for the site generated from the hCaptcha dashboard.',
'key' => 'hcaptcha_secret_key',
'name' => 'Secret Key',
'description' => 'Secret key for your hCaptcha account',
Whatever you do, make sure the key
and description
fields match the keys in the default.inc.php
lexicon file.
As for workflows, there is a diagram [here], (Bob's Guides | MyComponent Workflow), but I don’t know if it will help. It’s difficult because MyComponent is so complex (it’s now made up of over 3,500 files) and powerful, and I tried to make it fit a variety of workflows.
There are basically three possible workflows:
- Work on the files and import them with ImportObjects
- Work on the objects in the Manager and export them with ExportObjects
- Switch back and forth between 1 and 2
Number one doesn’t really work by itself because ImportObjects doesn’t update everything, and some objects have no code files. Number two can work by itself, but if you have a good code editor, you’ll miss it when editing code in the Manager.
Number 3 is what I do, but you have to be careful to run ImportObjects or ExportObjects before switching methods.