A Couple Force.com Sites URL Tips

I have been working on more and more Force.com sites lately, and every time I work on one, I learn something new.  Here are a couple of tips I’ve picked up to help make the development and release process go a little bit smoother.

If you are new to Force.com sites, you will learn quickly that there are some differences between creating a website in its environment compared to creating one in a different environment. Normally when we are setting up a new site, a server is built, software is added, then the site is created using things like HTML, Javascript, and PHP. A domain is then registered, and pointed to the newly created website. In Force.com sites, the platform is pre-built for you. You create a domain when you are initially setting up the site. The domain will look something like yourdomain.force.com. You will most likely want to have a custom domain set up to point to your new site that does not include the force.com suffix. To do that, register your domain name, then create a CNAME that points your new domain to your Force.com domain. 

When you set up a site in Salesforce, the site is located at the domain name you set up followed by a /sitename. So, as an example, if you set up a domain of “yourdomain.force.com” in your Salesforce organization, and you then create a Force.com site called “mysite,” your URL to access the homepage of your new site would be “http://yourdomain.force.com/mysite.” If you want to use a URL of “www.mywebsite.com” for your end users to access your new site, you would create a CNAME record to point “www.mywebsite.com” to “yourdomain.force.com.” Then you would add “www.mywebsite.com” to your new site record in Salesforce in the Custom Web Address field. Now, when someone goes to your site at “http://www.mywebsite.com,” they will see the home page for your new website.

This is where some issues may arise. Since you cannot test custom domains in sandbox or developer organizations, you don’t know for sure if all of your links and pages will work correctly with the new custom domain. You don’t find out until you make the site live in production with the new domain if your links, and various other components are broken.

Let’s say for example that you create a link on your home page to a page called “MySecondPage.” You could use something like href=”/mysite/MySecondPage” This will work fine in your development and sandbox organizations. It will even work when you go to your production site using the “http://yourdomain.force.com/mysite” URL you set up when creating your site. However, if you try to use your “www.mywebsite.com” domain, this link will not work. It will instead send you to “http://www.mywebsite.com/mysite/MySecondPage,” which is an invalid URL. The URL should read “http://www.mywebsite.com/MySecondPage.” Likewise, if you try to use href=”/MySecondPage” you will be able to access the page at “http://www.mywebsite.com/MySecondPage,” but not at “http://yourdomain.force.com/mysite/MySecondPage,” which makes viewing the page in sandboxes and developer organizations impossible. To get around this, and avoid any surprises when you go live with your new site, always try to use the “Page.PageName” functions available in Visualforce and Apex Classes. For example, the previous link would look like href=”{!$Page.MySecondPage}” Using this type of link would ensure it will work with all domains. 

You should also use this same convention in your Apex Controllers when using PageReference methods. For example, instead of using myPage = new PageReference(’/mysite/MySecondPage’); use myPage = Page.MySecondPage;

One more thing to keep in mind when creating these sites is if you are using SSL, you will have to use the force.com domain because the custom domain you registered will not work. The reason for that is the SSL certificates cannot work with domains outside of Salesforce’s organization, so CNAME domains would display an error to the end user. This is common when you have a public site that has a section that requires authentication. The custom domain you registered works fine until the user logs in. After they log in, they are taken to a secure version of the site using the organization’s force.com domain. Currently, there is no way around this when using SSL on Force.com sites.