set website default version to current stable (1.6) version

[ys2843]

Description

#18429 , To set website default version to v1.6 when users land on main page from other domain.

1. If coming from other domains except mxnet.apache.org or mxnet.incubator.apache.org, redirect users to v1.6 website
2. If coming from other pages on MXNet domain, don't redirect to avoid any looping.

Here is the explanation of this PR changes:

# Apply redirect on master website
RewriteCond %{REQUEST_URI} !^/versions/ 

# Apply redirect only when user visiting from outside of MXNet website
RewriteCond %{HTTP_REFERER} !mxnet.apache.org
RewriteCond %{HTTP_REFERER} !mxnet.incubator.apache.org

# Redirect to corresponding page on v1.6 website
RewriteRule ^(.*)$ /versions/1.6/$1 [r=307,L]

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
• Changes are complete (i.e. I finished coding on this PR)
• All changes have test coverage:

Changes

• Redirect user to v1.6 website when visiting from outside of MXNet website

Comments

• Preview: https://mxnet-beta.staged.apache.org/

[mxnet-bot]

Hey @ys2843 , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

• To trigger all jobs: @mxnet-bot run ci [all]
• To trigger specific jobs: @mxnet-bot run ci [job1, job2]

---

CI supported jobs: [edge, miscellaneous, unix-cpu, unix-gpu, windows-cpu, sanity, centos-cpu, website, windows-gpu, centos-gpu, clang]

---

Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

[ys2843]

@mxnet-label-bot add [Website]

[leezu]

If /versions/1.6/get_started becomes the default, we need to backport the license fixes to that page. Is it possible? Or do we require using the 1.x branch given this constraint?

[connorgoggins]

Instead of just testing redirects on the contribute page in the preview, shouldn't we be testing redirects across all pages?

[ys2843]

If /versions/1.6/get_started becomes the default, we need to backport the license fixes to that page. Is it possible? Or do we require using the 1.x branch given this constraint?

Yes, my plan is to copy the get_started.html directly from master branch to v1.6 static artifact (maybe need some change in the header)

[ys2843]

Instead of just testing redirects on the contribute page in the preview, shouldn't we be testing redirects across all pages?

This PR is to ensure the redirect based on HTTP referer header works as expected in Apache Infra's server. Contribution page is just a random page for testing purpose, we will replace the lines with regex that applies to all pages.

[aaronmarkham]

Not sure, but this didn't work: http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/community/contribute.html
Shouldn't the dropdown read 1.6 if the redirect worked?

You can use the beta site for testing redirects. It's perfect for this kind of testing.
https://github.com/apache/incubator-mxnet-site/tree/beta-site

[leezu]

Yes, my plan is to copy the get_started.html directly from master branch to v1.6 static artifact (maybe need some change in the header)

Thank you. Do you mean only get_started.html or all pages under the get_started hierarchy?

[ys2843]

Not sure, but this didn't work: http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/community/contribute.html
Shouldn't the dropdown read 1.6 if the redirect worked?

You can use the beta site for testing redirects. It's perfect for this kind of testing.
https://github.com/apache/incubator-mxnet-site/tree/beta-site

I will add more clarification about this PR. The redirect test in this PR is described below
Start: http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/versions/1.1.0/community/contribute.html
To: http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/versions/1.6/community/contribute.html

The redirect only takes effect when user visit /versions/1.1.0/community/contribute.html from outside of mxnet website. It could be from a google search result, or type this url into the browser directly. We get this info by checking whether HTTP request header referer is "apache.mxnet.org" or not. This is the behavior that I would like to verify on mxnet website server, it works well on preview host.
And to prevent redirect looping, if user goes to /versions/1.1.0 => top nav bar => community => contribute, this also goes to contribution page but redirect won't be triggered because user is coming from mxnet website.

It looks like this beta git repo is too large to clone...

[ys2843]

Yes, my plan is to copy the get_started.html directly from master branch to v1.6 static artifact (maybe need some change in the header)

Thank you. Do you mean only get_started.html or all pages under the get_started hierarchy?

Should be all folder

[ys2843]

Will test this redirect on beta-stage site, apache/mxnet-site#64

[szha]

while this change looks good, I think we definitely shouldn't make .htaccess a requirement for hosting as it precludes simple static hosting on file systems. This has been preventing a preview for website from being available in PRs and has caused many issues.

I think removing website preview in PRs for using .htaccess was a wrong decision, and if the preview can't be re-enabled, we should deprecate the usage of .htaccess.

[ys2843]

while this change looks good, I think we definitely shouldn't make .htaccess a requirement for hosting as it precludes simple static hosting on file systems. This has been preventing a preview for website from being available in PRs and has caused many issues.

I think removing website preview in PRs for using .htaccess was a wrong decision, and if the preview can't be re-enabled, we should deprecate the usage of .htaccess.

Thanks for reviewing. Since there are many content missing issues recently on master website reported from our customers.
@sandeep-krishnamurthy We decided to submit a fix ASAP without making large changes to website file structure and build process.

It would be good to reduce the usage of .htaccess to enable PR preview, but this need to start from fixing existing broken links since v1.6, which will take much longer time. Currently we think it is more critical to address customer complains in a short amount of time.

[szha]

@ys2843 agreed. it would be great to see a proposal on how .htaccess usage limitation can happen. I'm merging this change now

[sandeep-krishnamurthy]

@ys2843 - Can you please document the steps to update whenever there is new release in MXNet release process document?

[ys2843]

@ys2843 - Can you please document the steps to update whenever there is new release in MXNet release process document?

Sure, will do. I will add documents to apache wiki and internal quip.