April 27th, 2010 §
Overview
HTTP is the protocol which web browsers and web servers use to communicate via client requests and server responses, respectively. We’ve seen that the browser uses HTTP GET and POST methods to request data from the server.
HTTP also provides a very basic level of authentication which you can use to password-protect your sites or certain folders within your sites. And Apache servers, such as our class server, make it is possible to use this authentication system by simply writing a bit of special code in a file called .htaccess.
We have previously used .htaccess files for rewriting URLs to create Fancy URLs. The .htaccess file is a directory-specific configuration file – it can hold a variety of server settings that apply only to the folder in which you place it. This post is about one such setting.
Password-protecting a folder
To password protect a specific folder, we will create two files: one named .htaccess and another named .htpasswd.
.htaccess holds the server instructions indicating that the folder should be password protected. This file gets placed in the folder which you want to password protect.
.htpasswd holds the username/password combinations of users who are allowed to view the folder. Passwords are encrypted. This gets placed somewhere on the server where it is not accessible from the web – you don’t want people loading this file up directly in their web browsers.
The .htaccess file
The .htaccess file contains the following code.
AuthUserFile <the server path to the folder where your .htpasswd file will live>/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
Replace <the server path to the folder where your .htpasswd file will live> with the path to your own .htpasswd file. Ideally this will be somewhere outside of the web root of the server. On the class server, the web root is the folder /home/scps/onepotcooking.com/
As an aside, saying this is the “web root” means that when a user goes to http://onepotcooking.com in their browser, they will by default view the files in the folder /home/scps/onepotcooking.com. The “server root” is /, the very topmost folder on the server.
So, if your name is George Washington, perhaps put your .htpasswd file at
/home/scps/passwords/georgewashington/.htpasswd
so it is outside of the web root, yet still somewhere you might be able to find it again if you ever went looking.
The .htpasswd file
The .htpasswd file will contain one of the following lines for each user that has access to the protected folder:
<username>:<encrypted password>
Replace <username> with the username of the user you want to give access. And replace <encrypted password> with an encrypted password for that user.
How do you get an encrypted password? You use one of the many websites that encrypt your .htpasswd passwords for you for free, such as this one.
So, for example, if your username is “scps” and your encrypted password is “pnzpsMNdWW6aw”, you will put the following line in your .htpasswd file:
scps:pnzpsMNdWW6aw
And you will save this .htpasswd file into the folder that you indicated in the first line of your .htaccess file.
An example
See an example here. The username is our standard username, and the password is our standard password minus the last character. You’ll notice that I have been naughty and put the .htpasswd file in the same folder as the .htaccess file. On a real site you shouldn’t put it anywhere where a web browser can find it.
How it works
Here’s an overview of the steps that are happening behind the scenes to make this system work:
- Your client (most likely your web browser) makes a standard HTTP GET request for a password protected area of the server
- The server looks for any .htaccess file in the requested folder
- The server reads the .htaccess file and sees that the requested file or folder should be password protected
- The server responds to the client with an HTTP HTTP response code indicating that the requested file is password protected.
- The browser is built to know what to do with this response code: it pops up a dialog that the user must fill in with a username and password
- The user fills in the username and password and clicks submit
- The client sends another HTTP GET request to the server, but this time includes the login credentials as extra HTTP headers along with the request.
- The server again looks at the .htaccess file and sees that the requested file or folder is password protected, but this time notices that the client included the necessary login credentials along with the request
- The server responds to the client with the requested page
- The client stores the login credentials the user entered somewhere on the client machine (similar to a cookie) so that next time the page is requested, it doesn’t have to ask the user to enter them again. The client just sends them to the server in the HTTP headers automatically.
February 13th, 2010 §
Loading a web page involves multiple requests for various files from the server
When a user loads a web page in a web browser, a sequence of HTTP requests are made to the server for the various files necessary to display the web page properly in the browser.
For example, let’s say a user loads this site, http://wd.onepotcooking.com/. Here is a set of steps that may be triggered as a result of a simple action such as this:
- Typing that URL in the address bar and clicking “go” causes the browser to make an HTTP request to the wd.onepotcooking.com server for the default web page at that address.
- The server finds the file on its hard drive that contains the default HTML code for the requested page of the site, and sends that code to the browser as part of its HTTP response to the browser’s initial request.
- The web browser then may automatically send another request for the default favicon file that goes along with the requested website. The favicon file is the little image that sometimes shows up next to the address in the web browser.
- The server will try to find the favicon file that goes along with the requested web page on its hard drive, and if such a file exists, it will send the contents of that file back to the browser as part of its HTTP response.
- The web browser will eventually start analyzing the HTML code it received back from the server in response to its first request. The HTML code may indicate to the browser that there are other files necessary in order to display the requested web page properly in the browser. These might include CSS files that contain style and design information about the page, Javascript files that define interactive behaviors that should happen on the page, image files that are used for graphics or photos on the page, and other file types such as Flash animations, Java applets, and a variety of other more obscure types of content that may show up on some web pages.
- The web browser will go through this list of files and request them one-by-one from the web server using the same HTTP request/response mechanism until all files that are necessary to display the web page properly have been received from the web server.
- Finally, the web page shows up nicely in the web browser and the user is happy.
December 4th, 2009 §
Now that you know all the basic techniques of web development, it’s time to start thinking about aesthetics. One the most obvious aesthetic choices you can make on your site is what domain name you choose, and what you call the file names on that site. Domain names are something I can’t help you with, but the rest of the URL after the domain name, including the folder and file names, is something I can help you beautify.
This is an advanced topic, but one that can provide polish to your sites if you are comfortable with all we have covered so far.
The problem: ugly URLs
As you know, depending on what we call our files and how we use the query string to pass data from one page to another, we sometimes end up with URLs that look like this:
http://onepotcooking.com/index.php?post=19&view=rss
But you might rather have URLs that look like this:
http://onepotcooking.com/rss/post/19/
And actually, search engines sometimes prefer more descriptive URLs, so they can more easily determine what a page is about:
http://onepotcooking.com/rss_feed/why_urls_should_be_pretty.html
But you don’t want to change the structure of your folders and file names, and change the entire way you use the $_GET, $_POST, and $_REQUEST variables in PHP just to make the URLs pretty. When you’re coding the site, you’re usually thinking about functionality and getting the job done, not aesthetics.
The solution to URL woes: mod_rewrite
Apache, the most popular software used by web servers to handle the requests and responses for web pages (and the software used by our class server and most other UNIX web servers) comes with a module called mod_rewrite that is used for creating custom URLs.
mod_rewrite lets you publish fancy URLs like:
http://onepotcooking.com/isnt_this_a_prety_url.html
But have them actually get converted internally into ugly URLs like this, without the user ever seeing it:
http://onepotcooking.com/process_something.php?id=1884&to_do=something&this_is=ugly
You will be able to use the fancy URLs for any links to your pages, but your folders, filenames, and PHP code will not have to change, so long as you use mod_rewrite correctly.
Rewriting vs. Redirecting
This process of having fancy URLs that get internally converted by the server into ugly URLs is known as URL rewriting. With a rewrite, since it only happens internally in the server, the user only ever sees the fancy URL. They will never see the ugly URL in the browser address bar.
However, the term redirect is generally used to refer to the technique where client, meaning the web browser, handles the redirecting. In the case of a client-side redirect, the user can see the final destination URL in the browser’s address bar after the redirect occurs. So they will ultimately see the ugly URL clearly in the address bar of the browser.
Another look at the client/server request/response relationship
To understand how mod_rewrite works, it’s important to understand where it fits into the whole request/response relationship. Here’s a very broad overview of the just relevant steps of what happens when a client requests a file from a server:
- a user tries to load a web page in the browser (whether by going directly to a URL, clicking a link, submitting a form, or making an AJAX request)
- the browser sends an HTTP request (either GET or POST) for the file to the server.
- the server receives the request, and launches Apache’s request handler
- Apache tries to figure out how to respond to the request
- Apache first checks mod_rewrite settings to see if it should do any fancy processing of the URL of the file that the user is requesting
- Then, if Apache determines that the requested file is a PHP script, it launches the PHP engine and sends any data that was passed along with the request to the PHP script that the browser requested
- The PHP script runs and sends its output back to Apache
- Apache sends a response to the web browser. The response contains an HTTP status code indicating some information about whether the request was processed properly or not, as well as any content that was output by the requested file, regardless of whether it’s a PHP script, HTML file, CSS file, Javascript file, or any other type of file.
- The browser receives the response from Apache, and figures out how to display whatever content it received back from the server to the user.
As you can see, the mod_rewrite technique we will be discussing that allows sites to use fancy URLs will occur after the server has received the request from the browser, but before it has passed that request on to the PHP processor. It will be written in language that Apache can understand, not in PHP, since when it is processed, the PHP engine hasn’t even been launched yet.
Apache configuration files: httpd.conf and .htaccess
When a user requests a URL like this:
http://onepotcooking.com/spring2010/test.php
the Apache server checks two sets of configuration files to see whether it should do something fancy with that URL.
First, Apache checks its main configuration file, called httpd.conf, which is usually buried somewhere obscure in the deep recesses of the server filesystem. Httpd.conf has global settings that apply to your entire site. If you have a shared hosting plan for your site, which most of you will do, you do not have access to this file.
After it has checked httpd.conf for any relevant settings, Apache then checks the directory-specific configuration files called .htaccess, which have settings that apply only to specific folders.
With the example URL above, Apache would have to check for the existence of either of these two .htaccess files:
/.htaccess
/spring2010/.htaccess
Since the requested file is nested inside the spring2010/ folder, which is inside of the root / folder, either of those settings files could have an effect on how the request for the file is handled by the server.
We will be focusing on settings in the .htaccess files since these are the ones you will always have access to, regardless of your hosting setup. However, the same URL rewriting techniques will be applicable to settings in the httpd.conf file, with slight modifications.
How to use .htaccess files to rewrite URLs
Rather than rewrite an entire tutorial on how to rewrite URLs (which I initially started to do), there is an excellent tutorial already written which covers all the basic types of rewriting you are likely to do:
http://corz.org/serv/tricks/htaccess2.php
Note: Although I don’t think it’s clearly described on this site, all of the example code written there is meant to go into a file called “.htaccess” located in the root folder of your project. So if your project is at http://onepotcooking.com/johnhancock/final_project/, you should create an .htaccess file located at /johnhancock/final_project/.htaccess, so you can create fancy URLs like http://onepotcooking.com/johnhancock/final_project/this-is-a-fancy-url.html
In other words, fancy URLs only work at the level at which you put an .htaccess file. If you want a fancy URL like http://onepotcooking.com/this-is-a-fancy-url.html, you need to put an .htaccess file in the root folder of the server, /.htaccess.
I highly recommend you read that otherwise well-written document linked above if you wish to use fancy URLs on your own sites.
An example page
I have created a single example PHP script which can be accessed by a number of fancy URLs by taking advantage of rewriting rules found in a .htaccess file in the same folder. The PHP script just outputs whatever data was passed to it in the query string along with the GET request.
In other words, there is an .htaccess file which is allowing a variety of fancy URLs to all internally point to the same PHP script. Each URL is meant to exhibit a slightly different aspect of URL rewriting that may be useful to you. Several of them focus on passing data through the query string even though there is no query string in the fancy URL.
You will definitely want to read that tutorial linked above before going in to read the code in this example.
The direct URL to the example script is http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/index.php
The fancy URLs that internally rewrite to that same script are:
And the following URL uses mod_rewrite to do a client-side redirect (not a rewrite):
Reminder: all the rules that allow these URLs to point to and pass data to the same index.php script are found in the .htaccess file in the same folder as the PHP script.
July 25th, 2009 §
As we discussed in class, registering a website domain (e.g. registering a name such as “onepotcooking.com”) is a different transaction from hosting a website (i.e. renting space on a server where you can put your files).
However, most web hosting companies also throw in a single domain registration as a freebie for signing up for one of their web hosting plans. Plus, I have a promo code here that you can use to get further discounts from Dreamhost.
The Dreamhost promo code I am posting here will get you $20 off of a pre-paid monthly plan, and $40 off of a pre-paid yearly plan. I get a nice bonus by referring you, so although I think this is a pretty great discount for you, I also benefit by promoting it. It’s a good deal all around, but obviously you should still compare prices with others like StartLogic, GoDaddy, etc. There is no lack of competition in this market.
The Dreamhost promo code is:
WEBDEVSUMMER09
Probably the best selling point is that your own setup will be almost identical to what we used in class, since onepotcooking.com is hosted on the cheapest basic Dreamhost shared hosting plan.
I find it to be no-nonsense, well set up, relatively open, and with a very straightforward control panel that allows you to easily create and manage databases, email addresses, one-click installation of many pieces of common software such as WordPress and others, and few restrictions on usage. But it does have its ups and downs like any other hosting provider. I am not personally as familiar with the equivalent plans at other hosting companies, but I assume they all offer the same basic functionality.
July 23rd, 2009 §
We have talked a bit about SEO and optimizing your site to be indexed by the major search engines in searches for particular keywords. We generally, but not always, want to make it easy for search engines to figure out what any given page is about. So it only seems appropriate that we should discuss the opposite procedure: how to prevent search engines from indexing your site.
The major search engines, run by Google, Yahoo, and Microsoft, send out spiders, which are automated programs that crawl the web in search of websites. Every page on every website a spider encounters is analyzed, categorized, and logged in a giant database. That database is what is used when someone does a search on a search engine for a particular term. If your site has been categorized as being related to that term, your site will show up in the search results on the search engine’s website.
Before any of the major search engines’ spiders index the contents of your site, they will look for a file on your web server called robots.txt. If you want to prevent the search engines from indexing your site and mentioning it in their search results, you should create a robots.txt file and upload it to the root folder of your website.
To prevent spiders from indexing the entire site, put this code into your robots.txt file:
User-agent: *
Disallow: /
To prevent spiders from indexing only the subdirectory called “private”, put the following code in your robots.txt file:
User-agent: *
Disallow: /private/
To prevent spiders from indexing both the “private” folder, and another folder called “my_stuff”, use a robots.txt file with the following code:
User-agent: *
Disallow: /private/
Disallow: /my_stuff/
And so on. You can repeat the “Disallow” command with as many folders as you want to keep private.
For more information about robots.txt,check out The Web Robots Pages.
July 22nd, 2009 §
You should consider the URL address of your site to be part of its design. A memorable URL, and a nicely designed favicon are probably the first two things anyone sees of your work.
Intro to Favicons, Fancy URLs, and Search Engine Optimization
To read about what a favicon is, and how to create one, click that link.
To read about what I mean by fancy URLs, and how to create them, click that link. A simpler example than those found on this link follows in this post.
Fancy URLs, meaning intuitive URLs that are easy to understand, are also important for Search Engine Optimization (SEO). Click to read more about developing your web site with SEO in mind.
An example of Fancy URLs
I will now outline a relatively simple example of creating Fancy URLs. Click to see this example in action.
By clicking that link to see this example in action, your browser will bring you to this URL:
http://onepotcooking.com/amosbloomberg/summer2009/class9/mod_rewrite/animals/
If you click one of the animal names in that file, your browser will bring you to a URL that looks like something like this:
http://onepotcooking.com/amosbloomberg/summer2009/class9/mod_rewrite/animals/15
The first thing to notice is that if you view the files in that project folder on the server, you’ll see that there is no subfolder called “animals/ ” in there. So Fancy URLs are a euphemism for Fake URLs.
The .htaccess file
The file named .htaccess in this folder contains a few rules that make this trick possible. The first rewrite rule in the file is this:
RewriteRule ^animals/$ index.php [QSA]
This says that if the browser requests the folder “animals/“, the server should respond by sending the file “index.php” to the browser instead.
The second rule looks like this:
RewriteRule ^animals/([0-9]+)$ index.php?animal_id=$1 [QSA]
This rule says that if the browser requests the folder “animals/” followed by any number, such as “animals/15“, then the server should convert that into a request for the file “index.php?animal_id=15″ instead.
As you can see, in this second rule, part of the Fancy URL has been converted into a bit of data passed via the query string along with the request for the file. This is a common trick to make it less obvious that data is being passed to the server with the request.
July 22nd, 2009 §
Some sites allow users to upload files to the server. Most often, this is the case for sites that allow users to upload images. But the same technique is used regardless of the type of file. Uploading files of any type, be they images, audio files, video files, text files, or any other type, is a singular process.
This example shows how to allow users to upload files to the server. As with any site, it all starts with the XHTML. Click here to see this example code in action.
An XHTML page with a form
When uploading files to the server, it is absolutely necessary to give the <form> tag an extra attribute: enctype=”multipart/form-data”. This tells the server that it should expect to receive not only text in the form data, but also possibly a file as well. Omitting this extra attribute is a common mistake.
Here is an example XHTML page with a file upload form on it. We’ll call it “index.html“. The especially relevant bits for this example are the <form> tag, and the <input type=”file”> tag:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>File Upload Example</title>
<link rel="stylesheet" type="text/css" href="styles/main.css" />
</head>
<body>
<div id="container">
<h1>File Upload Example</h1>
<p>Please upload an image:</p>
<form action="process_file.php" method="POST" enctype="multipart/form-data">
<input type="file" name="uploadfile">
<br /><br />
<input type="submit" value="Upload!">
</form>
</div><!-- end container -->
</body>
</html>
When the user clicks the submit button, the data entered into the form is sent along with an HTTP POST request to the server for the script, “process_file.php”. This we surmise from the “method” and “action” attributes of the <form> tag.
A PHP script to process the uploaded file
The following code is from “process_file.php“, which is the PHP script that receives the data passed along with the HTTP POST request, and decides what to do with it.
<?php
require_once("Uploader.class.php");
//create a new instance of the Uploader class
//the constructor function for the Uploader class takes three parameters: the "name" attribute of the <input type="file" name="..."> field, the subdirectory where you want to store the files, and the maximum file size allowed
$uploader = new Uploader("uploadfile", "files", "10M");
//try to do the upload
if ($uploader->upload()) {
//it worked... so get the new location of the file from the $uploader->getPermanentPath() function
$path = $uploader->getPermanentPath();
//redirect to success page, and pass the new path along
header("Location: success.php?path=" . urlencode($path));
}
else {
//it didnt work! so get the new error message from the $uploader->getError() function
$error = $uploader->getError();
//redirect to failure page, and pass the error message along
header("Location: failure.php?error=" . urlencode($error));
}
?>
Let’s analyze this file. The first thing we do is require the inclusion of another file, named “Uploader.class.php”. This file is an object-oriented bit of PHP code that I have written. This Uploader class file contains the code that does the dirty work of file uploading.
The nice thing about object oriented code is that it is built to be taken for granted (click here if you’re interested in a brief intro to object-oriented concepts.) This is one of the core philosophies of object-oriented coding: different processes should run independently of one another, and the internal workings of each process should not matter to the functioning of the other processes. This is known as “encapsulation”. So in this case, I will not explain how this class works. The code is well commented if you want to look for yourselves. I will just describe how it should be used.
Once we have included the Uploader class file, we create an Uploader object. To do so requires passing three pieces of data to the Uploader “constructor function” (read here for a brief intro to how to do object-oriented programming in PHP)
$uploader = new Uploader("uploadfile", "files", "10M");
- The first parameter is the value we gave the “name” attribute of the <input type=”file” name=”…” /> tag in the XHTML form, in this case it is “uploadfile”.
- The second parameter is the subdirectory on the server where we want to store any uploaded files… you’ll see on the server that we have set up a “files” subdirectory in this project folder. (Note: This folder must allow web browsers to write data to it. You can use a file-transfer program such as WinSCP or Cyberduck to make sure the permissions for this folder allow “Others” to “Write” to it. Usually this can be done by right-clicking on the folder in WinSCP, or Control-clicking on the folder in CyberDuck, and selecting the “Properties” or “Info” menu in WinSCP and CyberDuck respectively)
Control-click menu in Cyberduck
Info menu in CyberDuck - make sure "Others" can "Write"
- The last parameter is an option maximum file size that you want to allow users to upload, in this case 10M.
Now that the object is set up, we try to do the upload, and we test to see if it worked or not.
if ($uploader->upload()) {
//... it worked ...
}
else {
//... it failed ...
}
If the upload was successful, we redirect the browser to a “success.php” confirmation page. We also pass along the path of the newly uploaded file on the server to the success.php script.
If the upoad failed, we redirect the browser to a “failure.php” page that explains that an error occurred, and we pass along an error message as part of the request for that failure.php script.
The success confirmation page
The success.php confirmation page simply shows a user-friendly message indicating that the upload was successful. The PHP script on this page retrieves the data that was passed along with the HTTP GET request for the page. This data is the path of the newly uploaded image file on the server. The script on this page uses that path as the “src” attribute of an <img> on the page, which makes the uploaded image appear on the page.
<?php echo "<?" ?>xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Success! File Uploaded</title>
<link rel="stylesheet" type="text/css" href="styles/main.css" />
</head>
<body>
<div id="container">
<h1>Success! File Uploaded</h1>
<p>Thanks. Your image has been successfully uploaded to <?php echo $_REQUEST['path'] ?></p>
<a href="<?php echo $_REQUEST['path']; ?>">
<img src="<?php echo $_REQUEST['path'] ?>" />
</a>
</div><!-- end container -->
</body>
</html>
The failure error page
The failure.php error page simply shows a user-friendly error message indicating that the upload was unsuccessful. The PHP script on this page retrieves the data that was passed along with the HTTP GET request for the page. This data is the error message that was output by the Uploader object.
<?php echo "<?" ?>xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Failure! File Not Uploaded</title>
<link rel="stylesheet" type="text/css" href="styles/main.css" />
</head>
<body>
<div id="container">
<h1>Failure! File Not Uploaded</h1>
<p>Your image failed to upload</p>
<p><?php echo $_REQUEST['error'] ?></p>
<p>
<a href="index.html">try again</a>
</p>
</div><!-- end container -->
</body>
</html>
July 15th, 2009 §
Efficient file management is a prerequisite for any successful development work. Over time, you will become acclimated with how files are stored on a Unix server, Windows PC, or a Mac. In the meantime, here is a set of conventions that may help you effectively manage files during the duration of this course. By following a few simple rules, we can make sure that file management does not prevent you from learning to be a great developer.
Rule #1 – Always use a “workspace” folder
Create a folder that will always function as your workspace. Store all other files and folders you create inside of this workspace folder. This way, you will always know where your files live, and how to find them.
For example, I may create a subfolder in the Documents folder (a.k.a. My Documents on a PC) and call it “webdev”. This will function as my workspace folder for all the web development work I do. Whenever I want to find some files I worked on, I know that I have to look inside of the webdev folder inside of the Documents folder.
To create a new folder, navigate with Windows Explorer (or Finder on Mac) to the location where you want to create the folder.
In this example, I will navigate to the Documents folder, where I want to create my workspace folder.
Navigate to your Documents folder in Windows Explorer or Mac Finder
Once you are in the location where you want to create your workspace, click the File menu, and select New -> Folder. Enter the workspace folder name, and click the Enter button to create that folder.
Then double click on the new folder name to go into that folder.
Create the workspace folder
Navigate into the new workspace folder
Rule #2 – Create separate subfolders for each project
For each project, assignment, or other task, create a new subfolder within your workspace folder.
For example, when beginning a project called “project1″, from within your workspace folder, click File -> New -> Folder, and create a folder called “project1″. Then double-click that folder to go inside it.
Create a project folder inside the workspace folder
Rule #3 – For each project, set up subfolders for CSS files, Javascript files, and image files
A typical project will have XHTML files, Javascript files, CSS files. It is important to be organized about where you store each type of file. As a general rule, within each project folder, you should:
- put XHTML files in the main project folder
- put images in a subfolder called “images”
- put Javascript files in a subfolder called “scripts”
- put CSS files in a subfolder called “styles”
So for a project called “project1″, for example, you would set up subfolders that look like this:
A typical project folder setup
And we will eventually put XHTML files in the main project folder. So a typical setup after we create our first XHTML file will eventually look like this:
Typical project folder with XHTML file
Notice that the main XHTML file, called “index.html”, is in the root project folder. And there are subfolders for each other type of file.
Rule #4 – Maintain the exact same folder structure on the server
To avoid complication, you should use the exact same folder structure on the server as what you created on your client computers.
When you use a file transfer program, like WinSCP (or Cyberduck on Mac), you will be able to view the files on the client side-by-side with the files on the server. The structure of your project folder should look the same on each.
Note that WinSCP on PC will show you files on both the client and server in two different panes. With Cyberduck on Mac, you will have to have the Finder open to view files on the client, and use Cyberduck to view files on the server.
Viewing client and server files side-by-side in Cyberduck and Finder on Mac
Rule #5 – Know your URLs
When you’re ready to test your files to see what they look like in the web browser, you have to know the location of your files on the web. When using WinSCP, you can infer the location of the files on the web from the location of the files on the server’s hard drive.
In WinSCP, at the top of the right pane (the server pane), you will see the location of your files on the server’s hard drive. The location of these files on the web is included in this path.
The URL of your files on the server
This is the location you should enter into Firefox’s address bar.
The URL to enter into the Firefox address bar
Note: Not all servers are set up exactly like this, but you can usually infer the location of your files on the web from the location of your files on the hard drive in a similar way.
