One of the great things about the Premium Membership that we offer is a service called “Assisted Deployment” in which we will, should you run into difficulty deploying your locally created site, help to get your site online. In many cases, we’ve found that our customers would like us to do it to a temporary site so that they can do a live demonstration for their clients. While this was never the intent of offering our service (we prefer to do permanent deployments), we certainly understand where you’re coming from when you ask us to do this. And we also realize that, in general, when you ask us to do this for you, it’s because you’ve tried the tools built within DesktopServer such as Direct Deploy or Quick Deploy, researched or watched our YouTube videos for guidance and have run into issues and out of ideas. To add insult to injury, it’s almost always the case that deployment becomes a matter of time being of the greatest essence.
With all of the above said, I thought I’d talk a little bit about one of the biggest issues that we run into when our customer gets to the point where they are in need of an assisted deploy. That is the subject of subdomain vs subfolder and the confusion that the two terms might bring to those who might not be fairly well seasoned when it comes to setting up a live site.
In short, the difference is pretty simple, but the impact it has upon deploying from DesktopServer can be the difference between a quick deploy and a manual deploy, meaning it costs more time.
A subdomain, essentially, is an actual DNS entry – meaning the whole Internet will see it as a named address. The name of the “sub” part goes at the beginning/before the domain. So, if you own xyz.com as a domain, and you wanted your WordPress site to reside in a directory called “staging,” the subdomain format would be staging.xyz.com.
A subdirectory, on the other hand, is NOT a DNS entry and the “sub” part falls at the end/after the domain. So, using the same example of xyz.com, your deployment destination would look like this: xyz.com/staging.
Why does it matter?
When it comes to how DesktopServer likes to do deployments, it matters a lot. This is because DesktopServer only recognizes a fully qualified domain / URL (in other words, something that DNS recognizes; see the subdomain explanation). A subdirectory is not a fully qualified domain / URL but, rather a directory underneath a fully qualified domain.
Which should you choose?
Obviously, based on this information, the best practice for deployment is to create a subdomain. The problem that many run into is that creating a subdirectory is easy and consistent along all platforms. If you have any sort of FTP or File Manager access, all you have to do is add a directory underneath the root of your domain directory installation and it’s instantly available. However, creating a subdomain is not necessarily so immediately obvious, and at times, the addition of your subdomain may not be immediately available due to potential DNS or Server-side propagation issues.
Most (if not all) hosts will allow for you to create a subdomain, but it involves you going into THEIR Control Panel to do it and sometimes it takes a bit of poking around to find the place in which it’s done. On most CPanel interfaces, you’ll find it in the “Domains” Section as seen here:
On most hosts, you’ll find a section similar and in almost every case it will be in the “Domains” Section. Once you get there, all you need to do is give a name to your subdomain and if you host several domains (top level domains like xyz.com), you’ll select the domain to which you wish to attach the subdomain.
Once you’ve created the subdomain, deployment can become much simpler because you can use the native deployment functionality within DesktopServer to handle most deployments.
While you can deploy your site to either a subdomain or a subdirectory, it makes far more sense to deploy to a subdomain for no other reason than it can be a real time saver and save a lot of frustration for all involved.