Closed Bug 869937 Opened 11 years ago Closed 11 years ago

Redirect out-of-date firstrun/whatsnew pages to /firefox/update and remove old pages

Categories

(www.mozilla.org :: Bedrock, defect, P3)

Product:
www.mozilla.org
Component:
Bedrock
Platform:
x86_64
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: sgarrity, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kb=1141849] )

Attachments

(2 files)

bug-869937-remove-whatsnew.diff
2.43 MB, patch
Details | Diff | Splinter Review
bug-869937-remove-whatsnew-status.txt
37.93 KB, text/plain
Details 
As per cmore's suggestions on Bug 852708#c18, the firstrun and whatsnew pages for out-of-date versions of Firefox (any version other than the current, I think), should redirect to /firefox/update

In order to do this, /firefox/update will need to be localized.

The firstrun/whatsnew pages that this replaces should then be removed from SVN.

This should probably obsolete /firefox/out-of-date/ too.
Priority: -- → P3
CC'ing pascal to inquire about the l10n process for this page. Pascal, we'd like to archive all of the out-of-date firefox firstrun/whatsnew pages and redirect the URLs to the /firefox/update page.

I presume we can't do this until that page has been localized? Can you confirm this and let us know what the next step is?
Also, to simplify/speed-up the process, I would propose we could still display the page without localizing all of the FAQ content - only only display that content if/when it gets translated for a given locale.

All that leaves us with is the basic header text:

 Congratulations!
 Your Firefox is up to date.

 Your Firefox is out of date.
 Get the newest version <a>here</a>.
