Where are we?

When you work with a site owner, you need to have a way to get feedback from him or her about your work. This lesson shows you how to create a private version of a site that only you and the owner can access.

This lesson’s goals

By the end of this lesson, you should:

• Understand why you need a development site.

• Know about several options for development sites.

• Be able to password protect a directory.

• Know that using relative URLs will make publishing a site easier.

Why you need a development site

When you – a Weber – work on a site, you talk a lot with the site owner. You show the owner something, and ask for feedback. You change the site, and ask again.

Figure 1. Weber and owner working together

Of course, the site owner could be you, in which case you talk to yourself a lot. Try to keep those conversations private, or you could find yourself spending time in a “special” kennel.

You don’t want regular people to see the site as you’re working on it. Just the owner, and other people you want to get feedback from.

Only when the site is ready do you show it to the outside world. This is often called publishing the site.

Figure 2. Weber publishing the final site

So you need:

• A development site. A version of the site that only a few people can see.

• A production site. The finished site, copied from the development site.

Sometimes the development site is hosted on a special development server, a machine (or Web hosting account) that is physically separate from the production server. But sometimes the development and production sites are on the same server.

Let’s look at some ways you can create a development site that only you and the site owners can see. I’ll assume that the production site will be on a shared Web host, like Hostgator.

For this page, let’s say you’re working on a site about dog blankets. It will be at dogblanket.com.

Your regular computer

You can just create the site on your own computer. This works well if you are building a site for yourself, or if you and the owner can easily get together over the same computer.

There are two ways to do things. The easiest is just to create a directory somewhere on your disk drive. Put the files for the site there. For example, if you are working on the dog blankets site on a Windows computer, you might put the files in Documents\websites\dogblanket.

Another way is to install the Web server Apache on your own computer. You can download XAMPP from ApacheFriends. XAMPP packages Apache with some other common server software. You usually install it on the C:\ drive (for Windows). The root of the XAMPP Web server will be something like C:\xampp\htdocs\. So you would put the files for your dog blanket site in C:\xampp\htdocs\dogblanket\.

You need to install XAMPP if you want to run PHP programs on your computer. These could be programs you write yourself, or things like content management systems, photo galleries, newsletter programs, or other software that other people write. More about this in the book ServerCore.

A portable file system

Another alternative is to put your development Web site on a portable file system, that you can carry around with you. One way to do that is with a USB thumb drive. Plug it in to your own computer when you want to work on the site yourself. When you go talk to the owner, plug it in to his/her computer.

You can also put software on the device, like the editor Notepad++. You can make quick changes to the site when you’re working in the owner’s office.

The ultimate portable file system is a laptop or netbook. It comes with a computer attached. This is a good option, because you don’t have to use the site owner’s computer when you visit him or her. You have all of your own software, browser bookmarks, and so on.

A directory on your Web host

The problem with using your own computer or a portable file system is that you and the owner have to be physically in the same place to work together. It would be nice if you could make a change to the development site, and send an email to the owner, asking “What do you think of that?” The owner could respond, and you could change it again.

One approach is to create a directory on your Web hosting account, and use it to host the development site. The directory tree on your Web server for the dog blanket project might look like this:

Figure 3. Development site in directory

The development site (the green box) is a another version of the actual site (the blue box). It’s inside the production site’s directory tree. You can mess with the development version without affecting what users of the production site see.

The domain name is dogblanket.com. The URL of the production home page would be http://dogblanket.com/index.html. The URL of the development home page would be http://dogblanket.com/development/index.html.

Figure 4. Home pages

There are two things you should do to make this work smoothly:

• Password protect the development directory

• Use relative URLs

Password protect the development directory

Your Web host’s control panel probably gives you an easy way to put passwords on directories. This is from the homepage of one of Hostgator’s control panels:

Figure 5. Protect a directory with a password

You select a directory to protect (like the development directory), then enter a user name and password for it:

Figure 6. Creating a user name and password

You can create more than one user name and password for the directory. But usually you won’t need to.

When a user tries to access a file in the directory, s/he has to enter a user name and password:

Figure 7. Authentication

Use relative URLs

When your development site is ready, you want to copy its files into the production area. It’s easy to break pages when you do do this.

Suppose you were writing the page at http://dogblanket.com/development/index.html. This is the home page of the development site. You wanted a link to the main page of the products section of your site. So you added this HTML, with an absolute link:

<p>Check out our awesome <a href="http://dogblanket.com/development/products/index.html">products</a>.</p>

Works just fine. Now suppose you publish the site. You copy all of the files from the development directory into the main part of the site. That means you copy the file http://dogblanket.com/development/index.html to http://dogblanket.com/index.html, and http://dogblanket.com/development/products/index.html to http://dogblanket.com/products/index.html.

You want the link in the HTML to go to http://dogblanket.com/products/index.html. But of course, it doesn’t, because you’ve hard-coded the link to http://dogblanket.com/development/products/index.html into your file.

Rats! You have to go through every file, find every link, and change it. That takes time. And it would be easy to make a mistake.

But suppose you had used the following HTML in http://dogblanket.com/development/index.html:

<p>Check out our awesome <a href="products/index.html">products</a>.</p>

This is a relative link. It says, “From wherever you are right now, go down into the products directory and find index.html.” Everything would work just fine. As long as you maintain the relationship between index.html and products/index.html, you can put the files anywhere you want.

So, when you work on your site, use relative links. If you have to use an absolute or root relative link, make a note of it. Then remember to check the link after you publish your site.

For more on relative, absolute, and root relative links, see the lesson making links.

Summary

In this lesson, you learned:

• Why you need a development site.

• Several options for development sites.

• How to password protect a directory.

• That using relative URLs will make publishing a site easier.

What now?

Now you have a place to work. Let’s get started by working out the goals of the site.