Most people don't really bother to understand how the internet works. They just say "I read stuff online". So there is stuff, i.e. content; there is me, i.e. content consumer; and there is the process - reading. This is too simple. First step is to look at the process from the content management perspective: from that standpoint, there is at least one more player, the content creator; and so it is a three part chain - Content Creator -> Online Content -> Content Consumer
In reality, the system is far more complex - here is a more detailed diagram, followed by a step-by-step explanation.
Your content must be stored on a reliable computer with a reliable internet connection, i.e. a web server. The reader finds your server entering a domain name such as uky.edu or twitter.com. Your browser then takes the domain name and "resolves" it. It is like looking up somebody's name in a directory to see their address. Without the directory you won't be able to find that person. The role of the directory is performed on the web by name servers. They translate the domain name into a unique numerical code (the IP address) and send your browser to the correct node on the internet to fetch your connect.
What all this means for you as a CMS administrator is that you have to take care of two things:
1. Find a web server where you can host (i.e. store) your files. That usually means paying them a monthly or an annual fee.
2. Register a domain name - i.e. grab a name that hasn't been used yet (this is where the directory metaphor doesn't work anymore - you can have 10 John Smiths in a directory, but you are allowed to have only one uky.edu - each domain name must be unique) and then store the information on name servers linking your domain name to the IP address of your server. Again, this is usually a paid service, available for an annual fee.
Having discussed the web server and the domain name, let's see what other things have to fall into place for the CMS to be ready for content. You need to do the following:
1. Install the CMS application on your web server. Just like you need to install Microsoft Word or another word processor on your laptop to be able to write a paper, or install Angry Birds on your phone to be able to play the game, you need to load the CMS code on your server.
2. Create a database - a container where your data is stored in an organised fashion, in several interconnected tables. It looks like a really complex tax return with lots of additional forms - lots of field and numbers referencing each other.
3. Tell the CMS how to access the database. This is like giving a new library employee a key to the collections and showing them how to re-shelf books.
So now we have the application and the database - but how do we display the content all to the end user? Let's say we are running an animal shelter web site; we have information about all the cats and dogs we have for adoption. How do we display a list of all cats we have, accompanied by their picture?
The database might have a record in the table "Cats" looking like this:
Cat ID = 1; Cat Name = Kitty; Fur Color = black; Admitted to shelter = January 10, 2011; Admitted by staff member: Mike; Picture file location: images/cute_kitty.jpg
The application might have rules written in a programming language that in human language amount to something like this:
Find out if they are interested in cats or in dogs, then look for the right table in the database, and retrieve the information about cat names and cat pictures; sort the information by date of adoption.
The problem is, the browser can't display either the database record or the programming language algorithms. It needs the final text that it will feed the user, and the instructions on where to place the text on the screen (middle column? drop down menu? top of the page? etc). and how to style it (what font to use? what size of font? bold or italic? what colors to use? what about borders and spacing?)
In the end, it takes four technologies to solve the problem. We have mentioned two - databases and web applications; but we need markup and styling to finish the job - and all four must interact correctly.
Browsers work with markup and styling, not with databases. The web application is the go-between - it gets a request from a user (show me a list of black cats), translates it into a request sent to the database, the database sends a response with the data requested; the application then takes the response and re-writes it into the markup that a browser can understand. That output can be presented without any styling; but usually some styling is applied before it is sent to the browser. It is like the difference between a type-written manuscript - page after page of text, with black ink only and the same font size and margins, and a finished textbook - pictures, fancy cover design, complicated page layouts, and a variety of colors and fonts. And just like a textbook's looks may change from one edition to the next, so can the same web content look very different with different styles applied.
Next we will discuss the different types of code that drive these four technologies: databases, web applications, markup, and styling. Each uses its own flavor of a coding language, and you need to have a basic understanding of how each works.