Closed Bug 414353 Opened 17 years ago Closed 17 years ago

Page redirect service for in-product help links

Categories

(support.mozilla.org :: General, defect, P1)

Product:
support.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: djst, Assigned: nkoth)

References

Details

(Whiteboard: sumo_only)

We need a redirecting service that allows us to now use hard-coded URL strings in Firefox 3 for in-product help. Could this be just a .htaccess file that redirects certain url patterns to the specific article on SUMO?
Depends on: 398353
s/now/not/
Should we use a pref-controlled URI scheme which includes locale and version, like AUS does? app.update.url = https://aus2.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
We could use mod_rewrite for this, and yes, it makes sense to follow a URI scheme; it eliminates the need to have any logic in the routing. We could do something like: http://support.mozilla.com/1/%PRODUCT%/%VERSION%/%PLATFORM%/%LOCALE%/ Not sure if we want to use SSL on the link. Are we concerned about man-in-the-middle attacks with support docs?
The question on whether to include the locale into the url or not is somewhat open to the locale choice algorithm. Or not, depending if we can overwrite that on the server. I guess, if we can, we should, to be on the safe side. I.e., include it in the url *and* overwrite it, with user setting, or accept_lang, even. Another thing in the URL, IMHO, should be the helptopic, as given in the preference pane overlays, helpTopic="prefs-main". By keying over the helpTopic itself, we're able to cut too long pages into two by mere server changes later.
(In reply to comment #4) > > Another thing in the URL, IMHO, should be the helptopic, as given in the > preference pane overlays, helpTopic="prefs-main". By keying over the helpTopic > itself, we're able to cut too long pages into two by mere server changes later. > Exactly -- this is important. Currently, the actual location you'll end up with is an anchor of a long article, but we might want to split it up in the future. Basically, every unique helpTopic should have its own mapping, even if it's linking to the same article but different anchors.
Severity: normal → critical
Priority: -- → P1
Severity: critical → blocker
http://support.mozilla.com/1/%PRODUCT%/%VERSION%/%PLATFORM%/%LOCALE%/<helptopic>/ makes sense to me, and I think SSL is overkill. That's one fantastic social hack, but social hacks of that complexity are Hard(tm) Thus, we'd get something like http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main/ which I think is easy to mod_rewrite in a bunch of different ways. Is there anything else that seems needed?
Is the version string "3.0" or "3.0.0"? That said, I think we will simply parse for 3* and make sure all 3.x.x versions enables "Firefox 3" view for articles.
Do we need %PRODUCT% if support.mozilla.com is Firefox-only?
Yes, keep it. Don't want to deviate from how other services work.
Status: NEW → ASSIGNED
Assignee: nobody → nelson
Status: ASSIGNED → NEW
which pages should this list of help topics point to?
can I get an authoritative list of help topics and pages they should point to? Thanks.
Chris, it's time that we rename the en-US in-product articles to the target names, e.g. "using_firebird-en-US" -> "Using Firefox". Can you take care of that today and provide the final URIs to point the individual help topics to as defined in http://mxr.mozilla.org/mozilla/search?string=helptopic&find=browser&findi=&filter=&tree=mozilla) Thanks!
Establishing the target names shouldn't be a problem today. There are a few articles that we need to combine with current KB articles, and maintaining links/associations will need testing on stage. I don't think that can be finished today, but I can make it P1 after the list is established.
As discussed on IM, we will rename any conflicting articles, then rename the *-en-US articles to their target (Fx2) names, and then we will have a full list of helptopic -> URI list here.
mconnor, do we use a helptopic for the main page as well? I.e. when you're selecting Help > Firefox Help from the menu.
I have assumed that the helptopic for "For Internet Explorer Users" is ieusers If this is incorrect. let me know.
So, what we're missing to get this checked in are: * helptopic/entry rule for start page (http://support.mozilla.com/%LOCALE%/kb/Firefox+Help) * helptopic/entry rule for "For Internet Explorer Users" (http://support.mozilla.com/%LOCALE%&kb/For+Internet+Explorer+Users)
> So, what we're missing to get this checked in are: > * helptopic/entry rule for start page That's "firefox-help". > * helptopic/entry rule for "For Internet Explorer Users" And that's "ieusers", see http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/base/content/baseMenuOverlay.xul&rev=1.17&mark=80,93#79 But that code (and the code in preferences.xml) needs to be changed anyway to open a new tab with the sumo page instead of the help viewer. Do we have a bug for that already?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Thanks Steffen for the info! This is now implemented on support.mozilla.com. Example: http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main
Status: RESOLVED → VERIFIED
Can we please change the platform part like so: WINNT (for Windows NT, 2000, XP and later) Linux (for all Linux versions) Darwin (for all MacOS X versions) Because those are the values returned by the url formatter for %OS%. And can we ignore the "b5pre" in the version part, i.e. ignore parts of the string starting with "a" or "b"?
Blocks: 423762
mconnor's patch in bug 423486 will take care of the version part, so no need to change that. The change to the platform part is still needed though.
I think we're ignoring the platform bit anyway, unless I'm wrong?
That's actually a bug that should be fixed, IMHO. The platform dependent firefox 3 content is there, we show firefox 2 windows, though.
(In reply to comment #25) > I think we're ignoring the platform bit anyway, unless I'm wrong? > Where is it ignored you mean? SUMO uses the platform bit to set the content customization filter for an article (win/mac/linux).
If I open this link on Windows, the windows version is displayed: http://support.mozilla.com/1/firefox/3.0/mac/en-US/prefs-main
To add, the sumo redirects seem to ignore both platform and version, but sumo picks them up again from the useragent. The fx3 mac link here gets me to fx2 windows prefs, if I open it in Firefox 2.0.0.12 on windows, and to mac fx3 options if I open it in minefield on my mac. I.e., I see preferences vs options, and the applications options only if I open the link from a fx3.
Oops, my bad. Yes, we currently ignore the url parts specifying os/version because we use js to show/hide content anyway, so we can might as well use js to detect stuff. If this is a bad idea for other reasons (such as browser UA spoofing), this should be easy to fix.
Blocks: 423486
No longer blocks: 423762
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.