User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140716183446 Steps to reproduce: Old copy/paste Get Firefox-code should still be supported... <a title="Get Firefox - The Browser, Reloaded" href="http://getfirefox.com/"> <img width="178" height="60" border="0" alt="Get Firefox" src="http://www.mozilla.org/products/firefox/buttons/getfirefox_large.png"></img> </a> Looks bad on websites that don't actively update their code.. Please check also the error-text on the 404-errorpage: If you typed in the address, check your spelling. Could just be a typo. If you’ve found an issue with one of our websites, we’d appreciate it if you could report the problem in Bugzilla, our bug tracker. One of our developers will take a look at it as soon as possible. If you followed a link, it’s probably broken. If you’re not sure what you’re looking for, start at mozilla.org The link to Bugzilla ends up on Mozilla.com, instead of ending up on bugzilla.mozilla.org Actual results: The image-source ends up on the mozilla.org 404-errorpage. Please check the Expected results: The thumbnail should be available
We may probably need stats to see how many blogs are still using the button.
I think it's a wrong approach to rely on your logs, and to do a decision based on that. The "damage" has already happened when someone get's to a page and finds a broken link/image/etc. I think the best way to solve similar issues is to maintain all links to buttons etc you ever have released. The point with such remote images is that you can update them to contain the latest version of whatever content you want people to share. These links should be there forever. I think it's a really bad policy and ignorance against people browsing the web when webmasters abandon old links when redesigning a website or changing it's underlying engine. This breaks the history of a site. Now when storage is cheap, it's absolutely ridiculous to delete old content and blaim eg. the need to save space. my 2 cents
Hey Kohei, I don't have any data on what pages these buttons would appear on. But this is a good idea moving forward, especially for download buttons as it would let me better segment download conversion rates. Thanks. Gareth
I'm 99% I had IT pull apache logs for these old buttons, while there were some 404s to these URLs, I think they were almost none. This could have been another old URL, but these seem familiar. Let me see if I can dig them up.
I've investigated this further. 1) http://www.mozilla.org/products/firefox/* has been redirected to http://www.mozilla.org/firefox/* and passes along any sub directories via an htaccess redirect given that we no longer use the /products/firefox/ naming structure. For example, http://www.mozilla.org/products/firefox/foo redirects to https://www.mozilla.org/en-US/firefox/foo 2) http://www.mozilla.org/products/firefox/buttons/getfirefox_large.png gets redirected to https://www.mozilla.org/en-US/firefox/buttons/getfirefox_large.png and that 404's. 3) We would have to check the apache log files to see how many requests are to URLs that contain /firefox/buttons/ as they won't be in Google Analytics because they are probably being requested via an img src. 4) On the legacy php 404 page, the link to bugzilla is https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org doesn't appear to be mozilla.com as described in comment 0. Here's what I did find in Google Analytics and the amount of monthly pageviews to those 404 URLS. Page Pageviews /en-US/firefox/buttons/getfirefox_88x31.png 23 /en-US/firefox/buttons/firefox_80x15.png 16 /fr/firefox/buttons/firefox_80x15.png 14 /fr/firefox/buttons/getfirefox_88x31.png 12 /de/firefox/buttons/firefox_80x15.png 6 /pt-PT/firefox/buttons/firefox_80x15.png 5 /de/firefox/buttons/getfirefox_88x31.png 4 /el/firefox/buttons/getfirefox_88x31.png 4 /es-ES/firefox/buttons/header.png 2 /fr/firefox/buttons/ 2 /fr/firefox/buttons/getfirefox_large2.png 2 /hu/firefox/buttons/firefox_80x15.png 2 /th/firefox/buttons/takebacktheweb_small.png 2 /de/firefox/buttons/getfirefox_large2.png 1 /en-US/firefox/buttons/getfirefox_large.png 1 /en-US/firefox/buttons/getfirefox_large2.png 1 /en-US/firefox/buttons/getfirefox_large3.png 1 /es-ES/firefox/buttons/getfirefox_88x31.png 1 /hu/firefox/buttons/getfirefox_88x31.png 1 /ru/firefox/buttons/getfirefox_88x31.png 1 Most people who have Firefox download banners have switched over to using https://affiliates.mozilla.org/. While a broken image is not ideal, we would have to look at logs to find out if many server requests are being made. These old buttons weren't deleted to save space. They were on an old SVN repo that used the legacy php system and it made it difficult to convert over to the new python/django based system when maintaining two application frameworks and multiple code repositories. Jgmize: Do you have access to the log files to see how many URLs are being requested that have "/firefox/buttons/" in them?
:cmore yes, I have access and without diving too deep I did some quick grepping and it looks like we're getting a *lot* more than I expected. Part of this is because each request to the unlocalized path generates a 301 to the localized path, so I'm doing a quick filter for just the 404s, and I decided to look at just one day's worth of data in the interest of time: [firstname.lastname@example.org ~]$ zgrep /firefox/buttons/ /mnt/stats_metrics-logger1/stats/logs/zlb1.ops.scl3.mozilla.com/www.mozilla.org.access_2014-09-15*.gz | grep -c '" 404 ' 97218 [email@example.com ~]$ zgrep /firefox/buttons/ /mnt/stats_metrics-logger1/stats/logs/zlb12.ops.phx1.mozilla.com /www.mozilla.org.access_2014-09-15*.gz | grep -c '" 404 ' 88132 So on 9/15 we got over 185,000 404s containing "/firefox/buttons/" between the two datacenters. I can do further analysis with a larger dataset, but these preliminary results suggest that we will probably want to prioritize getting these button images working again sooner rather than later.
Interesting, Josh! Thanks for the insight. Now the tricky part comes to decide what to do about those legacy buttons. I wonder if we were to 301 redirect all buttons to a button on affiliates.mozilla.org, if that would work suffice? https://affiliates.mozilla.org/media/uploads/image_banners/b5193a506ded57870dea0b44b45e3092fab1b916.png The only problem with a 301 is that it requires another HTTP request and then we are relying on affiliates. It may be easier to pick the top 80% of URLs being hit in /firefox/buttons/ and create images for those banners with updated branded and place them at those URLs on mozilla.org. Josh: Can you provide the list of exact URLs with the count grouped by file named sorted in descending order?
> Josh: Can you provide the list of exact URLs with the count grouped by file > named sorted in descending order? :cmore I've attached the full files, and here is a gist of how I got them: https://gist.github.com/jgmize/a14140c203f4580724eb These numbers are more in line with what I was expecting than what my quick grepping in comment #6 seemed to indicate, but are still pretty significant, I'd say: $ head 2014_button_404s.tsv aug_button_404s.tsv sept_button_404s.tsv | column -t ==> 2014_button_404s.tsv <== /fr/firefox/buttons/firefox_80x15.png 75749 /ko/firefox/buttons/getfirefox_small.png 11820 /en-US/firefox/buttons/firefox_80x15.png 8049 /fr/firefox/buttons/getfirefox_88x31.png 3366 /en-US/firefox/buttons/getfirefox_88x31.png 2568 /tr/firefox/buttons/firefox_80x15.png 2279 /it/firefox/buttons/firefox_80x15.png 1855 /en-US/firefox/buttons/getfirefox_small.png 1243 /de/firefox/buttons/firefox_80x15.png 1203 /en-US/firefox/buttons/getfirefox_large2.png 818 ==> aug_button_404s.tsv <== /fr/firefox/buttons/firefox_80x15.png 8932 /ko/firefox/buttons/getfirefox_small.png 1344 /en-US/firefox/buttons/firefox_80x15.png 934 /fr/firefox/buttons/getfirefox_88x31.png 499 /en-US/firefox/buttons/getfirefox_88x31.png 298 /tr/firefox/buttons/firefox_80x15.png 296 /it/firefox/buttons/firefox_80x15.png 196 /en-US/firefox/buttons/getfirefox_small.png 151 /de/firefox/buttons/firefox_80x15.png 130 /en-US/firefox/buttons/getfirefox_large2.png 91 ==> sept_button_404s.tsv <== /fr/firefox/buttons/firefox_80x15.png 66817 /ko/firefox/buttons/getfirefox_small.png 10476 /en-US/firefox/buttons/firefox_80x15.png 7115 /fr/firefox/buttons/getfirefox_88x31.png 2867 /en-US/firefox/buttons/getfirefox_88x31.png 2270 /tr/firefox/buttons/firefox_80x15.png 1983 /it/firefox/buttons/firefox_80x15.png 1659 /en-US/firefox/buttons/getfirefox_small.png 1092 /de/firefox/buttons/firefox_80x15.png 1073 /en-US/firefox/buttons/getfirefox_large2.png 727
I'd like to give a huge thanks to :tmary, he helped me out a lot with figuring out how to analyze our log files with hadoop, and the gist I mentioned in comment #11 was created based on an example he gave me.
Created attachment 8495303 [details] aug_button_404s.tsv
Created attachment 8495304 [details] sept_button_404s.tsv
I accidentally left in a filter from :tmary's example (which he helpfully pointed out this morning), so the analysis in comment #11 only had a sample of the data. I've rerun it with the full dataset for August and September and updated their attachments for this bug (2014 is just the sum of the data from those 2 months since the problem started in late August). I've also updated the gist. The results are now in alignment with what I was seeing in comment #6: $ head aug_button_404s.tsv sept_button_404s.tsv | column -t ==> aug_button_404s.tsv <== /fr/firefox/buttons/firefox_80x15.png 3740441 /ko/firefox/buttons/getfirefox_small.png 613009 /en-US/firefox/buttons/firefox_80x15.png 408765 /fr/firefox/buttons/getfirefox_88x31.png 211920 /tr/firefox/buttons/firefox_80x15.png 115892 /en-US/firefox/buttons/getfirefox_88x31.png 115465 /it/firefox/buttons/firefox_80x15.png 78040 /de/firefox/buttons/firefox_80x15.png 63393 /en-US/firefox/buttons/getfirefox_small.png 59424 /en-US/firefox/buttons/getfirefox_large2.png 39688 ==> sept_button_404s.tsv <== /fr/firefox/buttons/firefox_80x15.png 2942353 /ko/firefox/buttons/getfirefox_small.png 461530 /en-US/firefox/buttons/firefox_80x15.png 307212 /fr/firefox/buttons/getfirefox_88x31.png 121560 /en-US/firefox/buttons/getfirefox_88x31.png 99688 /tr/firefox/buttons/firefox_80x15.png 82360 /it/firefox/buttons/firefox_80x15.png 75923 /de/firefox/buttons/firefox_80x15.png 49338 /en-US/firefox/buttons/getfirefox_small.png 47482 /de/firefox/buttons/getfirefox_small.png 32462
Ok, great. It looks like there are only a few size buttons and languages to deal with. I wonder if we could get away with the 100x72 banners on affiliates? https://affiliates.mozilla.org/media/uploads/image_banners/b5193a506ded57870dea0b44b45e3092fab1b916.png We also have this legacy 110x32 banner: https://affiliates.mozilla.org/media/uploads/banners/5d3a43832c5233ce27da7b53e00b2ad1c6ccd87b.png It looks like the locales are: * fr * ko * en-US * tr * it * de I don't know if that download button is localized in the locales above.
(In reply to Chris More [:cmore] from comment #16) > Ok, great. It looks like there are only a few size buttons and languages to > deal with. :cmore just to make sure we're on the same page, I'd like to point out that I only pasted the top URLs into my comments, the full list of 404s for August and September are attachments-- there are over 400 localized button URLs getting traffic, only a handful of which look like legitimate 404s. The majority of the traffic is of course concentrated on a subset of those, but we may want to broaden our scope of what buttons to restore beyond the top 10 urls for each month I showed in the output of my "head" command in comment #15 > I don't know if that download button is localized in the locales above. I don't either, but I do know that in an old svn checkout of the mozilla.com repo on my laptop, I wasn't able to find any localized buttons, but I did find en-US versions of the buttons: jgmize@x1c:~/mozilla.com/en-US/firefox/buttons$ ls -l total 64 -rw-rw-r-- 1 jgmize jgmize 1063 Aug 8 2013 firefox_80x15.png -rw-rw-r-- 1 jgmize jgmize 1027 Aug 8 2013 firefox_pixel.png -rw-rw-r-- 1 jgmize jgmize 3691 Aug 8 2013 getfirefox_88x31.png -rw-rw-r-- 1 jgmize jgmize 3919 Aug 8 2013 getfirefox_large2.png -rw-rw-r-- 1 jgmize jgmize 4500 Aug 8 2013 getfirefox_large3.png -rw-rw-r-- 1 jgmize jgmize 3958 Aug 8 2013 getfirefox_large.png -rw-rw-r-- 1 jgmize jgmize 2396 Aug 8 2013 getfirefox_small.png -rw-rw-r-- 1 jgmize jgmize 18842 Aug 8 2013 header.png -rw-rw-r-- 1 jgmize jgmize 4271 Aug 8 2013 takebacktheweb_large.png -rw-rw-r-- 1 jgmize jgmize 3309 Aug 8 2013 takebacktheweb_small.png Perhaps we should copy those old buttons into bedrock and configure apache to serve them up for any locale?
> :cmore just to make sure we're on the same page, I'd like to point out that > I only pasted the top URLs into my comments, the full list of 404s for > August and September are attachments-- there are over 400 localized button > URLs getting traffic, only a handful of which look like legitimate 404s. The > majority of the traffic is of course concentrated on a subset of those, but > we may want to broaden our scope of what buttons to restore beyond the top > 10 urls for each month I showed in the output of my "head" command in > comment #15 Yes, I knew that was just the top URLs and that there was a long-tail of URLs. The only concern is that we could spend valuable time handling all of those URLs, or we just focus on where 80% the requests are coming from. I'm sure the 80/20 rule is in here somewhere. i.e 80% of the requests are coming from 20% of the URLs. :) I would probably focus on finding a good solution for the top URLs and then "good enough" for the rest of the URLs that don't contribute a ton of traffic. > Perhaps we should copy those old buttons into bedrock and configure apache > to serve them up for any locale? Actually, maybe that will be good enough to just serve up the en-US buttons for all locales. It is not 100% ideal given that French is #1 and en-US is #3 on the top 10. I just realized that these buttons were deleted in bug https://bugzilla.mozilla.org/show_bug.cgi?id=946993#c4 opps! I guess we all assumed that they weren't getting many requests.
Isn't the point with such banners that they can be managed by you guys, and all those sites who embed these images would always have a fresh set of buttons on their site?
(In reply to Rene from comment #19) > Isn't the point with such banners that they can be managed by you guys, and > all those sites who embed these images would always have a fresh set of > buttons on their site? These legacy and unsupported buttons were before affiliates.mozilla.org existed and we don't have a team outside of affiliates to manage such buttons. Also, affiliates.mozilla.org currently is on maintenance mode as it is not priority for Mozilla. We are just trying to find a low technical investment to restoring these buttons that don't consume a lot of bandwidth. We have higher impact development tasks that we need to focus on now.
Unfortunately it gives a pretty unorganized picture when at some point Mozilla urges people to use buttons, and then abandons them more or less completely in a relatively short time.