Closed Bug 466125 Opened 16 years ago Closed 16 years ago

Add .htaccess rules for new in-product help link "places-locked"

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: djst, Assigned: laura)

References

()

Details

(Keywords: fixed1.9.1, Whiteboard: sumo_only)

With bug 414715, we'll get a new product help link from Firefox (http://support.mozilla.com/1/%APP%/%VERSION%/%OS%/%LOCALE%/places-locked) that needs to be directed to the correct article.

For now, let's use the article Bookmarks+not+saved#Bookmarks_file_is_write_protected, but we might want to move this out to an article of its own for added clarity.
Would having its own article be a better idea for l10n as well?
i think a separate article is the long term solution. we need to move this to 0.8 because 0.7.3. code freeze is today, so let's create a separate article for this.
Target Milestone: 0.7.3 → 0.8
Target Milestone: 0.8 → 0.9
Flags: blocking-firefox3.1?
Depends on: 467814
We're about to check in the fix for this. The drop-dead date for this is when 3.1b3 is shipped. However, it'd reduce nightly-tester confusion if at least a placeholder page is in place as soon as possible.
Chris, what's the final URL to the standalone article?
Priority: -- → P1
Target Milestone: 0.9 → 0.8.1
OK, so we need this line to be added to .htaccess:

RewriteRule ^1/([\-a-zA-Z]+)/([\.0-9ab]+(?:pre)?)/([\-_a-zA-Z0-9]+)/([\-a-zA-Z]+)/places-locked\/$  /$4/kb/The+bookmarks+and+history+system+will+not+be+functional?style_mode=inproduct [R,NE]

Someone with svn, please help submitting a patch!
Assignee: nobody → laura
In trunk r21432, prod r21433.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
We need an IT person to run 
sudo webroot/htaccess.sh 
on staging before you can verify.
Who from IT do we CC on this? Cause the URL no worky.
(In reply to comment #10)
> Who from IT do we CC on this? Cause the URL no worky.

reed, I think?
Reed, can you check that htaccess.sh was run *after* the svn checkout was
unborked?
(In reply to comment #12)
> Reed, can you check that htaccess.sh was run *after* the svn checkout was
> unborked?

It wasn't. Done now on staging and production. Seems to work fine.
Both production and staging are now working fine; Verified FIXED!
Status: RESOLVED → VERIFIED
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Whiteboard: sumo_only
You need to log in before you can comment on or make changes to this bug.