Closed Bug 1048268 Opened 10 years ago Closed 10 years ago

Ship redirect solution for welcome.webmaker.org index

Categories

(Webmaker Graveyard :: Engagement Ladder, defect)

Product:
Webmaker Graveyard
Component:
Engagement Ladder
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: adam, Assigned: akirose)

References

Details

(Whiteboard: [webmakersnippet])

Attachments

(1 file)

https://github.com/mozilla/webmaker-landing-pages/pull/45
57 bytes, text/x-github-pull-request
adam
: review+
Details | Review 
High-traffic webmaker promotions (currently the snippet) link in to https://welcome.webmaker.org/

As we test new landing pages and user journeys for these first-time visitors, we need to be able to move the default flow of traffic into the best performing journey. 

It is not easy to regularly update off-site links (e.g. those used in the snippet) so I think we should continue with our current process of sending the traffic to the index page https://welcome.webmaker.org/ and managing the flow of traffic from there with a redirect.

Right now, I am using optimizely to redirect this traffic but this would be better done on the page (it's not the best use of optimizely credits ;) ).

Alternatively, we could update the build script on webmaker-landing-pages to let use flag which of the page designs gets built as the index. That might be nice.

Aki, what do you think is the best tech solution here? 

Or more precisely, what's the best tech solution for right now :)
Flags: needinfo?(aki)
My guess would be a trivial nodejs redirector who a) loads the distribution of redirect target & percentage allocation from a JSON file, b) and that probably exists already in node land. Adding a few people who might have useful opinions.
(In reply to David Ascher (:davida) from comment #1)
> My guess would be a trivial nodejs redirector who a) loads the distribution
> of redirect target & percentage allocation from a JSON file, b) and that
> probably exists already in node land. Adding a few people who might have
> useful opinions.

The current limitation is that these pages are static HTML hosted on S3, but we might be reaching the point where we should look at changing that (see also: Bug 1047521).

@all CC'd: if you have any preferred nodejs solutions for this, please note them in the bug :)

If we choose to re-tool this into a node app, and change the hosting setup, and this was going to be more than say a week to launch, I think we can still look at a quick fix for the static HTML version.
Band-aid!
Attachment #8467655 - Flags: review?(adam)
Yeah I'm starting to think maybe a basic node express/nunjucks server wouldn’t be a terrible idea. Then we could solve the webmaker-auth problem referenced in Bug #1047521, as well as have a single `routes.js` file to switch when changing up the `index.html` template.

Damn.

p.s. leaving this as NEW because my PR really doesn’t solve the problem of this bug at all, it is, as you would call Adam, a plaster.

p.p.s. we still have to deal with the problem of cache-busting/CDN. Idk if it would be a great idea to totally forgo a CDN with the level of traffic we’re talking about here. (though if we want to that would be awesome because seriously CDNs are the source of so many of my programming problems.)
Flags: needinfo?(aki)
See Also: → 1047502
Comment on attachment 8467655 [details] [review]
https://github.com/mozilla/webmaker-landing-pages/pull/45

Could we get this reviewed and merged so we can save those Optimizely credits?
Flags: needinfo?(adam)
We'll need to keep Optimizely in place as we're now routing the traffic out to wm.o/signup for the next few days, but I'll review this now so we can merge and keep the repo clean :)
Flags: needinfo?(adam)
Commits pushed to master at https://github.com/mozilla/webmaker-landing-pages

https://github.com/mozilla/webmaker-landing-pages/commit/79762d4be908f8e3dc9658c5af21f435c57e3576
Bug 1048268 - Ship redirect solution for welcome.webmaker.org index

https://github.com/mozilla/webmaker-landing-pages/commit/ab6a247e1984f8656eaaff62037b1c356ca00a24
Merge pull request #45 from gesa/1048268/rearrange-index

Bug 1048268 - Ship redirect solution for welcome.webmaker.org index
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [webmakersnippet]
What about adding a header in the S3 console?
http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html

