“What’s in a name? That which we call a rose
By any other name would smell as sweet.”
Act 2 Scene 2, Romeo and Juliet, Shakespeare

It's a common point of confusion for people to ask what the difference is between their live site and their *.sf.ucdavis.edu site. Or to ask how to get rid of their *.sf.ucdavis.edu since they have their live one now. Or, why does Acquia call your site something different entirely? This post is all about understanding that, in the end, your site is your site no matter its name, just like Shakespeare intended.

Identity Crisis: An Origin Story

When SiteFarm signed on with Acquia Cloud Site Factory for hosting services, it was determined based on our client information, that sites created on Site Factory would be given this site URL format:

http://sitename.ucdsitefarm.acsitefactory.com 

Broken down as:

• http:// = Hypertext Transfer Protocol (no encryption or verification) 
• sitename = the administrative name requested by you, our client
• ucdsitefarm = SiteFarm's client name as known to Acquia
• acsitefactory.com = Acquia Cloud Site Factory's domain

The name presented us with a few issues:

1. It's long and hard to remember, especially since it's only intended as an administrative domain URL,
2. Campus Security requires all UC Davis websites to utilize secure encryption via an SSL Certificate, which this didn't have, and
3. Search engines would find it, index the site, and share it with the world almost out of the box.

Our team realized we could address a few issues in one change, and this brings us to our first name update.

A Site in Progress

Let's imagine one of our users created a new site called 'abcsite'. The SiteFarm team performed some backend programming to create a naming format to address the points of concern listed above so as to go from:

http://abcsite.ucdsitefarm.acsitefactory.com

to the now familiar URL format of:

https://abcsite.sf.ucdavis.edu

In addition to providing security encryption with HTTPS and making the URL shorter, we also created a trigger for each site's robots.txt file. If you're not familiar, the robots.txt file provides instructions to search engines for if and how they're allowed to crawl a website. For as long as a site is in its unpublished ".sf" state with no live domain associated with it, the site serves a robots.txt file instructing search engines to leave it unindexed, which means it remains invisible to the internet unless you deliberately share a URL with other people or post it in a place where that URL can be found on a live site where pages do get indexed.

So, to this point, you still have the same site—it's just known by two different names.

It's Alive!

When a department feels their site is ready to be published, this is when one or more "live" domains are associated with their SiteFarm site on our hosting platform, Acquia Cloud Site Factory. One primary domain is absolutely required, but in some instances a department may need vanity domains that point to important or highly trafficked spots deeper in the site, or it may be a legacy domain from a previously existing domain name from which they need to redirect to the new domain name.

The site with its development name:

https://abcsite.sf.ucdavis.edu

gains a new name of:

https://abcsite.ucdavis.edu

So now, technically, you can access this site from any of its three names. But which one should you use? And why?

Cache is King

Once your site is published, always log into the live domain name to work on your site. So, in this site example we would use:

https://abcsite.ucdavis.edu/login

The reason is that a different caching process is used for live sites than for sites in development, and updates you make via your live domain should be visible to your visitors almost instantaneously. Because of the nature of your development site, which is not intended for external use, updates made while logged into *.sf.ucdavis.edu could conceivably take several hours to show up on your live site.