The first thing I'd like some clarification on is did you install and set up the RESTbase server at some point? Or is that no longer required? My reading (both online and of the config you've previously posted) suggests that it is, but your posts don't make that clear to me? Although perhaps I missed something? Nope. Did not have to install that separately. You are correct, it is all baked in at this point.
Also, was '$wgServer' really set to 'https//domain.com'? Or was that just for example purposes? It should have been set to a domain name that resolves to your server (via DNS and/or hosts file adjustments on both your host and guests) and I'm guessing that you didn't set that up for https://domain.com!? It’s a very small environment and I didn’t want to have to manage and backup an internal dns server so I was attempting to utilize the server IP instead of a hostname. Defining the value as the hostname of the machine instead of the IP seemed to rectify the issue. This was the missing piece to my puzzle. My silver bullet.
FWIW newer "zeroconf" type dynamic addressing is pretty cool, but can be a bit flaky (there are competing standards and no all devices support all standards). It works well when it works, but when it doesn't it's a PITA in my experience so we don't actively try to support that (it's a bit of a rabbit hole in my experience). Although we did make some adjustments a while ago that should make it work somewhat with many common modern DHCP servers.
As you note, '$wgServer' should be set to a name that resolves to your server. Although that should be resolvable both internally, and externally (either via DNS or by adjusting hosts files on the server and the guests). From what I can gather, you've essentially changed it to use a locally resolvable hostname (Correct). So whilst it now "works", I suspect that that name is not externally resolvable. So whilst the VisualEditor may now work (because it can connect locally), I suspect that you may hit other (perhaps more subtle) issues (unless I'm mistaken and that same hostname is also externally resolvable). E.g. some internal links may no longer work, some assets (e.g. pictures) may not load (if/when the links to them are being dynamically mapped to absolute URLs).
Sorry that I didn't pick up that possibility before. Although in fairness, unless the RESTbase server install is no longer required (Correct, a secondary installation is not required.), it seemed not installing that seemed like the most likely reason why it wasn't working. You didn't mention installing that and the config clearly shows that it should be available via localhost port 8142.
So in summary I'm really happy to hear that you worked out how to get the VisualEditor working, but I think that a little more config is required to make your while MediaWiki install work perfectly.
Also, I get the frustration, but it's not really Linux's fault. I'd say it's more of a server thing, perhaps even an open source software server thing? E.g. MediaWiki can be installed on Windows and I bet that you'd hit exactly the same issues, actually probably more (some of this stuff is really hard to set up properly on Windows - it's a breeze on Linux). FWIW, before I became a Linux user, I was a "Windows Power user" and managed IT for a small NGO (actually I still do, but most of their backend infrastructure is now Linux). And I can confirm, that as soon as you move away from the sort of every day Windows user type activities, configuring server related stuff on WIndows is just as bad, if not worse IMO. I'm slowly but surely working my way into Linux.
This instance is only meant to be used and accessed internally – I can’t even setup smtp on this instance. My latest challenge is trying to figure out how to enjoy VisualEditor while also not having the read permissions open for everyone, because I would still like to meet a minimum bar of security.
following up
The first thing I'd like some clarification on is did you install and set up the RESTbase server at some point? Or is that no longer required? My reading (both online and of the config you've previously posted) suggests that it is, but your posts don't make that clear to me? Although perhaps I missed something? Nope. Did not have to install that separately. You are correct, it is all baked in at this point.
Also, was '$wgServer' really set to 'https//domain.com'? Or was that just for example purposes? It should have been set to a domain name that resolves to your server (via DNS and/or hosts file adjustments on both your host and guests) and I'm guessing that you didn't set that up for https://domain.com!? It’s a very small environment and I didn’t want to have to manage and backup an internal dns server so I was attempting to utilize the server IP instead of a hostname. Defining the value as the hostname of the machine instead of the IP seemed to rectify the issue. This was the missing piece to my puzzle. My silver bullet.
FWIW newer "zeroconf" type dynamic addressing is pretty cool, but can be a bit flaky (there are competing standards and no all devices support all standards). It works well when it works, but when it doesn't it's a PITA in my experience so we don't actively try to support that (it's a bit of a rabbit hole in my experience). Although we did make some adjustments a while ago that should make it work somewhat with many common modern DHCP servers.
As you note, '$wgServer' should be set to a name that resolves to your server. Although that should be resolvable both internally, and externally (either via DNS or by adjusting hosts files on the server and the guests). From what I can gather, you've essentially changed it to use a locally resolvable hostname (Correct). So whilst it now "works", I suspect that that name is not externally resolvable. So whilst the VisualEditor may now work (because it can connect locally), I suspect that you may hit other (perhaps more subtle) issues (unless I'm mistaken and that same hostname is also externally resolvable). E.g. some internal links may no longer work, some assets (e.g. pictures) may not load (if/when the links to them are being dynamically mapped to absolute URLs).
Sorry that I didn't pick up that possibility before. Although in fairness, unless the RESTbase server install is no longer required (Correct, a secondary installation is not required.), it seemed not installing that seemed like the most likely reason why it wasn't working. You didn't mention installing that and the config clearly shows that it should be available via localhost port 8142.
So in summary I'm really happy to hear that you worked out how to get the VisualEditor working, but I think that a little more config is required to make your while MediaWiki install work perfectly.
Also, I get the frustration, but it's not really Linux's fault. I'd say it's more of a server thing, perhaps even an open source software server thing? E.g. MediaWiki can be installed on Windows and I bet that you'd hit exactly the same issues, actually probably more (some of this stuff is really hard to set up properly on Windows - it's a breeze on Linux). FWIW, before I became a Linux user, I was a "Windows Power user" and managed IT for a small NGO (actually I still do, but most of their backend infrastructure is now Linux). And I can confirm, that as soon as you move away from the sort of every day Windows user type activities, configuring server related stuff on WIndows is just as bad, if not worse IMO. I'm slowly but surely working my way into Linux.
This instance is only meant to be used and accessed internally – I can’t even setup smtp on this instance. My latest challenge is trying to figure out how to enjoy VisualEditor while also not having the read permissions open for everyone, because I would still like to meet a minimum bar of security.