I feel like this image says all that needs to be said: http://docs.aws.amazon.com/AmazonS3/latest/dev/images/website-redirect-metadata.png
Flags: needinfo?(adam)
This might work, but I couldn't quite get it right. I tried these two methods:

== Method 1: setting the meta redirect on the index.html file (as shown in the screenshot)

* This redirects, but loses parameters in the URL (we need these to know where traffic is from)
* Uses a 301 redirect which is problematic for changing this regularly as browsers cache the 301 internally (a 302 would be better here)

== Method 2: using the custom XML configuration as shown here: https://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html

* I can get this to do a 302 redirect with the parameters intact, but... this matches on prefix rather than a full path, so is redirecting all traffic from all sub-pages. Not just the index at the root.

Here's a copy of the XML I was testing.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>webmaker.org</HostName>
      <HttpRedirectCode>302</HttpRedirectCode>
      <ReplaceKeyPrefixWith>signup</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

==

@aki, would you be able to ask your friend if they have another solution that I'm overlooking here?
Flags: needinfo?(adam) → needinfo?(aki)
Leo's advice is to try

  <Condition>
    <KeyPrefixEquals>index.html</KeyPrefixEquals>
  </Condition>
Flags: needinfo?(aki)
(In reply to Aki Rose Braun [:akirose] from comment #11)
> Leo's advice is to try
> 
>   <Condition>
>     <KeyPrefixEquals>index.html</KeyPrefixEquals>
>   </Condition>

That almost did it, but doesn't quite work. 

It now redirects just the index page, but only if 'index.html' is explicitly included in the URL.
From Leo: What if you put a CloudFront distro in front of it? with the default root object of index.html?
Looks like the default root object is already index.html: https://www.dropbox.com/s/ybdc7g5pn793ap2/Screenshot%202014-08-15%2015.22.16.png
JP: I'd love to hear your thoughts on solving this problem on the "server" side as well. We could not, and choose to use client-side javascript instead, but that leaves for potentially a **** experience.
Flags: needinfo?(johns)
Another option here would be to upload an object to S3 with a x-amz-website-redirect-location header attached. I think we could do this on a deploy as well...
I actually really like this as an option jbuck. easy, cheap, can be done on deploy or from the console.
(In reply to Jon Buckley [:jbuck] from comment #16)
> Another option here would be to upload an object to S3 with a
> x-amz-website-redirect-location header attached. I think we could do this on
> a deploy as well...

(In reply to Aki Rose Braun [:akirose] from comment #17)
> I actually really like this as an option jbuck. easy, cheap, can be done on
> deploy or from the console.

I don't really understand what this means, but would like to close up this bug if possible :)

Would this work for a 302 style redirect? (ie temporary), or is it easier to do this client side?
1. Sign in to the aws console and click on S3 http://snaps.akibraun.com/o313y.png
2. Find welcome.webmaker.org. Click on the properties icon, and scroll to "Static Website Hosting" http://snaps.akibraun.com/4dgs6.png
3. Use the documentation found here to add routing rules to the text box https://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html#configure-bucket-as-website-routing-rule-syntax

A good example for the index would be:

  <RoutingRules>
    <RoutingRule>
    <Condition>
      <KeyPrefixEquals>/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyPrefixWith>/start/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>

(note I haven't tested this, it *might* have to be "/start/index.html" instead of "/start/")

We'd have to test whether this returns a 301 or 302 redirect though.
Oh fiddlesticks that code sample isn't right.
jbuck: can travis be configured to deploy headers on specific files on s3? I think no. And I think they'll lose their headers (such as x-amz-website-redirect-location) we set in the console on travis deploy.
Flags: needinfo?(jon)
I don't think travis can be configured to do that sort of thing, we'll need to use an existing tool or roll our own for that.
Flags: needinfo?(jon)
How about we revert to a simple client-side: window.location.replace() in the index.html file?
does that break the back button? Or are modern browsers smarter than that? i like it.
It shouldn't break the back button as far as I know: http://stackoverflow.com/a/506004/1697507
Then I think we have our resolution. window.location.replace() it is!
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(johns)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: