A subdomain is one way of organizing and separating content on your site. You’re already familiar with the concept of subdomains, even if you don’t know it. Consider OU’s public Web site at http://ou.edu.

As you browse parts of that site, you’ll notice that the domain changes. When you’re looking at your department Web site, say the site for the Chemistry & Biochemistry Department at http://chem.ou.edu, the URL is no longer just ou.edu. Now the root of the url is chem.ou.edu, indicating that you’re on the part of the site that is dedicated to the Chemistry & Biochemistry Department.

If you browse to the technology store pages at http://itstore.ou.edu, you’ll notice that the domain changes again, this time indicating that you’re in the technology store of the OU site.

As you can see the domains serve two purposes: they help to organize the site from a technical perspective, but they also serve as indications to the users that they are in a new/different space. As you work on your site, you’re welcome to create as many subdomains as you like, and in each subdomain you can actually create a distinct, individual Web site.

Additionally, we have resources that demonstrate setting up subdomains and illustrate the difference between subdomains and subdirectories.

When you sign up for domains.skidmore.edu, you get space on a Web host that is associated with the project. There are a few things you need to know about the Web host that will make it easier to understand what you can do with your new space.

The Web server is the main computer that is associated with the domains.skidmore.edu hosting account. It’s literally a computer, but it’s a computer that has special software on it that allows it to be accessible via the Web. The files that run your applications, images or video you upload, or any other files you upload into your Web space are stored on this server.

(For comparison’s sake, your desktop or laptop computer, by default, doesn’t allow this; I can’t access files on your computer through a Web browser by default. You CAN actually install Web server software on your own computer, essentially making your files accessible over the Web.)

In order to run, a Web server has an operating system installed and some kind of Web server software. The domains.skidmore.edu server runs the 'LINUX' operating system and an 'APACHE' Web server.

In addition to the Web server, there is also an associated database server. This is another computer, but it is configured with software that allows it to host databases. It is also connected to your Web server so that your applications (hosted on the Web server) can retrieve data (from databases hosted on the database server).

Databases come in LOTS of varieties. The kind of database you can use for a Web application depends on the kind of software that’s installed on the database server. The domains.skidmore.edu server can run 'MYSQL' databases.

When you install open-source software on your Web account, it’s going to be written in some programming language. Your Web server has software installed on it that allows it to understand different languages. If you install software that’s written in a language that your Web server doesn’t read, it won’t work.

The domains.skidmore.edu server has software installed on it that allows it to understand 'PHP', 'PERL', and 'PYTHON'.

If you take a look at all the descriptions above, you can determine that we are running what is known as a LAMP server for create.ou.edu:

• Linux (operating system)
• Apache (Web server)
• MySQL (database server)
• PHP/PERL/PYTHON (programming language)

Applications that are written for LAMP environments will, presumably, run on the server. HOWEVER, some applications do require additional extensions or libraries that aren’t included, by default, in a LAMP environment. The applications you can install via Installatron (in cPanel) should work just fine.

What makes LAMP environments special is that all of the component parts are open-source. Linux, Apache, MySQL, PHP, PERL, and PYTHON are all open-source programs or systems. Anyone can download them (for free) and install them. Anyone can also modify them and redistribute them. As a result, there are lots of online resources for using these systems that have been built by their communities of users. But, also as a result, since you’re not paying for these systems, you can’t just call up a company and ask them to fix a problem.

You may find this video, which explains how the LAMP technology stack works, useful in further understanding LAMP Web environments.

Static Websites

In the early days of the Web, almost all Web sites were what is known as 'static sites.' Content (text, images, video, audio, etc), was placed or embedded in a file in which HTML tags were used to format it. If you looked at the actual contents of the file, you might see something like this:

The content and the tags lived side-by-side. To edit the page, you’d open up the file (on your own computer) in a program capable of editing HTML files and make changes to either the content or the presentation. Every page had to be edited individually, even if the edits you were making were for common elements that appeared on many pages (like menu bars).

From a technical perspective, accessing a static Web site is fairly straightforward. When your computer is connected to the Internet, you can use a Web browser to access files on a Web server (as long as you know the address). The Web server delivers the contents of those files to your browser, and your browser displays them.

Over time, as the Web became more sophisticated, new systems emerged for creating and managing Web sites. These moved beyond the model of having content and HTML tags live in a simple HTML page which your browser accessed and displayed. Instead, these systems were Web applications – software that literally runs on the Web server and makes it possible to manage a Web site, often with very sophisticated features. One feature of these applications is that they separate content and presentation by storing most content (your text, images, etc) and data about the site (the title, options, etc). in a database.

On the Web server, the Web application installs files that are written in some kind of programming language. The server reads this code and obeys any requests in it to access data in the database (which lives on a separate server) and displays it according to the instructions in the code.

Essentially, the data for the site (living in a series of tables in a database on the database server) is entirely separate from the actual presentation of the site (living in the code of the programmed files on the Web server). Special software on both the Web server and the Database server enable the two to speak to each other and work together.

One of the benefits of using a Web application is that you usually don’t need to touch (or even look at!) the code in order to make changes to your content. In addition, editing the site usually involves accessing some kind of control panel through your Web browser and filling out a form, instead of having to download and access files in software on your own computer.

