Closed Bug 431591 Opened 16 years ago Closed 15 years ago

Collapse FF2 in-product pages

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: clouserw, Assigned: clouserw)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

PHP to detect version
1.34 KB, patch
reed
: review+
Details | Diff | Splinter Review
fix .htaccess
1.07 KB, patch
reed
: review+
Details | Diff | Splinter Review 
I talked about this somewhere (email?) and we agreed it was a good idea.  I don't think there is a bug for it yet though.

I want to add the following redirects; $lang = any locale, $version = any FF2 version:

/$lang/firefox/$version/firstrun/ -> /$lang/firefox/2.0/firstrun/
/$lang/firefox/$version/whatsnew/ -> /$lang/firefox/2.0/whatsnew/

we can replace "2.0" with something else if that would be more appropriate.  Releasenotes will remain where they are, the files affected by the redirect will be deleted.  This will save us space/time/bandwidth/etc and it will be easier to maintain (eg. we can change the firstrun page to say "congrats.  Also, you should upgrade.").

I'd like to land this change on the FF3 branch so it can launch with FF3.  Looking for approval in this bug.
A couple of things:

1. When we do our release to "beta" testers, we redirect
     /$lang/firefox/2.0.0.x/* -> /$lang/firefox/2.0.0.xrc/*

   Will this change affect that redirect? We use a special whatsnew page.

2. Sometimes our whatsnew page is different. For example, 2.0.0.11 was a
   compatibility release and contained no security updates. It had a different
   whatsnew page. How will these redirects handle that?

   http://www.mozilla.com/en-US/firefox/2.0.0.10/whatsnew/
   http://www.mozilla.com/en-US/firefox/2.0.0.11/whatsnew/
> 1. When we do our release to "beta" testers, we redirect
>      /$lang/firefox/2.0.0.x/* -> /$lang/firefox/2.0.0.xrc/*
> 
>    Will this change affect that redirect? We use a special whatsnew page.

If you want to keep versions ending with "rc" we could do that and redirect them all to a separate page?  Otherwise I'd suggest redirecting them to the same /2.0/ pages.

> 2. Sometimes our whatsnew page is different. For example, 2.0.0.11 was a
>    compatibility release and contained no security updates. It had a different
>    whatsnew page. How will these redirects handle that?
> 
>    http://www.mozilla.com/en-US/firefox/2.0.0.10/whatsnew/
>    http://www.mozilla.com/en-US/firefox/2.0.0.11/whatsnew/

Everything goes to the same place - we should make a generic whatsnew page that talks about upgrading to firefox3.  Releasenotes will still be around if people really want to know what changed.
(In reply to comment #2)
> If you want to keep versions ending with "rc" we could do that and redirect
> them all to a separate page?  Otherwise I'd suggest redirecting them to the
> same /2.0/ pages.

It's not about seeing the 'rc'; users don't actually see that, they only see 2.0.0.x in the URL bar. We have special pages for beta users that explain they're in the beta channel and give more information about it. We don't want them to be the same pages (i.e., the 2.0 set) when we're in beta.

> Everything goes to the same place - we should make a generic whatsnew page that
> talks about upgrading to firefox3.  Releasenotes will still be around if people
> really want to know what changed.

Our current "generic" one was the security one but there are times we can't use that because the release isn't truly a security update. 90% of the time we want our messaging to be "Look at how secure we're keeping you!" but the rest of the time we need to change it.
Is this only for 2.0.0.x?

Both of Sam's comments in comment #1 need to be sufficiently addressed before we can do this. We can't lose that functionality. We need to be able to support our beta pages and the different whatsnew types. Some JS with version checking may suffice for this purpose, though. I'll think about this later this week when I have time.
Couldn't we just have a generic release candidate page and a generic release page?

How important is it that we distinguish a security release from a compatibility release when we're talking about such old releases?  If it's important the JS sniffing reed talked about would work.
We're not just talking about "old releases". We're talking about the next 2.0.0.x releases as well (at least seven months worth at this point) and we have no idea what they'll be (security, web compat, stability-only, etc.).

We could probably have a generic RC page, but right now we specifically call out the fact that it's an RC and when it was released to users and also do so on the relnotes page. I suppose we could just not show it on the firstrun and just link to the relnotes page for that information. Who's doing the writing? ;)
Could we get by with:

- Generic RC page
- Generic security release page
- Generic compatibility release page

We could even leave current versions of Firefox out of it, so anything >= to 2.0.0.14 could keep it's custom page until the next release.

Converting all the old pages to use the new FF3 style is a substantial amount of work in addition to all the things I listed in comment #0 which is why I'm pushing this.
Also, I'll need to know one way or the other on this as soon as possible as cleaning up the old first-run pages will take some time.
(In reply to comment #7)
> - Generic RC page
> - Generic security release page
> - Generic compatibility release page
This plan sounds great to me. Unless I'm missing something (which is possible), I don't see much value in having Steven spend a bunch of time converting ALL the versions of the FF2 pages. A generic one for each case seems like a good solution.

Pkim, you have more history on this stuff than I do. What do you think? Should we proceed?
Blocks: 437474
Flags: blocking-firefox3?
Sounds fine to me John, to only update these 3 pages to the new Firefox 3 web style. 

The full set of in-product pages for Fx2 is listed here: http://wiki.mozilla.org/Firefox2/In-Product_Web_Pages - just to confirm, these pages will live on, and retain Firefox 2 web style, correct?  
sgarrity's request is expanding the scope of this bug, but I want to be clear with what I'm suggesting.  I'm proposing creating a rewrite for the following content (this means if someone goes to /firefox/2.0.0.4/firstrun/ the url won't change but they'll get the content from where the rewrite is pointing):


Firstrun pages.  Versions 2.0 -> 2.0.0.5 are all the exact same page, and 2.0.0.6 -> 2.0.0.14 are all the same page.  I'd like to pick one of the two versions and just rewrite all firstrun content to that page.  Something like (not tested!):  RewriteRule ^(\w{2,3}(?:-\w{2}(?:-mac)?)?/)?firefox/2\.0\.*$ $1firefox/2.0/firstrun/ [PT]

Whatsnew upgrade pages.  Versions 2.0 -> 2.0.0.4 are all the same.  2.0.0.5 -> 2.0.0.9 and 2.0.0.12 are all the same.  I'd like to pick one version of the two and rewrite them all to that page.

Whatsnew security pages.  Verions 2.0.0.10, 2.0.0.13, and 2.0.0.14 are all the exact same page and it mentions security.  If we need a separate page for these (and it sounds like we do) I'd like to make rewrites and point them all to a single page.  This should have no affect from a user's point of view.

RC whatsnew pages.  Versions 2.0.0.4rc, 2.0.0.6rc - 2.0.0.11rc are all the same thing (aside from mention of a version number in the text).  Versions 2.0.0.12rc - 2.0.0.14rc are all the same thing aside from the version number as well.  I'd like to pick one of the two versions, rewrite it to remove the specific version number in the text (there are no localized versions of these), and rewrite all pages to use it.

(In reply to comment #10)
> The full set of in-product pages for Fx2 is listed here:
> http://wiki.mozilla.org/Firefox2/In-Product_Web_Pages - 

I'm only talking about firstrun and whatsnew pages.  The others are already FF3 styled because they are already shared pages (which is essentially what I'm asking for in this bug)
This plan seems to make a lot of sense. Thumbs up from me.
This will implement the rewrites I outlined in comment #11.  There are some additional steps to do:

1) Get r+ on this patch.
2) Copy the 2.0.0.10 version of the whatsnew page to /$lang/firefox/whatsnew/security.html for every locale
3) Copy the 2.0.0.12rc version of whatsnew to /en-US/firefox/whatsnew/rc.html (there is no localized versions of these)
4) Remove all extra firstrun/whatsnew pages from SVN for all locales.  The 2.0 directory will remain complete and the remaining directories will still contain releasenotes.
5) sgarrity will only need to style the /$lang/2.0/firstrun/ and /$lang/2.0/whatsnew/* pages (4 per locale) rather than locale * versions * 2 pages.
Attachment #324925 - Flags: review?(reed)
Comment on attachment 324925 [details] [diff] [review]
htaccess rewrites to implement comment #11

Also looking for review from Pascal - this affects a lot of locales, however, it should be transparent to the end user.
Attachment #324925 - Flags: review?(sunpascal)
Comment on attachment 324925 [details] [diff] [review]
htaccess rewrites to implement comment #11

r=me... get rid of the extra line when committing, please.
Attachment #324925 - Flags: review?(reed) → review+
Attachment #324925 - Flags: review?(sunpascal)
Attachment #324925 - Flags: review?(reed)
Attachment #324925 - Flags: review?(pascalc)
Attachment #324925 - Flags: review+
Attachment #324925 - Flags: review?(reed) → review+
(In reply to comment #13)
> 3) Copy the 2.0.0.12rc version of whatsnew to /en-US/firefox/whatsnew/rc.html
> (there is no localized versions of these)

No, but there are dates / version numbers involved. How are you solving that or are you removing them? If you're removing them, are you rewriting a bit of the text so it makes sense and points people to release notes? Or am I just recreating these files going forward (i.e., for 2.0.0.15, we'll be back to the same format we're using now)?
(In reply to comment #16)
> (In reply to comment #13)
> > 3) Copy the 2.0.0.12rc version of whatsnew to /en-US/firefox/whatsnew/rc.html
> > (there is no localized versions of these)
> 
> No, but there are dates / version numbers involved. How are you solving that or
> are you removing them? If you're removing them, are you rewriting a bit of the
> text so it makes sense and points people to release notes? Or am I just
> recreating these files going forward (i.e., for 2.0.0.15, we'll be back to the
> same format we're using now)?
> 

There are no dates but there are version numbers.  I just replaced "The final release of Firefox 2.0.0.12..." with "The final release of this version of Firefox..."  This would mean in the future you wouldn't need to create whatsnew pages - just add the version to the rewrite rule (or let reed or I know) - it's a 2 digit change.

However, the releasenotes link is trouble.  The whatsnew pages currently link to ../releasenotes which works for each page but ruins my plan.  I could have them all link to http://www.mozilla.com/en-US/firefox/releases/ or do some code in PHP to generate the releasenotes link using the version in the URL.
(In reply to comment #17)
> However, the releasenotes link is trouble.  The whatsnew pages currently link
> to ../releasenotes which works for each page but ruins my plan.  I could have
> them all link to http://www.mozilla.com/en-US/firefox/releases/ or do some code
> in PHP to generate the releasenotes link using the version in the URL.
> 

Here is code to fix this.  It checks if the file exists before including the link - after I wrote it that seemed unnecessary since we're restricting the version number via .htaccess.  I'm fine with doing it either way.
Attachment #324979 - Flags: review?(reed)
Attached patch fix .htaccess — — Splinter Review 
The way we were doing rewrites was broken...must have been tired last night. :)
Attachment #324925 - Attachment is obsolete: true
Attachment #324980 - Flags: review?(reed)
Attachment #324925 - Flags: review?(pascalc)
Comment on attachment 324980 [details] [diff] [review]
fix .htaccess

sigh, indeed, we were tired. I'm still quite tired. :(

Could possibly use ranges here for long stretches like 2-9, but I don't care.
Attachment #324980 - Flags: review?(reed) → review+
When am I going to be able to test this? :-)
I have one concern with the plan which is that we have lost Bulgarian for Firefox 3, which means that we can't propose them a page to upgrade to Firefox3. can an exception be kept for them?
Why does this need to block the final release of Firefox 3?
(In reply to comment #23)
> Why does this need to block the final release of Firefox 3?
> 

I don't think it does.  We're talking about the style of FF2 firstrun/whatsnew pages.  If this isn't fixed by then they will be ugly but I don't think it blocks.  I'd support critical though.

(In reply to comment #22)
> I have one concern with the plan which is that we have lost Bulgarian for
> Firefox 3, which means that we can't propose them a page to upgrade to
> Firefox3. can an exception be kept for them?
> 

We're not talking about upgrade pages here.  We're talking about whatsnew and firstrun pages; neither of which say anything about upgrading.  I think we can worry about exceptions in $x months when we're ready to really encourage people to switch from FF2 -> FF3.
(In reply to comment #24)
> I don't think it does.  We're talking about the style of FF2 firstrun/whatsnew
> pages.  If this isn't fixed by then they will be ugly but I don't think it
> blocks.  I'd support critical though.

If it's not going to be fixed for launch, I can do some emergency stylin' to mitigate the ugliness. I'd like to know as soon as possible though, so I can plan for this.
(In reply to comment #25)
> If it's not going to be fixed for launch, I can do some emergency stylin' to
> mitigate the ugliness. I'd like to know as soon as possible though, so I can
> plan for this.
Sounds to me like you should go ahead and do this. Thanks!


As per Wil's comments. Steven, thanks for the help on the emergency stylin'.
Flags: blocking-firefox3? → blocking-firefox3-
Emergency stylin' done in r15695. All of the 2.x and 3.0beta/rc firstrun and whatsnew pages are now restored to look right (in their old dalvay style).
Comment on attachment 324979 [details] [diff] [review]
PHP to detect version

Not tested, but I trust you. Looks reasonable enough, but again, I didn't closely test it as well I usually try to do...
Attachment #324979 - Flags: review?(reed) → review+
Steven, have you also run a test for the localized pages? Or has Pascal to do a mass-update?
Is this still an open issue?
(In reply to comment #32)
> Is this still an open issue?

All the emergency stuff is fixed.  The original request is still not resolved and it's assigned to me.
Can we delete all Firefox 2 pages please?
r55106 & r55108 adds the redirects to the .htaccess, as well as generic firstrun and whatsnew pages for every locale.

r55110 removes all the individual firstrun and whatsnew pages.

QA:  All old URLs for whatsnew and firstrun pages (e.g. en-US/firefox/2.0.0.4/whatsnew/) should redirect to the new pages (e.g. en-US/firefox/2/whatsnew/).  This goes for all Fx2 versions of the form:

2.0
2.0.0.1
2.0.0.10
2.0.0.2rc
2.0.0.3rc1

Since this is a massive change between tags, kubla is probably dead until we push this all the way through.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified, FIXED.
Verified combination of 6 different locales with different 2.0/2.0.0.1/...etc
versions
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: