D14452 and similar seem nearly certain to obsolete this.

You can change the configuration. This protocol is not prevalent enough to motivate us to include it by default in the upstream.

After D14219, you can adjust GC policies with the new bin/garbage.

wow man, thanks for thinking about this

that looks good to me

^^ yuh?

(I think I just repeated what avivey said, much more crisply, above.)

(But, and this is a slightly separate issue, it might be nice to have some indication in the 'default' section of which of those values is the current actual value -- maybe just highlight the value, or put a star next to it, or the text 'current working value' or some such. It's not necessary, and I know it will always be the first non-empty value that's marked in that way, but it would remove all ambiguity, especially in cases like the database has the empty string as its value, and a config file has a non-empty string, so the empty string is the default but it may not be clear from the UI.)

Yeah, I think just hiding the "value" section for non-editable controls would have resolved the issue for me. (In that case, I would have assumed the value was set to the first non-empty value in the "default" section.)

I think the primary use case for this UI is editing the value (that's what I'm trying to do about 98% of the time I end up here, at least), so it seems weird to bury that control. On some pages, like differential.fields, it would be buried very deeply if we moved it after the table.

And highlight the first one as "Effective Value" or something.

Maybe move that table up, label it "Current Value", and - if needed - have the DB value control show up below it?

In T9339#135299, @chad wrote:

What if we just change the text to say "Database Value" instead of "Value"

What if we just change the text to say "Database Value" instead of "Value"

For locked stuff we should probably just not show the "Value" control for most controls. (I think we show it because it's useful for some config that has special controls, but I'm not sure; could also just be something I missed.)

btw, I think the right fix is to have 'value' be the current value, no matter where it comes from.

The default can be changed using following patch (cf. P1821):

Thanks!

It is always English (US).

But where does "Server Default" come from? Apparently there is a default set somewhere, I just cannot find it…

There is no way to do this right now. T4103 will provide a way.

Oh, haha, there is nothing useful in there.

I'm really glad that's still not a thing. :)

Same here, but I do see we are both design nerds. Wanna talk about skeuomorphism for a few hours?

FWIW I spent 20 minutes and couldn't set it from the command line either. But I am a JSON noob.

No worries! You're still my best friend. Just hope this report helps somehow. Thanks Chad.

Yeah, it's know this feature is experimental, possibly bad, and incomplete, which is why we warn people beforehand. T4214 is the "make it work as expected" task. Sorry for the troubles.

Bonus sadness: I still cannot figure out how to set ui.custom-header via bin/config.

Sorry, we don't offer support with third-party custom development. See "Supported Issues" here:

Presuming this is resolved, but let us know if that doesn't work for you.

Use bin/config delete --database phpmailer.smtp-password to delete the database value.

This is intentional in the general case because some config issues may be raised before we can load CSS, so they can't contain Remarkup.

Cool. Let us know if you run into anything eles.

Fair enough. Thanks.