Sometimes when we talk about the difference between dynamic and static content we get bogged down in the idea of whether or not the content is “fresh” (dynamic, regularly updated) or “old” (static, never updated). How frequently you update your content has nothing to do with what kind of system you are using to manage your site. You can manage a static Web site (as described above) and update the content every day. You can also have a dynamic Web site (running something like WordPress) and never change the content after you create it.

Generally speaking, it IS easier to regularly update content on a dynamic Web site because the Web application just makes it easier. Sometimes, even when you just want a very basic page or placeholder, it’s easier to install a Web application (and only put up a single page) then to manually create an HTML page and upload it.

Another aspect of separating content from presentation involves the use of 'Cascading Style Sheets' (CSS). These are special files that live on your Web server and are linked to your Web pages. They contain information (written in a special markup language) about how to make elements on your site look. They allow you, for example, to define in a single location what all Level 1 Headings look like on your site. They are an important aspect of understanding how to separate content from presentation, but they’re not really an aspect of the difference between static and dynamic sites. Both static and dynamic sites can use style sheets.

When you’re first getting started with a new space on a new Web host, you might think of yourself as owning a small “territory” of the Web. Everything you place in your public folder on the server becomes available for anyone on the Web to see (assuming they know the address of your site and the files you’ve placed there).

If you’re just putting up a handful of static, HTML pages which you want to make available to colleagues, friends, or family by sending them links, then working with this large, unorganized space may work. But as soon as you get to the point where you want to organize your site, you’re going to need a new strategy.

Consider this scenario: you want to have a personal blog on your new Web space, where you share pictures and short written pieces with family, friends, and colleagues. In addition, you’re working on a large research project that requires you to build a Web-based repository of digital images related to your discipline. You want to use one application (say, WordPress) to manage your personal blog. For your research project, you’ve settled on another open-source application (Say, Omeka). Both of these are applications that need to be installed on your Web host, but you can’t just put them both at your main domain name – if you did, both sites would quickly experience conflicts and errors. You need to cordon off separate spaces for your different Web “properties.”

There are two primary strategies for parceling up your Web space. You can create subdomains or subdirectories. But before you can understand the difference, you need to first understand what we mean when we talk about your root domain.

Let’s say you’ve registered a new domain for domains.skidmore.edu called yourdomain.com. Anything that is stored at this core URL is considered to be at the root of your domain: Nothing comes before the address or after the address. You can certainly decide that you simply want to have a single site on your Web host (say a blog running WordPress), and you can set that blog up at your domain’s root. To get to your site in this scenario, users would simply go to yourdomain.com.

When you want to do more than just have a single site at the root of your site, you need to decide now to organize your space. One way to do so is by setting up subdomains.

You’re already familiar with the concept of subdomains, even if you don’t know it. Consider OU’s public Web site at http://ou.edu. As you browse parts of that site, you’ll notice that the domain changes. When you’re looking at your department Web site, say the site for the Chemistry & Biochemistry Department at http://chem.ou.edu, the URL is no longer just ou.edu. Now the root of the url is chem.ou.edu, indicating that you’re on the part of the site that is dedicated to the Chemistry & Biochemistry Department.

If you browse to the technology store pages at http://itstore.ou.edu, you’ll notice that the domain changes again, this time indicating that you’re in the technology store of the OU site.

As you can see the domains serve two purposes: they help to organize the site from a technical perspective, but they also serve as indications to the users that they are in a new/different space.

As you work on your site, you’re welcome to create as many subdomains as you like, and in each subdomain you can actually create a distinct, individual Web site.

The alternative for organizing your space is to simply set up subdirectories. These function much like file folders on your computer. Instead of creating a blog at blog.yourdomain.com you would place it in a subdirectory called “blog” making the address yourdomain.com/blog. Setting up subdirectory is really easy. You can create folders on the fly when installing applications (like WordPress), and you can also manually create them in your file browser.

There is one particular issue you need to be aware of. Let’s say you’ve installed WordPress to be your primary blog at yourdomain.com. Later, you decide you want to create another image gallery site on your site, and you want to place it at yourdomain.com/gallery. But, if for some reason you’ve already created a page on your WordPress site called “Gallery” then the url yourdomain.com/gallery will already be taken. If you try to create a subdirectory of the same name, you’ll get a conflict and errors.

• Subdomains are generally a cleaner, more elegant solution to organizing your site. You’re less likely to get conflicts or errors. However, when using subdomains the process is slightly more complicated: You must create subdomains first, before you can install anything in them.
• Subdirectories don’t create as pretty URLs as subdomains, but they’re easier to set up. They can, however, result in conflicts with existing Web pages.
• As soon as you create subdomains or subdirectories to organize your site, you need to consider how people are going to find them. If you’ve created a new primary blog at blog.yourdomain.com, and someone goes to just yourdomain.com, they won’t see that new site. It is possible to set up redirects to avoid this issue. You can also always create links from pages on one subdomain of your site to another.
• If you really just need one site, sometimes installing at the root of your domain is the easiest thing to do, at least as you’re getting started. You can always add more pieces to your territory later with either subdomains or subdirectories.

• Setting Up Subdomains