Long running UX bugs that I would love to finally be rid of
There are a couple of things that have been causing a great deal of support for us for many years now, minor things that are easy to correct case-by-case, but that also feel particularly unnecessary.
Hopefully they are easy to fix.
1. Hostname is often wrong for FTP.
In the FTP Accounts tool. When the user clicks on Configure FTP Client, they are provided with useful information for how to configure an FTP-client.
However, the value for FTP server is often wrong.
cPanel appears to assume that an A-record for ftp.$domain is Always set and Always resolves to the cPanel server.
And while this can often be true! Especially for users with a newly registered domain. Often enough the A-record for ftp.$domain doesn't exist, or resolves to some other host. Most of the time this is because the user has moved their hosting to a cPanel host but still have their nameservers with a previous host.
I propose that instead of showing ftp.$domain, the box shows the server hostname regardless of what domain this is regarding. This I believe should be more universally applicable.
2. FTP Directory is almost always wrong.
In the FTP Accounts tool. When the user creates a new FTP account, they are initially shown an empty textbox for Directory, but this box is silently filled such that it will show $domain/$login by the time the user presses the button to Create FTP Account. We find that many users do not notice this textbox and create the FTP account with a directory that leaves the FTP-account unusable. Most of the time the user creates an FTP-account to give full FTP-access to a developer or to avoid using the main cPanel credentials for FTP, for these use-cases the suggested Directory is always wrong.
I propose that the Directory textbox be left empty entirely.
Or if the current behavior is preferable for some reason, then add something to draw the user's attention to the Directory textbox so that new users who are not aware of this pitfall have a better chance to avoid waltzing into it.
3. Current setting in Email routing is misleading.
In the Email Routing tool, after the user has selected a domain, the option that was last saved is pre-selected.
This saved option does not however necessarily reflect what is the currently saved setting in /etc/localdomains and /etc/remotedomains for that domain.
For most options this very rarely becomes an issue, but for Automatically Detect Configuration this often becomes misleading as that option does not say what setting was last saved, and it has a preview that shows what setting will be saved if the option is selected and saved now.
Currently this means that if I need to check the setting for Email routing I cannot rely on the UI, I have to grep for the domain in the files for the real answer.
I propose that the option to be pre-selected in the UI is determined based on what is currently in the files, and not on what option was last saved.
4. The Automatically Detect Configuration option in Email routing is causing confusion.
In the Email Routing tool, after the user has selected a domain, there is an option to Automatically Detect Configuration, with a useful preview of what setting will be saved if this option is selected and saved now.
This option suggests that there is some automation to update the setting whenever the domain's MX changes, without user action, but this is not true.
Further, when Automatically Detect Configuration is the currently saved option then the user might mistake the preview for showing the current setting, mistakenly believing that no action is required.
I propose that when the option would be saved as Automatically Detect Configuration, then it visibly changes the selected option to either Local, Backup or Remote instead, whichever is appropriate. So that the user can clearly see that there is no automation past the point when they press Change.
-
Hey there! Give me a bit to explore these for you and I'll get back to you with more details soon!
0 -
1 - FTP Issue - By default, we include the mail, www, and ftp subdomains in all new DNS zones that are created, as these are in the zone templates you can see in WHM >> Edit Zone Templates. If you are using the cPanel server for your DNS those records would be present unless the zone template has been modified.
i did confirm that if the DNS templates are modified we still show the "ftp" option in the "Configure" section, so we could likely improve on that interface a bit. I've created case CPANEL-45976 for our team to review this behavior, with the recommendation of using the hostname instead, as the hostname should always exist and be operational on a functioning system.
2 - For this behavior, I see that the box gets filled as soon as you click out of the "Log in" box when you create the name. This ensures there is always directory created under domain.com/username unless the user decides to customize it. We do have documentation about this under step 4 here:
https://docs.cpanel.net/cpanel/files/ftp-accounts/#add-ftp-account
and I don't believe we want to change that behavior at this time.
3 - Can you clarify this behavior a bit? I'm not sure what you mean by "last saved" vs "what is in the files" so I'm not entirely sure how to reproduce this behavior.
4 - I like this idea a lot, although it may end up being a documentation issue more than an interface issue, depending on how the developers decide they want to handle it. I've created case CPANEL-45977 to have them investigate that behavior to see if we can make it more obvious that this is a one-time detection and not an "automated for future changes" setting.
Thanks so much for this type of feedback!
0 -
Happy to help!
And thank you for your response!Elaborating on point 3:
From my testing, it appears that changing the selected option for Email Routing, and clicking the button "Change", causes two things to happen.
A. It saves what option was selected in the UI. So that the same option can be pre-selected the next time the user visits the interface. This is what I meant when I say it saves the "option".
B. It changes Exim files to get the desired behavior from the email-server. I don't know for sure all the files that it changes, but I know that at least /etc/localdomains and /etc/remotedomains files are changed. This is what I meant when I say it saves the "setting" to the "files".
In other words. The saved Option and the saved Setting are separate.
At the time when a new option is selected and saved, the option and setting will always match.
But at some point later they might no longer match, depending on outside factors.If the saved option is to Automatically detect. Then you have no way via the UI to find out what the actual setting is. You have to run grep $domain /etc/localdomains to find out if Exim will attempt to deliver emails locally or try to send them to the domain MX.
If the saved option is Local, Remote or Backup. Then the setting will usually match often enough to be reliable! But there could be a mismatch if something has been done to the files, perhaps via backup, or ad-hoc fixes by tech-staff. Meaning that when you are troubleshooting, you have to run grep $domain /etc/localdomains to be sure.
Therefore I suggest that when the UI determines what option to pre-select, it selects based first on what it reads from the files, so as to to reflect the setting instead of what option was last saved.
(If Backup and Local are the same when looking in the files, then the previously saved option can be used as a tie-breaker between those two.)
Alternatively, instead of changing the current behavior, add a new text-field that reads the setting from the files.0 -
Thanks for the additional details, and I do understand what you're saying now. Is there a particular way you can reproduce them being out of sync? I believe one would need to manually edit the /etc/remotedomains or /etc/localdomains file for the specific domain in question in order for that to happen, which isn't something we typically recommend.
If you have a way to reproduce the issue of the setting in the UI getting out of sync I'd be happy to look into it!
0 -
Editing the files is the only method that I know of to intentionally cause such a mismatch.
I don't know by what mechanism this occurs unintentionally, it is rare, but it happens.
I will let you know if I find something.0 -
Sounds good!
0
Please sign in to leave a comment.
Comments
6 comments