Redirect the Download pages to Installation

Review links:

http://1449-redirect-the-download-pages-to-installation.about.gitlab.com/downloads

http://1449-redirect-the-download-pages-to-installation.about.gitlab.com/downloads-ee

Closes #1449 (closed)

added 1 commit

• 16583cc1 - Set pages to redirect

Compare with previous version

unmarked as a Work In Progress

changed title from WIP: Resolve "Redirect the Download pages to Installation" to Redirect the Download pages to Installation

changed the description

We may want to wait until #1448 (closed) is fixed, as right now there is no other way to get EE install instructions than /downloads-ee.

@iamphill can you review this quick? Not sure if there is a better way to redirect.

We may want to wait until #1448 (closed) is fixed, as right now there is no other way to get EE install instructions than /downloads-ee.

Fixed by https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/6360

---

@joshlambert if we redirect, then there's no way to display the CE downloads since /installation will always display EE packages. Unless we do some JS magic that toggles CE and EE, I say we don't kill the downloads pages yet.

If we do redirects should it be done at the server level & create a 301 instead?

Yes, we can also do it in nginx.

NGINX would certainly be cleaner, if we can do that with the deployment system we have that would be great.

@axil @iamphill redirecting these to /installation was a request from @sytses. My personal preference would be to have some JS magic to re-write the instructions for CE rather than continuing to direct over to the /downloads pages. The CE link can then change to EE, so they can switch back if they want.

My personal preference would be to have some JS magic to re-write the instructions for CE rather than continuing to direct over to the /downloads pages. The CE link can then change to EE, so they can switch back if they want.

👍

If we redirect both pages to /installation, the CE info will be lost the way it's implemented now.

@joshlambert I think to get the redirects done with nginx we need to go through the production team.

I can have a look at getting them to toggle between CE & EE instructions if that is what we want?

@iamphill if you get the installation page to work by toggling between CE/EE that would be great!

For the Nginx redirects we can submit an MR for https://gitlab.com/gitlab-cookbooks/cookbook-about-gitlab-com/blob/master/templates/default/nginx.erb. That's not a big deal :)

@iamphill That sounds good, I think that would be a good way to approach it. It's just a few letters different as well, so hopefully won't be too hard. 😉

Okay so we have the toggle for CE/EE, which is awesome. I unfortunately don't seem to have access to the about-gitlab-com cookbook, for some reason.

@axil or @iamphill would you be able to edit the nginx config? That would be a better redirect than this, as it won't try to load the page first.

Thanks!

@joshlambert the redirect MR is in https://gitlab.com/gitlab-cookbooks/cookbook-about-gitlab-com/merge_requests/21. Let's wait until it's merged and deployed and then we can remove the pages.

Thanks @axil. Any idea when it will be merged? Or can you grant me access to that repo to see?

@joshlambert the redirects are in place! Can you amend this MR to remove the downloads pages altogether?

Or can you grant me access to that repo to see?

I don't have that permission :) Can you ask in #production?

added 1 commit

• 924d2b79 - Remove unnecessary download pages since redirects now handled at NGINX level.

Compare with previous version

added 1 commit

• aaa4aafa - Remove GPG keys, as they are also redirected.

Compare with previous version

@axil awesome! I have updated the MR to simply remove the existing directories. It looks like there were some GPG keys that were also in those directories, but access attempts to them were also being redirected so I removed those as well. (Since they are essentially unreachable already)

Also did a search for "*.asc" within www-gitlab-com and didn't come up with anything. So not sure what would use them.

@axil can you re-review with the removed directories? Thanks for your help!

assigned to @axil

@joshlambert Crap, I forgot we had the archives dir under downloads/ :/ This is useful for users will old installations, long before we created the repos. The Nginx redirect also redirects this, and we're probably screwed since it's now a 301 and we never expire it (add_header Cache-Control "public, max-age=0, must-revalidate";)...

Not sure of its usage though. Let me ping some people.

• @mitchellwright can you check what GA is telling us about /downloads/archives/ usage?
• @lbot do you have any data if and how many customers update from very old installations (<7.x), and if the archives downloads page is used by the support team?

It looks like there were some GPG keys that were also in those directories, but access attempts to them were also being redirected so I removed those as well. (Since they are essentially unreachable already)

I don't know about the GPG keys, @marin do you know anything about them?

Also, @mitchellwright with this change we remove some marketo stuff which are not in the new /installation page. Should we move them over there or is it ok to purge them?

There are about 760 users that visit about.gitlab.com/downloads/archives/ on a monthly basis.

I think you removed a newsletter sign up form that was on the page. In the last 30 days that was responsible for 205 newsletter subscriptions. It seems like a fairly decent way to get people to sign up. Not sure if you can put that anywhere else on the page, but it's hard to say how effective it would be as the design/layout is completely different.

Should we revert the NGINX redirect and just switch over to the JS based redirect for now, until we figure out where to put these other assets like the archive?

I wouldn't do that on account of the Marketo form. Not sure about the archives page though. Seems like people went there, but whether it was because they wanted/needed an old version is hard to say.

@axil let's just revert the NGINX change and go with the JS based redirect for now. This way if folks are utilizing the Archives page or GPG key they will be unaffected, and we can figure out a plan forward on those with less urgency.

@joshlambert submitted an MR to revert those changes in https://gitlab.com/gitlab-cookbooks/cookbook-about-gitlab-com/merge_requests/24

I don't know about the GPG keys, @marin do you know anything about them?

I have no clue Axil, that page was not touched for a long time. One important thing to note is that we will be considering removing older packages anyway, but this is a different story.

@joshlambert Nginx rules are reverted. You can also revert this MR to 16583cc1.

We also have this issue to take in mind https://gitlab.com/gitlab-com/www-gitlab-com/issues/1469.

assigned to @joshlambert

mentioned in issue marketing#1169 (closed)

I was catching up with @mitchellwright and @jjcordz over slack. There are some concerns that this redirect will impair the EE trial experience.

Some users that arrive at the Download page are expecting information on how to get up and running on an EE trial. The https://about.gitlab.com/installation/ page defaults to CE instructions, and the link to change to EE instructions is easily missed by users due to its size and position at the bottom of the instructions sections.

I'm new, so not sure the best way to address... would it make sense to have a UX team member weigh in on how to ensure each distinct audience is served well by this page?

@courtlandia there is an existing discussion over on https://gitlab.com/gitlab-com/marketing/issues/1169 about the best way to resolve this issue. Probably better to keep that going for continuity.

I agree we need to hold this MR until we sort out the free trial workflow.

👍 🙇

added 2 commits

• 3a022e8e - Revert "Remove GPG keys, as they are also redirected."
• 706cadfc - Revert "Remove unnecessary download pages since redirects now handled at NGINX level."

Compare with previous version

assigned to @axil

@axil can you review? This puts in place the JS redirect, and leaves alone the GPG keys and old build archive.

Thanks, I pushed a small fix to make the URLs relative.

enabled an automatic merge when the pipeline for 706cadfc succeeds

canceled the automatic merge

added 1 commit

• e6bcf023 - Use relative URLs

Compare with previous version

enabled an automatic merge when the pipeline for e6bcf023 succeeds

merged

mentioned in commit ae7f4a9b