Url links - surely not correct?

OS type and version Ubuntu Linux 22.04.3
Webmin version 2.101
Usermin version 2.001
Virtualmin version 7.8.2
Theme version 21.08
Package updates All installed packages are up to date
Box Name dev

Sorry @Ilia me again.
Trivia I know, but perhaps needs attention, a general rule of thumb - accepted norm - if a user hovers over a link / menu item a help prompt is displayed indicating the url that the user will go to if they click on the link/menu item.

This is pretty much true throughout Virtualmin.
for example go to Virtualmin -> Server Configuration -> and hover over SSL Certificate and the help prompt shows https://domain.com:10000/virtual-server/cert_form.cgi?dom=16890059795199&xnavigation=1

Go to Virtualmin -> Dashboard (and I select a another domain from that list - not the first in the list of course) then hover over Dashboard menu item

The help prompt shows https://another_domain.com:10000/sysinfo.cgi

This is nothing like where that link actually takes you.

If you click on the menu it does take you to the Dashboard.

But if you enter the url in the browser one goes to a bad place. It takes one back to Webmin (for a start) and it resets the selected domain to the first in the list. On top of that when you tab to Virtualmin one gets the spinning circle of doom as there seems to be stuff happening.

Also if the help prompt was changed to the actual destination https://another_domain.com:10000/sysinfo.cgi/?xnavigation=1 that is still incorrect as going to that url still takes you on the same journey through Webmin.

I think you know what I’m going to say here!
why not https://domain.com:10000/dashboard or similar https://domain.com:10000/virtual-server/dashboard.cgi?dom=16890059795199&xnavigation=1 in keeping with all the other help prompts?

and while I’m on my hobby horse why ?dom=16890059795199 and not dom=a_real_domain_name ? I don’t know about everyone else but I find long numbers difficult to remember.:frowning:

Ed: Actually all one needs to do to be dumped is to do a browser refresh (Ctrl + R) → domain forgotten and back to Webmin. Because the system has forgotten where you were.

What do you mean by help prompt actually?

This is how it was initially designed by @Jamie.

Actually all one needs to do to be dumped is to do a browser refresh (Ctrl + R) → domain forgotten and back to Webmin. Because the system has forgotten where you were.

If you make full page reload while being on the Dashboard, then yes, the menu switch isn’t remembered. This is quite expected, and would be pretty hard to make it work as you suggest.

Moreover, this is absolutely not important in my opinion, because you only need to reload the page when theme is upgraded, i.e. as part of Webmin upgrade.

That said, the menu switch is remembered for all other Virtualmin pages, except Dashboard. What’s the big deal?

Alright to try to be more clear. I’m on Windows (and Chrome browser not that the browser makes any difference) and I’m pretty sure it is the same on an Apple machine.

If you move the mouse over a anchor link (menu item with a title attribute) or when using a screen reader. You see a small popup at the bottom of the browsed page that displays the “href=” or “title=” content of the link. That is the help prompt to which I am referring. There are long established and accepted rules about this prompt. Some of which that have been expanded W3C (SC 1.413) regarding making them focusable / dismissible / persistent especially for accessibility.

Perhaps that is something slightly off this topic. I was just using it as an example and the question flashed into my head - why? it seems so easy to design everything with the same principle design rules.

why use url path parameterisation ../virtual-server/some.cgi/ for one url and then url query string parameterisation
for another it is inconsistent even if correct and confusing and meaningless to users.

Consistency is the 1st rule of design.

I did say “Trivia”. But I get really annoyed by anything on the internet that doesn’t do what is expected.

I think the Dashboard is the first place to go to as it contains almost everything anyone needs to know about the state of things.

There is no need to care about domain name in URL. It is possible to change it, although I don’t see any practical value in doing it, as you always have domain name shown in navigation menu.

I could have a look in making sure that the Virtualmin tab is restored with Dashboard reload.

1 Like

But don’t put it higher up the list than real bug fixes - it is only a design trivia after all - just me.

I’ve already fixed it locally. I will need to run more tests though.

I intentionally chose to use numeric domain IDs in all links because they never change, whereas domains can be renamed in Virtualmin.

