Redirecting entire mobile site to desktop site (multi-page) test
I'm trying to run a test in which all the mobile phone visitors who would normally see pages from a 'mobile' version of the site would see the 'big screen' version of the site instead. We have a feeling that the mobile site is actually worse than the main site, even for mobile users.
My test idea is that
(also any https in the live version)
would be redirected to
(also any https in the live version)
The redirect would remove the /mobile/ directory at the start of the path.
The solution I have found in the support site which most closely seems to match this is in
Using Parts of the Existing URL
the code example is
/* _optimizely_redirect=http://custom */ window.current_url = window.location.href.split('/'); window.relevant_url_part = window.current_url; window.new_url = "http://www.mydomain.com/" + window.relevant_url_part + "/test.html"; window.location = window.new_url;
and the code I am using is
/* _optimizely_redirect=http://custom */
window.current_url = window.location.href.split('/');
window.relevant_url_part = window.current_url;
window.new_url = "http://www.mydomain.com/" + window.relevant_url_part;
window.location = window.new_url;
with the correct domain of course.
When I try using the Cross Browser testing process as part of the preview I seem some worrying results.
Most of the desktop browsers behave as intended, although Windows Vista with IE & does not. It displays the original version.
The iPhone 4s/ 5 with Mobile Safari 5.1 also displays the original
and so does Android 4 Simulator with Android Browser 4.
So it seems that this code does not work with the two main mobile browsers. This doesn't entirely surprise me since it relies on them behaving as normal with window.location etc and that may well be relying on too much.
Have I got some fixable detail wrong with this code, please?
Or is there a much better / simpler way of doing such a test. I hope so.
Solved! Go to Solution.
You code looks fine.
How does your site determine whether someone is taken to the mobile version of the site? Could your site be redirecting the mobile browsers back to the mobile version of the page?
A slightly more flexible way of creating the new URL would be to use slice to grab the first 3 parts and everything after the 4th (also works in case someone decides to use a slash somewhere in the URL parameters):
var thisURL = window.location.href; var current_url = thisURL.split('/'); var new_url = current_url.slice(0,3).join('/')+ '/' + current_url.slice(4,current_url.length).join('/');
Or, if you are positive that "/mobile/" will never be in your non-mobile site...
var thisURL = window.location.href; var newURL = thisURL.replace('/mobile/','/');
Edit - added a couple of other ways to generate the "non mobile" version of the URL
Thank you very much for the code. It's really helpful learning by example.
And, of course, thank you for asking the obvious question to start!
Of course, you're right. My test was looping back via the normal redirect. How stupid of me.
I can skip the redirect by adding a parameter ?show_desktop=1
But now I need to deal with inbound links which may or may not have other parameters. So my rewrite has to be conditional to use either ? or & for the show_desktop parameter. I have a bad feeling that this test may end up being too fragile for real life with a high risk of 404s
var currentPath = window.location.pathname; var newPath = currentPath.split('/').slice(2,currentPath.split('
var currentQS = window.location.search; var newQS = (currentQS.length>0) ? currentQS + "&show_desktop=1" : "?show_desktop=1";
var newURL = window.location.protocol + "://" + window.location.hostname + "/" + newPath + newQS;
Note: Depending on your settings you may need to either:
1- Exclude redirected-to URLs with "substring match" on "showdesktop=1"
2- Wrap the redirect logic in an "if-then" so that the redirect does not happen
I've been side-tracked on another related issue. It now turns out that the two versions of the site are not identical - not all pages exist in both versions. So I need to deal with that before returning to the mechanics of sending test candidates from one to the other.
I'm going to have to come back to this next week. But I wanted to thank you again now for your help and code examples.