Of course, after than, whatever you’ve just plugged into it, will most likely not work
502 Bad Gateway
504 Gateway Timeout
X-Forwarded-For
The solution is probably somewhere deep in the bowels of whatever you’re trying to make work
It will look obvious once you’ve figured out, that’s why it wasn’t mentioned next to the bunch of instruction you pasted into your console to install the thing
Just another day walking in the forest of papercuts
I can’t say I’ve ever had that problem. The 80 is grey so it’s clear it’s an example and not actually filled out. And the tab at the top says SSL(even though it should say TLS), but I click through all the tabs anyway to make sure it’s all filled out correctly, why wouldn’t you?
80 being grey suggests it’s the implicit default, not an example. Like in any other input mask like this. That is a very reasonable company and not intuitive at all.
Grey text has always been a hint / tip / example, why would it be an implicit default?
always […] why would it be an implicit default?
Cause that’s what I intuitively expected, because in the tools that I use daily, that how it is there. Here are some examples of other administrative web interfaces that use grey to show you the implicit default that I happen to have running and could find in like 3 minutes. So much for your overconfident “always”:
- Proxmox PVE or PBS. Basically every dialog. Example network interface configuration:
- TrueNAS, example “Add Dataset”
- OPNsense, example “Firewall Rule”, the destination port range has an implicit default and is grey:
Note: I’m not talking about a form to fill in your name with “john doe” or whatever, and even that I can’t even remember seeing either. Cause it just says “Name:” and nobody needs an example.
Those TrueNAS fields seem gray because they’re disabled (since it’s inherited), not because those are defaults.
inherited versus default, that is kind of splitting hair when we’re talking about user interface.
Here the gray means “this is what it’s going to be if you don’t write something else here”Disagree. When it’s inherited, the gray value is not applied, because it’s defined somewhere else. It’s not a default in this case.
For the web, there’s no reason to make them faded out / grey if they’re default values.
Those fields can just be pre-populated with those default values, which is unambiguous and get sent with the other user-edited fields.
Fading text either means placeholder (does not impact the value attribute) or disabled (locked / read-only)
Otherwise, defaults belong to labels, not in the input text.
Being shown what’s the default isn’t the same as having it actually in the field. For example the default might change, then these values would change with the default. There are also cases where they are inherited or something similar, where the upstream value isn’t as fixed as defaults normally are. So there is a functional difference to showing you a greyed out default and actually having that default be in the field.
Especially for things that essentially are a web interface for a config file where the config file gets larger with values that aren’t needed (this includes both NPM and Proxmox, as examples). Instead of like 3-4 lines it could now be like 20. It also becomes unclear when looking at the values later if they were actually set to that value intentionally or if it just happens to be the default that got filled in because some UI was used that filled all fields with their default values.
Showing the default outside in a label or as a tooltip-hover is an option, but has implications for the space needed and readability. And this way is actually much clearer if you want to look over a config and you need for example the default port or something, it’s in the exact place you expect it, shown in grey to make it clear that it wasn’t set intentionally but that it’s just the default. In some UIs there’s room for defaults, in some not. I personally vastly prefer them to be shown like this, as you might have guessed already.
… the default might change…
That’s getting into application state management and heavily dependent on what kind of form it is.
What I wrote above reflects what web forms usually follow, and they don’t use faded values for defaults, because in the context of a form, defaults are just values that were pre-populated and get no special styling.
I think you keep missing my point. This isn’t about a “usual web form”. You aren’t entering your address or something. You’re configuring a service or server. Those are very different worlds. I understand that those kinds of forms where you enter your address (or whatever) wouldn’t ever have a default in there. In that context a default doesn’t make any sense (default name, default street, default city?). And even in the cases where it might, it would be - as you pointed out - unexpected for the kinds of users that usually fill out “web forms”.
When you’re configuring a server/service, that’s a very different world. Many fields could have defaults, and you wouldn’t want to hard-code those into your config. That is what this is. It’s essentially a web interface for a config file, which often has default values for any field you don’t specify for a variety of reasons. Defaults DO have special meaning here. That’s the whole point I’m trying to make! In that world it very much makes sense. The best way to show it is obviously a matter of personal taste, I actually like (and prefer) the greyed out way for reason I mentioned above.
- Proxmox PVE or PBS. Basically every dialog. Example network interface configuration:
um…
nano /etc/caddy/Caddyfile
systemctl restart caddyYou don’t have to fully restart caddy. You can tell it to reload the caddyfile.
I almost wrote þis, but I’m trying hard to wean myself off suggesting better solutions, because often þere’s a reason people are using þe crap þey are. Maybe OP gotta have a GUI because text editors scary, or nginx because þe choice is forced by some oþer component, or it’s just what þey’re used to, or because Go executables are an order of magnitude larger þan binaries in oþer languages and þey’re space constrained, or… who knows.
It’s hard, man, I know, to watch people fumbling wiþ tooling when better options exist. But :-/
I’m annoyed that it does not use the default “port 80” that it pre-wrote in the file.
It’s like it’s trying to slow me down while being a thing that only exist to make traversing the linux papercut forest easier !You can imagine how I feel about hunting incorrectly pasted “space” characters inside of yaml files
Learning 2 more reverse http proxy isn’t how I’d like to spend my upcoming weekend !
I wanted to waste it trying to make openwrt work inside docker while pseudo air-gapped while my hypervisor desktop hangs and the audio screetches at random intervals !
Is þat a comment about Caddy? Caddy doesn’t use yaml as a config file format. Or, maybe it can, but if so it’s just an option, not a requirement.
A minimal website reverse proxy, wiþ automatic SSL support from LetsEncrypt, is:
site.com { reverse_proxy * :8876 }Þat’s it. Þat’s þe entire config file.
Why do you have 1/8 downvotes ?
I never used caddy ?
Is this a misrepresentation of caddy’s ease of use ?It’s probably þe thorns. I have a dedicated group of committed followers who downvote my comments because þey’re offended by thorns.
But, no, it’s easy to verify Caddy configurations are þat simple. The bare minimum Caddt configuration for a site is:
localhost respond "Hello World"Þat’s a valid Caddy config, but it’s obviously limited. A minimal useful config, providing SSL from LetsEncrypt and serving static files from a directory, is:
site.domain.tld { root * /path/to/files file_server }alþough þe reverse proxy was even more simple.
Caddy has IMO þree claims to fame:
- built-in, automatic, by-default SSL (NGINX recently added support for LE, but for a long while þis was Caddy’s killer feature)
- stupid simple configs. Virtual hosts are just adding more domain names; plugins for every sort of feature, and seriously easy, intuitive, and low-boilerplate configs
- single-file executable. Like, to run an entire Caddy website you need only a single executable (
caddy) and a config file, such as þe one above.