(In reply to Steven Garrity from comment #2)
> Also, to simplify/speed-up the process, I would propose we could still
> display the page without localizing all of the FAQ content - only only
> display that content if/when it gets translated for a given locale.
 
I wouldn't do that, not for a page with such visibility. Instead, make all the content localizable and let local teams determine if they have time/resources to localize everything. If they don't, content will be redirected to en-US.

Exposing partially localized pages to users make the work of localizers look sloppy, and that's not something we want ;-)

For the same reason I would suggest that we leave some time to localize those strings before enabling the redirects.
Yes, we should first update that page. I propose that we work on that next week together to launch that localization for all of our locales.
Pull request that wraps the strings on this page for l10n: https://github.com/mozilla/bedrock/pull/929
Sounds good Pascal.

While we get the l10n situation sorted out, we could do this for en-US right away. The question is, how?

We want to redirect /en-US/firefox/XX.X/firstrun/ to /firefox/update
(and the same for the "whatsnew" page)
but we need to exclude the current version of Firefox (does that ever vary by platform/locale?) and any other special cases (like /firefox/nightly/firstrun/).

Is there a way we can somehow let apache what the latest first version # is?
(In reply to Steven Garrity from comment #6)
I thought this was already done:

https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/views.py#L134

That's in place for firstrun and whatsnew in bedrock, and the pass-throughs seem to be there for all locales. If this isn't working it's a bug.
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/ad7f73618fc93cf2268507b741bf5373794826cb
Wrap strings for l10n (Bug 869937)
Also updated the headline text for non-Firefox users for Bug 864483

https://github.com/mozilla/bedrock/commit/57ba5290e42c549fa92ad1e014de221fd96d4e62
Merge pull request #929 from sgarrity/bug-869937-update-l10n

Wrap strings for l10n (Bug 869937)
(In reply to Paul McLanahan [:pmac] from comment #7)
> That's in place for firstrun and whatsnew in bedrock, and the pass-throughs
> seem to be there for all locales. If this isn't working it's a bug.

It turns out I was running into two issues here.

First, if you include the tailing index.html on the end of the URLs, the old pages leak through. I don't think the in-product URLs for firstrun/whatsnew included the index.html, but it's going to be addressed in Bug 832348 anyhow.

Second, pages with 'beta' or 'rc' after the version number aren't getting caught by the /b/ redirect in bedrock (https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf#L216). For example:

https://www.mozilla.org/en-US/firefox/16.0beta/firstrun/
https://www.mozilla.org/en-US/firefox/13.0beta/whatsnew/
https://www.mozilla.org/en-US/firefox/3.6.19rc/whatsnew/

pmac, I think we could address this by replacing the (?:pre) with (?:[pre|beta|rc]?) but I'd like a more regex/apache aware person to confirm that. This would have to apply to both the firstrun and whatsnew redirects.
I'm very inclined to make that regex a lot less complex. I'm not sure I care what is in between "firefox" and "whatsnew" or "firstrun". We can leave it to django to work out whether the version is valid. Unless someone objects, I'm in favor of changing that rule to:

RewriteRule ^/en-US/firefox/(.+)/firstrun(/?)$ /b/en-US/firefox/$1/firstrun$2 [PT]

And I think we should do something similar to the "whatsnew" rule.
(In reply to Paul McLanahan [:pmac] from comment #10)
> I'm very inclined to make that regex a lot less complex. I'm not sure I care
> what is in between "firefox" and "whatsnew" or "firstrun". We can leave it
> to django to work out whether the version is valid. Unless someone objects,
> I'm in favor of changing that rule to:

Does this mean there is essentially only one firstrun page at any given time - not one-per-version? This might make sense given the rapid-release-cycle.
It does mean that. Other browsers are redirected. The php version had the possibility of having different pages, but in practice they were all just copies of the same file (mostly).
(In reply to Paul McLanahan [:pmac] from comment #12)
> It does mean that. Other browsers are redirected. The php version had the
> possibility of having different pages, but in practice they were all just
> copies of the same file (mostly).

I like the sounds of that. In the past, there have been special additions to firstrun/whatsnew pages for versions with major changes (or region-specific changes). This still might be fine, since we'll still really only have two versions: current, and out-of-date.

This also begs the question: should the version # even be in the URL? That comes from the browser itself though.
Also firstrun/whatsnew is disabled on Aurora and Nightly builds. Beta will be the only one still popping those URLs and for the most part, are copies of release channel. I would probably keep the version numbers in the URL in case we move to a model in the future where we can target specific versions of Firefox. 

The URLs comes from here:

http://mxr.mozilla.org/mozilla-central/source/browser/branding/official/pref/firefox-branding.js#6
This is blocked on getting /firefox/update l10n-ized.
/firefox/update/ and /firefox/fx/ will soon be going away and we should not be doing anything to these pages. They will be eventually redirected to /firefox/new/ and /firefox/new/ will be renamed/redirect to /firefox/download/ (final step) which is the Unified Firefox Download page that the Silver Orange devs are just about done. Learn more: https://wiki.mozilla.org/Websites/Mozilla.org/Unified-Firefox-Download
(In reply to Chris More [:cmore] from comment #16)
> /firefox/update/ and /firefox/fx/ will soon be going away and we should not
> be doing anything to these pages.

Ah, right. In that case, this is blocked on Bug 868199.
Blocks: 868199
Pmac/Steven: Ok, it looks like we have a problem here! This redirect described in this bug appears to have been in place in production for a LONG time. It probably has been in production as long as whatsnew has been localized in bedrock. 

This line is redirecting all locales to /firefox/update/ and /firefox/update/ is not localized as described in bug 893006.

I checked analytics and 30% of /en-US/firefox/update/ traffic are non-en-US and probably coming in through this redirect.

Try for yourself here:

curl -H  "Accept-Language: fr" -ILA "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/16.0 Firefox/16.0" http://www.mozilla.org/fr/firefox/16.0/whatsnew/

That redirects to: http://www.mozilla.org/en-US/firefox/update/
Blocks: 893006
I propose that we point people to /firefox/new/ instead of /firefox/update/ because it has been affecting people for a long time and still is. It may not say "you are out of date", but it will soon.
No longer blocks: 893006
(In reply to Chris More [:cmore] from comment #19)
> I propose that we point people to /firefox/new/ instead of /firefox/update/
> because it has been affecting people for a long time and still is. 

Not sure if it matters, but we already have 12 locales with a complete localization of update.lang
No longer blocks: 868199
Depends on: 868199
No longer depends on: 868199
Now that we have the new /firefox/new page, we may be able to start redirecting these old firstrun/whatsnew pages. We have a lot of locales covered on /new, but not all yet.

Here's a list of locales that have some version of a firstrun or whatsnew page, but do not have the /new page localized yet (asterisks are locales that seem to get en-US or a 404 on /new page

ach
af
*ak
as
be
bn-BD
bn-IN
bs
*cy
*eu
fa
ff
gl
gu-IN
he
hi-IN
km
kn
ku
*mai
mn
*ms
nn-NO
nso
oc
or
si
*sw
ta-LK
th
ur
vi
wo
*zu

Should we redirect/remove the old firstrun/whatsnew pages for other locales now, or wait until all locales are done and do it all at once?
We don't ship Firefox yet for ak, ms, sw and zu
eu and cy do have a localized /new page:
http://www.mozilla.org/eu/firefox/new/
http://www.mozilla.org/cy/firefox/new/
Also, almost all of these locales have a localized /new page (the one on the php site) so if we want them to updgrade, that works too. therefore it's ok for me to redirect these pages to /new
The problem with redirecting to /new pages for locales where that page still lives on the PHP site (example: http://www.mozilla.org/si/firefox/new/) is that those pages don't have any of the version-checking logic of the new page.

That said, it may be better to go there than an even more out of date firstrun/whatsnew page?

:cmore?
Flags: needinfo?(chrismore.bugzilla)
(In reply to Steven Garrity [:sgarrity] from comment #24)
> The problem with redirecting to /new pages for locales where that page still
> lives on the PHP site (example: http://www.mozilla.org/si/firefox/new/) is
> that those pages don't have any of the version-checking logic of the new
> page.
> 
> That said, it may be better to go there than an even more out of date
> firstrun/whatsnew page?
> 
> :cmore?

I think [locale]/firefox/new/ is still the best choice given that the vast majority of traffic is to locales where /firefox/new/ is the new unified page. Additional locales will come in over time.
Flags: needinfo?(chrismore.bugzilla)
Here's a PR to add the broad redirects for /firefox/*/whatsnew/ and /firefox/*/firstrun/ to bedrock, which already knows what to do based on the browser version: https://github.com/mozilla/bedrock/pull/1291

This seems to simple/easy to be right... pmac, can you review?
Flags: needinfo?(pmac)
Also, once this is in place, there will be a lot of redundant redirects we should be able to remove from the PHP .htacces file.
I commented on the PR.
Flags: needinfo?(pmac)
Ok, so it turns out that the whatsnew page is ready for such a redirect, but the firstrun page is still en-US only on bedrock.

We could do this for whatsnew pages now, and clean them out of the PHP site, or we could wait for the l10n-friendly firstrun page and do it all at once.
Whiteboard: [kb=1141849]
Depends on: 924552
Accordingly to line #193 in global.conf [1] we're already redirecting all whatsnew variations to bedrock. We should be able to safely remove all whatsnew related pages from SVN.  I have filed Bug 924552 to track this.

[1] https://github.com/mozilla/bedrock/blob/master/etc/httpd/global.conf#L193
Here's a big a** diff that removes all whatsnew page files and the en-US firstrun pages, as they are no longer used.

It's mostly just removed files and a few modifications removing references to whatsnew CSS/JS/PHP includes. The diff is large enough that it's probably not feasible to look through every file, so I'm also going to attach the output of "svn status" to get a more readable list of removed/modified files.
Attachment #814860 - Flags: review?(pmac)
Attachment #814860 - Flags: feedback?(pascalc)
Here's the output of "svn status" for the previously posted diff. This gives a more readable summary of what has been removed.
for locales, that looks good to me
:sgarrity: what if we just make the out-of-date whatsnew/firstrun redirects only in bedrock even though firstrun is en-US only in bedrock? As more content is converted to bedrock, these out-of-date redirects will capture more and more visitors. I am also worried that the idea behind this bug was less legacy clean up and more improving UX. The original idea for this bug is if that someone would install an old version of Firefox not on purpose, get a firstrun/whatsnew page and not realize they are not on the latest version. I want to redirect visitors to /firefox/new/ if they land on a whatsnew/firstrun page with a version of Firefox that is less than latest Firefox variable's value. For example, a user could install Firefox 7, go to this page http://www.mozilla.org/en-US/firefox/7.0/whatsnew/, and think they are up to date. /whatsnew en-US and locales are on bedrock where as /firstrun is en-US only on Bedrock and the rest on PHP. For the Australis project we are working on a new possible firstrun experience that would deprecate the en-US and locales php versions of /firstrun thus I wouldn't make this redirect capture the php also. 

Should we meet on this to get on the same page? We don't have new firstrun content yet and this out-of-date redirect could be in place in bedrock now and once other php pages get pulled into bedrock, this redirect would also handle those locales too. I don't think it has to be blocker.
:cmore: I'm not quite sure I follow the suggestion to "just make the out-of-date whatsnew/firstrun redirects only in bedrock even though firstrun is en-US only in bedrock". We should probably talk it.
(In reply to Steven Garrity [:sgarrity] from comment #35)
> :cmore: I'm not quite sure I follow the suggestion to "just make the
> out-of-date whatsnew/firstrun redirects only in bedrock even though firstrun
> is en-US only in bedrock". We should probably talk it.

let's talk at the mozilla.org meeting. What I mean is to not worry about the locales that are not in bedrock now as they will be soon. We should be able to do this redirect in bedrock directly and not have to put it on the php side.
(In reply to Chris More [:cmore] from comment #34)
> For example, a user could install Firefox 7, go to this page http://www.mozilla.org/en-US/firefox/7.0/whatsnew/, and think they are up to date.

Chris, this is already the case. If you visit mozilla.org/firefox/7.0/whatsnew/ with Firefox 7 (or any out-of-date Firefox version), you'll be redirected to the /new page which will inform you that you are out-of-date. Is that what you meant, or am I misunderstanding?
Ok, it looks like this is working as-is. Closing. Thanks!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Comment on attachment 814860 [details] [diff] [review]
bug-869937-remove-whatsnew.diff

Moved the SVN remove patch over to the more specific Bug 924552.
Attachment #814860 - Flags: review?(pmac)
Attachment #814860 - Flags: feedback?(pascalc)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: