Apex Code Development You need to sign in to do that
Don't have an account?
paul-lmi can we get more explanation on redirects feature in Winter '11
Is this just "page x" to "page y" or are we going to have full control over this, including support for URL params? We're planning to migrate our existing knowledgebase implementation over to sf knowledge, and a proper on-platform redirect implementatio nwould dramatically simplify the cleanup and allow us to decommission the servers running the current KB a lot sooner.
Here's what I'd envision
1. Set up Force.com Site 1 for public KB
2. Set up Force.com Site 2 to act as the redirector
3. Add redirect rules to push requests for URLs on Site 2 to redirect to URLs on Site 1
4. Have cake
This would hinge on getting more detail on this feature (release notes and feature preview page are a bit dodgey on actual implementation), and whether this does properly support using URL params (docid in site 2 to id in site 1, etc).
i actually like that gotcha. it forces us to centralize things that should be centrally configured, like we already do with robots and favicon.
All Answers
Right now it is an exact source-to-target match. So:
When a request comes in, we check if you have a site with a redirect rule that matches the request. For example:
http://mysite/myprefix/somepage?lang=fr
We will look for a rule with a source of '/myprefix/somepage?lang=fr'. If we find a rule, we will reply with a 301/302 code with your specified target as the new page to go to.
For various arcane reasons we don't support anchors in source urls, but that's about it. There's no automatic 'change all params called id to sourceid' facility, however.
does it work with sites that use custom web address?
example, what i'd be planning is to create my list of redirects, then change the DNS to redirect my current site over to the force.com site, and have it gracefully take over the traffic, in this case, redirecting to the other force.com site.
we'd have to hand craft each one, so the ID mapping isn't an issue, but handling the redirect of non-platform-style URL's to platform-style URLs, cross-site, would be needed. if that's covered, I think we're good with everything but the lack of native custom web address support on SSL, which is a different boat altogether.
This should work fine with sites that have custom web addresses. All the source urls must be relative, so it doesn't matter if you get here via foo.force.com or myowndomain.com.
One gotcha that you might run into if you have multiple sites is that if you have a root site (without any prefix), it will 'claim' all redirects that don't have a prefix. So:
site 1, no prefix.
site 2, prefix of /a/ .
If you wanted to make a rule that said 'redirect from /page.html to /a/newpage.html' it _must_ be placed in site 1's list of rules, because the /page.html url looks like it belongs to site 1.
i actually like that gotcha. it forces us to centralize things that should be centrally configured, like we already do with robots and favicon.