Recipe 2.3. Organizing Your Files in Directories

Problem

You need a plan for putting site assets in their proper place, so you and others who work on the site can easily find and update the right file at a later date.

Solution

Group your files by content, method of creation, and access level, and then create directories on your web server where they can be uploaded and modified as needed.

From a command-shell prompt, you can create a directory with the Unix mkdir command. A full-featured FTP client or WYSIWYG site management applications should offer a menu command for creating directories on a remote server as well.

Discussion

Don't build a site where every file commingles with every other file in an unorganized mess at the top file level of your web server. Well-planned web site organization requires a lot of advance planning, but pays dividends as your site grows and changes. Try to mirror your web site's navigationthe links and buttons that visitors follow through your sitebut keep in mind some of the limits of the server file system as you do.

Unlike the folders you create on your desktop PC, web site directory names should not contain spaces. The server will convert spaces to the unaesthetic (but not unusable) encoding %20. Likewise, avoid special characters: The server might mistake ampersands (&) and questions marks (?) for delimiters in a CGI script argument; the number (or pound) sign (#) is used in HTML markup to create a link to another section of the same web page. Hyphens and underscore characters are safe, butas you saw in Recipe 1.1they add an unnecessary stumbling block to people trying to memorize a URL or recite it over the phone. Best to leave them out, if possible. Finally, use all lowercase; on Unix servers, the directory and filenames that make up a URL are case sensitive.

Every site should have separate directories for the supporting files that are not linked to directly on your site, such as GIFs, JPEGs, and PNGs (in /images), server-side includes (in /includes or /ssis), Flash or QuickTime files (in /movies), stylesheets (in /styles or /css), and client-side scripts (in /scripts, /javascripts, or /js).

Generic directory names for supporting files are better than names that describe the technology of the files they contain. /styles is usually better than /css, and /scripts is usually better than /javascripts. And, it makes upgrading to different technologies a lot easier. (Who wants to refer to /javascript/validate.php?\)

On a large site, you may want to divide these directories into subdirectories that reflect the site structure. For examples, images for the products section could go in /images/products, images for events in /images/events, and so forth.

Separating files by content and creator makes keeping track of everything much easier. Keeping the web page for a product demo in the /demos directory and the movie of the demo in /movies/demo prevents you from deleting or overwriting the wrong file. It's all too easy to overwrite widget.mpg when you meant to replace widget.html if all of your files are in the same directory.

Maintaining separate directories for site files has other practical benefits. Although Unix can easily store and retrieve several thousand files in one directory, I start to get dizzy when sorting through a list of more than a couple of hundred files. Grouping files in directories also allows you to segregate files with different security settings or permissions. Web hosting companies commonly restrict CGI scripts that run on the web serverin other words, executable filesto the /cgi-bin directory. You may have other files to protect, such as customer order logs in a directory for which only you have read access, or downloadable files in a directory that require a password from visitors to gain access.

Problem

Solution

Discussion

See Also