They can but that is a separate process so changing the id number could be included in that process on that page. The numbers (or name) seem to have some importance when they are included in urls yet the number remains meaningless to the observer or someone entering the url.

An example would be me providing a novice user with a go to link as help. If that link was clear as in
https://your_domain.com/virtual-server/some.cgi/?dom=your_omain&xnavigation=1 it would do as expected.

whereas the link https://your_domain.com/virtual-server/some.cgi/?dom=1234567890&xnavigation=1 would be a total guess and probably wouldn’t work.

Oh course it will work as that would be the expected target, you don’t need to guess the domain ID at all you can find it at vmin->domain->Virtual Server Summary

from a coding point of view I find a numeric variable much simpler to work with than a string there a lot less checks to make on a number over a string to make sure its correct.
at a bare minimum the following files would have to be renamed to a new id

plus I guess loads of references to the domain id contained in other files elsewhere, such as the apache/nginx config files

I am not saying the id as a number cannot be found but could I guess yours or anyone’s if I was providing you or someone else a link to “go to” finding my own id number would also require several more menu selections. → might as well just click on that link as provided. The whole idea of providing a link visible on hover is that it has meaning to the user (otherwise why is it there and in the W3C).

in some languages maybe (in NodeJS my language of choice) strings are pretty much a given throughout. interpreting ../spam/14457205497609/v342.pre would be split into path = {"spam", "14457205497609", "v342.pre"} the number “14457205497609” or string “14457205497609” are just as meaningless to the user. the word “dom” is suggestive of meaning “domain” othewise just save 2 bytes of code (and bandwidth) and just use “d” if the number is just an attempt to obscure the domain then just use a hash. ?x=a13bf, or better still stop using links (GET requests) altogether.

But this is post not really about the internal workings or choices made in the code of the site’s GUI. It is about the information (specifically the urls), as they are currently provided, being functional. I do note that there are no url links provided on the main menus eg Virtual Server Summary, or Edit Users → yet they do take you to different pages. That clearly demonstrates intent to show the user.

This is a data-structure – it is not supposed to have any meaning for the user! User shouldn’t care about the URL and search any meaning there.

The latest theme 21.09 have support for it already.

That was a specific response to @jimr1 comment on coding.

However, urls are what the web is all about - especially for users. if they are not for users they should be hidden.

Tx again, I’ll update - only using 21.08 at the moment.

Not 100% valid anymore, especially on the title attribute. It is useless on all mobile/touch devices so is basically semi-deprecated in all modern design builds.

Illa probably already gets nagged endlessly in his build process by missing ally and aria attributes all over the place and that is more applicable here as far as future navigation improvements to the front end is concerned.

See more here

there are plenty of old folk out there still, at least until we all die out or get put into “homes” who do not use or even have an implanted mobile/touch device.

So most “future improvements” gets put in the same waste basket as “just stop oil” and “go vegan, save the planet” clap trap.

I’m fine with adding features to accommodate such things but keep the functionality we are all used to because it simply works, as it was originally designed to do.

Is there something else that isn’t working?

So most “future improvements” gets put in the same waste basket as “just stop oil” and “go vegan, save the planet” clap trap.

It’s worth noting that the agriculture process for meat production necessitates a minimum of four times more crops for livestock feed than direct human consumption would. Additionally, animal agriculture is significantly water-intensive. It’s not just an opinion; it’s grounded in research and facts.

That is why these urls should not change into something human readable there is no need. but have you hovered over a discord link ? it shows in your ‘help’ popup something like
where as the human sees that as

discord.com → phporyx → welcome

so using numerics in urls is not just a vmin/wmin thing it’s all over the place. I must admit wordpress tends to ‘prettify’ it’s urls into human readable forms for seo purposes

as @apt_virtualmin is most likely heading for depreciation.

I’m well over 70 and do not wish to live in a bygone era of web design … I love to see how it changes over time and incorporate modern ideas into my code

Illia’s 21.09 theme has improved things.

and I seem to be living in the past as far as urls and user usability is concerned. No one else cares. :frowning:

Good to hear! Thanks for the heads up!