I was made aware of bug 1242886, in which a hard-coded sumo URI was added to browser.js. We should be using app.support.baseURL For examples, visit http://mxr.mozilla.org/mozilla-central/search?string=app.support.baseURL Doing a search on MXR, it looks like there are many more instances of hard-coded sumo URIs. http://mxr.mozilla.org/mozilla-central/search?string=support.mozilla
Somewhat related: bug 1265006 ... which links to https://support.mozilla.org/en-US/kb/tab-groups-removal/discuss/6456
See Also: → 1265006
I've gone through instances of hard-coded links to sumo articles in the mxr link in comment 0, and used Hg Blame to find these people who added links to the code. Théo Chevalier [:tchevalier] (bug 716643) Gerald Squelart [:gerald] (bug 848994) Justin Dolske [:Dolske] (bug 901747) Ed Lee :Mardak (bug 1064515) :Felipe Gomes (bug 1081296) Tim Nguyen :ntim (bug 1105704) :Margaret Leibovic (bug 1107133, bug 1210386) Benjamin Smedberg [:bsmedberg](bug 1133000, bug 1133003) Martyn Haigh (:mhaigh) (bug 1157978) Chenxia Liu [:liuche] (bug 1187107) Sebastian Kaspari (:sebastian) (bug 1200665, bug 1225433, bug 1262105) Masatoshi Kimura [:emk] (bug 1218971) :Gijs Kruitbosch (bug 1221050) Johann Hofmann [:johannh] (bug 1242886) Jonathan Kingston [:kingstonTime] (bug 1273696) I've CCed them on this bug. I don't know if Firefox for Android supports app.support.baseURL, so I included those bugs as well. @Everyone I just CCed, When you want to add a link to a sumo article in the UI, use app.support.baseURL with a help-topic name. The support site will take care of the redirection. That way, the link will continue to work, even if the article is renamed, or the URI structure changed. No need to update the Firefox code. It's been like that since the Help menu started pointing to sumo in 2008 (bug 423486). I don't know if there's a technical reason why it wasn't done that way in the bugs listed above, but I get the feeling those people just didn't know.
(In reply to Chris Ilias [:cilias] from comment #2) > It's been like that since the Help menu started pointing to > sumo in 2008 (bug 423486). How often has the URI structure actually changed since then? > I don't know if there's a technical reason why it > wasn't done that way in the bugs listed above, It requires privileged JS, and many of these links are simply present as-is in (unprivileged) HTML/XUL markup, so you'd have to jump through hoops to use the pref. Even worse for items in .properties files (of which there are also a few). So fixing this is not trivial for quite some of the cases.
(In reply to Chris Ilias [:cilias] from comment #2) > I don't know if Firefox for Android supports > app.support.baseURL, so I included those bugs as well. It does, but only from JS. If we are trying to use the URL in Java, this makes the code much more complicated. Gijs's comment from above about privileged JS also applies to Android.
(In reply to :Gijs Kruitbosch from comment #3) > How often has the URI structure actually changed since then? Including the TLD, 3 times (that I can remember :) ) - In 2010, we switched from tikiwiki to kitsune. Before then we didn't even have slugs, and plus signs were used for spaces in article titles. - At some point, the domain changed from support.mozilla.COM to support.mozilla.ORG - And more recently, everything was switched from HTTP to HTTPS Now that sumodev no longer exists, there is talk about switching to another CMS. A couple more things I didn't mention above: - sumo adds parameters to the URI when an inproduct link is used. This enables everyone to know if people are arriving at an article from the product link, or somewhere else. That doesn't happen on hard-coded links. In at least one case where a sumo URI was hard-coded, I didn't see anyone from the sumo team CCed on the bug. When inproduct links were first implemented, the look of an article was different when accessed via an inproduct link. I don't know if that still applies today, though. - I don't know how much we care about projects that use Firefox code, like Palemoon, but there is no effort in sumo to support Palemoon specifically. > It requires privileged JS, and many of these links are simply present as-is > in (unprivileged) HTML/XUL markup, so you'd have to jump through hoops to > use the pref. Even worse for items in .properties files (of which there are > also a few). So fixing this is not trivial for quite some of the cases. Is there anything I can do to help? Do we really don't need to link to sumo in every one of those instances?
You need to log in before you can comment on or make changes to this bug.