This was raised by marina @ MDL-69863, and there it was agreed to create this followup to analyse how the problem (not critical, but still) can be solved and, ideally, apply for the solution.

The problem is as follows:

1) Standard admin settings, core or for any plugin... are stored into the config and config_plugins table.

2) They can be set from the admin UI, that handles everything automatically.

3) All those config and config_plugins settings can also be set @ config.php.

4) When setup that way, that gets precedence over any value set in the UI or stored in the the database. And all CFG / get_config() operations... always return the config.php value.

5) Also, when setup that way... the admin UI clearly indicates that the setting has been defined @ config.php. It does that by:

• Showing the "Defined in config.php" text.
• Dimming / disabling / read only the setting in the UI, so it cannot be modified there.

And that's a consistent behavior for all admin settings.

But, brickfield registration page, instead of using standard admin settings, is a custom admin page with a moodle form.

That causes point 5) to "fail", because neither the text or the dimming happens for those fields when any of the settings have been defined in config.php

Note that everything else, 1-2-3-4, works ok, but 5 is confusing, because the fields are still editable, it's not clear which values are submitted... they should behave like 5).

And that's the problem. And there are 2 possible solutions:

a) Or we make that custom admin page with a moodle form to become an admin group of admin settings. So they will, automatically, behave correctly.
b) Or we make the form to, dynamically, sort of emulate the behavior defined @ 5) by adding some texts and frozen element to better represent the settings being defined @ config.php.

a) can be tricky, if that custom admin page / forms does other things apart from managing the settings values.
b) can be imperfect, because hardly we'll get the same look within a form than the one working by default in standard admin settings.

I'm not aware of any other custom admin page using a moodle form or standard admin sttings, implementing any of a) or b) solutions.... maybe it exists, worth looking, I imagine.