Closed Bug 852708 Opened 11 years ago Closed 11 years ago

Remove Webtrends from [Bedrock] and php code bases on www.mozilla.org

Categories

(www.mozilla.org :: Analytics, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cmore, Assigned: sgarrity)

Details

(Whiteboard: r=114543)

We need to remove Webtrends from All www.mozilla.org pages on both the Bedrock and PHP side. Bedrock is easy, PHP will be more work and hopefully it will be easier given that we just went through adding GA to all php templates/includes.

Bug 818195 and bug 829723 should have most of the places that we need to touch. 

Contract end date is March 21st and we should remove WT off the site asap. If we don't have it off by the 21st, we *won't* get any 404's or other errors.
Malexis/Jen: can we add this to the mozilla.org backlog kan ban board?
Priority: -- → P2
Priority: P2 → P1
Assignee: nobody → steven
OS: Mac OS X → All
Hardware: x86 → All
Done in the mozilla.com trunk in r114543. This will need to be merged into stage/production.

Done in mozilla.org in r114544 (this doesn't need a merge).

Bedrock changes coming up next.
cmore: Do all of the dcsMultiTrack() references needed to be re-done for Google Analytics? You can see them all here: https://github.com/mozilla/bedrock/pull/735/files - they seem to mostly be for tracking offsite links, or in-page navigation (tabs, etc.).
(In reply to Steven Garrity from comment #5)
> cmore: Do all of the dcsMultiTrack() references needed to be re-done for
> Google Analytics? You can see them all here:
> https://github.com/mozilla/bedrock/pull/735/files - they seem to mostly be
> for tracking offsite links, or in-page navigation (tabs, etc.).

Remove the dcsmultitrack. Garteth, the new web analytics engineer is going to be helping define the type of interactions that we should be tracking to support site/page goals. New methods will be put in later. Thanks!
(In reply to raymond [:retornam] from comment #10)
> https://www.allizom.org/en-US/plugincheck/
> https://www.allizom.org/es-ES/firefox/18.0/firstrun/ from bug 829723 still
> have webtrends tags

Right, I still need pmac, or someone else with the permissions to merge the PHP changes into production.
(In reply to raymond [:retornam] from comment #10)
> Chris,
> This pull request was for bedrock pages  so 
> https://www.allizom.org/en-US/plugincheck/
> https://www.allizom.org/es-ES/firefox/18.0/firstrun/ from bug 829723 still
> have webtrends tags
> 
> https://www.allizom.org/en-US/firefox/update/  is en-US only
> https://www.allizom.org/en-US/firefox/sms/sent/ is en-US only
> https://www.allizom.org/en-US/firefox/sms/ is en-US only
> https://www.allizom.org/en-US/firefox/mobile/platforms/ is en-US only
> 
> https://www.allizom.org/de/firefox/new/ 
> https://www.allizom.org/fr/firefox/new/ have no webtrends tags

Got it. I just wanted to make sure that this bug wasn't going to be verified fixed before the php side is done too. :)
Whiteboard: r=114543
Pushed to prod for the .com portion in r115627.
http://www.mozilla.org/en-US/firefox/12.0beta/firstrun/
http://www.mozilla.org/en-US/firefox/13.0a2/firstrun/
http://www.mozilla.org/en-US/firefox/15.0a2/firstrun/
http://www.mozilla.org/en-US/firefox/17.0a2/firstrun/
http://www.mozilla.org/en-US/firefox/18.0a2/firstrun/
http://www.mozilla.org/en-US/firefox/19.0/firstrun/
http://www.mozilla.org/en-US/firefox/19.0.1/firstrun/
http://www.mozilla.org/en-US/firefox/19.0.2/firstrun/
http://www.mozilla.org/en-US/firefox/19.0a2/firstrun/
these links are fine 


The links below have issues 



http://www.mozilla.org/en-US/firefox/13.0beta/firstrun/ ---- has some JS from webtrends
http://www.mozilla.org/en-US/firefox/15.0beta/firstrun/ --- webtrends dcs JS
http://www.mozilla.org/en-US/firefox/16.0beta/firstrun/ -- webtrends dcs JS
http://www.mozilla.org/en-US/firefox/17.0beta/firstrun/ -- webtrends dcs JS
http://www.mozilla.org/en-US/firefox/18.0beta/firstrun/ --webtrends dcs JS
http://www.mozilla.org/en-US/firefox/19.0beta/firstrun/ --webtrends dcs JS
http://www.mozilla.org/en-US/firefox/9.0beta/firstrun/index.html --webtrends dcs JS
http://www.mozilla.org/en-US/firefox/8.0beta/firstrun/index.html --webtrends JS
http://www.mozilla.org/en-US/firefox/6.0beta/firstrun/index.html -- webtrends dcs JS
http://www.mozilla.org/en-US/firefox/5.0beta/firstrun/index.html -- webtrends dcs JS
http://www.mozilla.org/en-US/firefox/4.0/firstrun/index.html --webtrends dcs JS
http://www.mozilla.org/en-US/firefox/4.0/whatsnew/index.html --webtrends DCS JS
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I can clean these up, but I'm finding more similar pages by searching the source. Should these out-of-date firstrun/whatsnew pages still exist?

Perhaps they be removed and redirected to http://mozilla.org/firefox/out-of-date/
(In reply to Steven Garrity from comment #15)
> I can clean these up, but I'm finding more similar pages by searching the
> source. Should these out-of-date firstrun/whatsnew pages still exist?
> 
> Perhaps they be removed and redirected to
> http://mozilla.org/firefox/out-of-date/

Can you check how templates are created and use the out-of-date page contents? It looks like out-of-date is not accessed directly.
(In reply to Chris More [:cmore] from comment #16)
> Can you check how templates are created and use the out-of-date page
> contents? It looks like out-of-date is not accessed directly.

According to this gem in the PHP/SVN-based mozilla.com repo .htaccess file [1], we're supposed to be redirecting all but the latest firstrun/whatsnew pages to the out-of-date page. This doesn't actually seem to be working though.

My ApacheTegex-ese is rusty, but I think this means that anything but Firefox 3.6, 7,8,9 and 10-through-19 firstrun/whatsnew pages would redirect to the out-of-date page. The behaviour doesn't seem to hold up though. I think it is breaking on whether or not there is an index.html on the URL.

# Redirect all old firstrun versions to a out-of-date page
# NOTE: you need to add exceptions here for normal firstrun pages!!
# bug 538486
RewriteCond $1 !^(?:3.6.*|7.*|8.*|9.*|1[0-9].*|sync|aurora|backtoschool)$
RewriteRule en-US/firefox/(.*)/(whatsnew|firstrun)[/]? /en-US/firefox/out-of-date/ [PT,L] 

[1] http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/production/.htaccess?view=markup
Thanks for the investigation and that is a gem! I am leaning toward fixing this redirect logic, but send everyone to /en-US/firefox/update/ instead.
(In reply to Chris More [:cmore] from comment #18)
> Thanks for the investigation and that is a gem! I am leaning toward fixing
> this redirect logic, but send everyone to /en-US/firefox/update/ instead.

We'll have to l10n-ize the /firefox/update page, but this does sound like a good idea. I've filed Bug 869937 accordingly.
Updated all of the remaining PHP pages in the meantime - r116013 in trunk. Will need a review and push to production.
.org PHP pages updated in r116029.
Steven, is this still waiting for a code review?
Flags: needinfo?(steven)
(In reply to Mike Alexis [:malexis] from comment #22)
> Steven, is this still waiting for a code review?

Just need a review/merge-to-stage-and-prod. CC'ing sancus for a merge.
Flags: needinfo?(steven)
Looks like the en-US versions of firstrun were ported to bedrock in bug 833645, and all locales of whatsnew in bug 773739. Should we just delete all these files?
(In reply to Paul McLanahan [:pmac] from comment #24)
> Looks like the en-US versions of firstrun were ported to bedrock in bug
> 833645, and all locales of whatsnew in bug 773739. Should we just delete all
> these files?

Yes, you can delete legacy php firstrun/whatsnew. They aren't coming back. :)
(In reply to Chris More [:cmore] from comment #25)
> (In reply to Paul McLanahan [:pmac] from comment #24)
> > Looks like the en-US versions of firstrun were ported to bedrock in bug
> > 833645, and all locales of whatsnew in bug 773739. Should we just delete all
> > these files?
> 
> Yes, you can delete legacy php firstrun/whatsnew. They aren't coming back. :)

We are still serving non en-US firstrun pages for older versions. For example: https://www.mozilla.org/fr/firefox/8.0/firstrun/
(In reply to Steven Garrity [:sgarrity] from comment #26) 
> We are still serving non en-US firstrun pages for older versions. For
> example: https://www.mozilla.org/fr/firefox/8.0/firstrun/

I think it's all non-en-US firstrun, not just old versions. Though I believe that's being worked on elsewhere?
Changes merged to prod in r118959. We should probably open another bug for deleting all of those pages.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
(In reply to Paul McLanahan [:pmac] from comment #28)
> Changes merged to prod in r118959. We should probably open another bug for
> deleting all of those pages.

Thanks. Though the redirect destination may have changed, I think Bug 869937 can address this.
You need to log in before you can comment on or make changes to this bug.