Lucene - Core
  1. Lucene - Core
  2. LUCENE-3978

redo how our download redirect pages work

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.9, 5.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      the download "latest" redirect pages are kind of a pain to change when we release a new version...

      http://lucene.apache.org/core/mirrors-core-latest-redir.html
      http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

        Activity

        Hoss Man created issue -
        Hide
        Hoss Man added a comment - - edited

        when we released 3.6, we ran into a few annoyances...

        • these pages require that you edit the template (not availbale in the bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL
        • these pages were in browser caches, so they weren't seeing the cahnges in the javascript redirect (rmuir added some no-cache metadata headers, so hopefully this won't be a problem again)

        My suggestion for the future...

        • eliminate these templates and their mdtext pages entirely
        • replace them with a .htaccess redirect rule that looks like:
          /([^/*)/mirrors-(.*)-latest-redir.html /$1/mirrors-$2-redir.html?3.6.0
          
        • update the templates for mirrors-solr-redir.mdtext and mirrors-core-redir.mdtext so that the javascript will use the query string when building the final URL

        ...that way whenever we release a new version, we can just tweak the .htaccess rule, and the only "html pages" that might ever show up in an http or browser caches will have unique URLs per version.

        (EDIT: 1. fix fucking code markup, 2. didn't mean for redir rule to include "latest" ... sigh: 3. only ment to remove latest from the redir dest)

        Show
        Hoss Man added a comment - - edited when we released 3.6, we ran into a few annoyances... these pages require that you edit the template (not availbale in the bookmarklet) to change the 3.5.0 to 3.6.0 in the final URL these pages were in browser caches, so they weren't seeing the cahnges in the javascript redirect (rmuir added some no-cache metadata headers, so hopefully this won't be a problem again) My suggestion for the future... eliminate these templates and their mdtext pages entirely replace them with a .htaccess redirect rule that looks like: /([^/*)/mirrors-(.*)-latest-redir.html /$1/mirrors-$2-redir.html?3.6.0 update the templates for mirrors-solr-redir.mdtext and mirrors-core-redir.mdtext so that the javascript will use the query string when building the final URL ...that way whenever we release a new version, we can just tweak the .htaccess rule, and the only "html pages" that might ever show up in an http or browser caches will have unique URLs per version. (EDIT: 1. fix fucking code markup, 2. didn't mean for redir rule to include "latest" ... sigh: 3. only ment to remove latest from the redir dest)
        Hide
        Uwe Schindler added a comment -

        Hi Hoss,
        I have seen your commit and I now understand the reason for the redirect pages (to also count downloads by Google Analytics). As I also did GA tracking for webpages not long ago, there is a better/more correct solution to track downloads. The trick is to add some javascript to the source link that tells Google Analytics to create a "virtual pageview" when clicking on the link. The virtual pageview is counted on a "virtual" URI (e.g., the current URL with the redirect page, without http and hostname): http://support.google.com/googleanalytics/bin/answer.py?hl=en&answer=55529 In fact, the trick is to execute the analytics javascript on the link click and pass a "custom" url instead the default one from the current page.

        Show
        Uwe Schindler added a comment - Hi Hoss, I have seen your commit and I now understand the reason for the redirect pages (to also count downloads by Google Analytics). As I also did GA tracking for webpages not long ago, there is a better/more correct solution to track downloads. The trick is to add some javascript to the source link that tells Google Analytics to create a "virtual pageview" when clicking on the link. The virtual pageview is counted on a "virtual" URI (e.g., the current URL with the redirect page, without http and hostname): http://support.google.com/googleanalytics/bin/answer.py?hl=en&answer=55529 In fact, the trick is to execute the analytics javascript on the link click and pass a "custom" url instead the default one from the current page.
        Hide
        Hoss Man added a comment -

        Uwe: if i'm understanding that page correctly, this would only be possible for links where:
        a) link html is on our site
        b) we can control the html used to generate them
        ...which isfine for the bug buttons on lucene.apache.org, and any other download links we might want to include on those CMS pages, but not for things like links from wiki.apache.org, or the URLs we include in our plain text release announcement emails (that users just cut/paste) or that we submit to any other site to promote the release.

        Show
        Hoss Man added a comment - Uwe: if i'm understanding that page correctly, this would only be possible for links where: a) link html is on our site b) we can control the html used to generate them ...which isfine for the bug buttons on lucene.apache.org, and any other download links we might want to include on those CMS pages, but not for things like links from wiki.apache.org, or the URLs we include in our plain text release announcement emails (that users just cut/paste) or that we submit to any other site to promote the release.
        Hide
        Uwe Schindler added a comment -

        Hoss: That's the problem. For links on external pages to our downloads we cannot track, only with a redirect page. But people adding links to their pages will always link-through, so we cannot enforce that they go through analytics code.

        But analytics should track page usage (means the action "clicking link on our homepage") and not download usage in general (which is diametral somehow). Tracking of downloads is in Apache's responsibility.

        Show
        Uwe Schindler added a comment - Hoss: That's the problem. For links on external pages to our downloads we cannot track, only with a redirect page. But people adding links to their pages will always link-through, so we cannot enforce that they go through analytics code. But analytics should track page usage (means the action "clicking link on our homepage") and not download usage in general (which is diametral somehow). Tracking of downloads is in Apache's responsibility.
        Hide
        Hoss Man added a comment -

        bulk cleanup of 4.0-ALPHA / 4.0 Jira versioning. all bulk edited issues have hoss20120711-bulk-40-change in a comment

        Show
        Hoss Man added a comment - bulk cleanup of 4.0-ALPHA / 4.0 Jira versioning. all bulk edited issues have hoss20120711-bulk-40-change in a comment
        Hoss Man made changes -
        Field Original Value New Value
        Fix Version/s 4.0 [ 12322456 ]
        Fix Version/s 4.0-ALPHA [ 12314025 ]
        Hide
        Robert Muir added a comment -

        rmuir20120906-bulk-40-change

        Show
        Robert Muir added a comment - rmuir20120906-bulk-40-change
        Robert Muir made changes -
        Fix Version/s 4.0 [ 12322550 ]
        Fix Version/s 4.0-BETA [ 12322456 ]
        Robert Muir made changes -
        Fix Version/s 4.1 [ 12321140 ]
        Fix Version/s 4.0 [ 12322550 ]
        Mark Miller made changes -
        Fix Version/s 5.0 [ 12321663 ]
        Mark Miller made changes -
        Fix Version/s 4.2 [ 12323899 ]
        Fix Version/s 4.1 [ 12321140 ]
        Robert Muir made changes -
        Fix Version/s 4.3 [ 12324143 ]
        Fix Version/s 5.0 [ 12321663 ]
        Fix Version/s 4.2 [ 12323899 ]
        Uwe Schindler made changes -
        Fix Version/s 4.4 [ 12324323 ]
        Fix Version/s 4.3 [ 12324143 ]
        Hide
        Steve Rowe added a comment -

        Bulk move 4.4 issues to 4.5 and 5.0

        Show
        Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
        Steve Rowe made changes -
        Fix Version/s 5.0 [ 12321663 ]
        Fix Version/s 4.5 [ 12324742 ]
        Fix Version/s 4.4 [ 12324323 ]
        Adrien Grand made changes -
        Fix Version/s 4.6 [ 12324999 ]
        Fix Version/s 5.0 [ 12321663 ]
        Fix Version/s 4.5 [ 12324742 ]
        Simon Willnauer made changes -
        Fix Version/s 4.7 [ 12325572 ]
        Fix Version/s 4.6 [ 12324999 ]
        David Smiley made changes -
        Fix Version/s 4.8 [ 12326269 ]
        Fix Version/s 4.7 [ 12325572 ]
        Hide
        Uwe Schindler added a comment -

        Move issue to Lucene 4.9.

        Show
        Uwe Schindler added a comment - Move issue to Lucene 4.9.
        Uwe Schindler made changes -
        Fix Version/s 4.9 [ 12326730 ]
        Fix Version/s 5.0 [ 12321663 ]
        Fix Version/s 4.8 [ 12326269 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Hoss Man
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development