Noticed this while cleaning up my CSP proof of concept:
Discourse.base_url_no_prefix seems to actually be the base url sans path (not protocol, as I would expect), compare base_url_no_prefix to base_url below:
https://github.com/discourse/discourse/blob/master/lib/discourse.rb#L250-L267
So, I propose base_url_no_prefix is renamed base_url_no_suffix or base_url_no_path to clear up any future confusion.
But it’s a prefix to all paths. A path suffix would be strange. I don’t agree that this name is confusing.
Seems fine as-is. It’s the base URL without a prefix. Saying no suffix on a base URL is redundant.
As to no path, that’s just confusing- it’s valid without a path, right?
But surely the method would have to be named base_url_no_path_prefix to be able to extract that meaning from it. With no mention of any path, there’s no reason to assume prefix refers to anything other than the base url’s prefix.
Don’t want to labour the point here (though after proofreading I realized I have), but suppose discourse were running from https://example.com/discourse:
Currently, the methods would produce the following:
base_uri: /discourse
base_protocol: https
base_url_no_prefix: https://example.com
base_url: https://example.com/discourse
Whereas if I were to take a guess at what they would produce without having read the source:
base_uri: ??? could be many many different things
base_protocol: https
base_url_no_prefix: example.com/discourse
base_url: https://example.com/discourse
I humbly propose those methods are renamed like so:
base_uri → base_path
base_protocol âś“
base_url_no_prefix → base_url_no_path (let’s remove any confusion over what prefix/suffix is referring to)
base_url âś“
But maybe my brain works a bit differently, I don’t mind that much - certainly less than the length of this post suggests 
You are not alone. I always need to look at this post whenever I work with base_* stuff.
@neil Any objections to adding @LeoMcA’s suggestions as method aliases? I have to add subfolder support to a bunch of translations and base_path would make a lot more sense to me than base_uri.
Sure, but I don’t like “base_url_no_prefix” meaning being switched to “remove http://” instead of “remove subfolder”.
Let’s use the word subfolder there since we all seem to know what that means. base_url_no_subfolder?
The meaning of base_url_no_prefix isn’t switched. It still removes the prefix (=path).
| Method | Alias | Output |
|---|---|---|
base_uri |
base_path |
/discourse |
base_protocol |
https |
|
base_url_no_prefix |
base_url_no_path |
https://example.com |
base_url |
https://example.com/discourse |
I think using “path” instead of “prefix” or “subfolder” works best.
So the code is going to be a mess of some places using base_url_no_prefix and some places using base_url_no_path, depending on the preference of who writes that code? I’m not a fan of that.
So the changes to existing would be:
base_uri becomes base_path: looks good to me.
base_url_no_prefix becomes base_url_no_path: also looks good.
I say we replace those instead of creating aliases.
I thought @LeoMcA wanted base_url_no_prefix to mean removing the “http://” which is a change of value and will cause bugs.
Except plugins might be using them. So maybe not.
I can rename the methods, update our code in core and deprecate the old method names. But yeah, removing them isn’t possible right now because I’m quite sure lots of plugins use them.
I more meant that that’s what it meant in my head, rather than wanting a method which does that to be named base_url_no_prefix (there’s no method named anything which does that currently IIRC).
If there was to be a method I’d suggest it be called base_url_no_protocol, but I’m not sure it’s necessary since current_hostname and base_uri can just be concatenated.
base_url_no_prefix → https://example.com
base_url → https://example.com/discourse
Yeah the use of the word prefix here is… kinda… wrong @neil? More like base_url_no_suffix, amirite?
So I support these renames, because broken naming only grows to hurt you more and more over time.