More Q&A

2. How do I set Fetch for uploading correctly?

Use your Fetch Preferences to establish the settings. Upload graphics as "raw"; upload html and other text files as "text". Then you don't have to think about what setting to use.

3. How do you keep track of all the files you have?

Organize your hard drive html and graphics folders exactly like you want them on the server. All folder names should be the same as the server directory (including public_html directory), and all relative locations should be the same on the server and your hard drive. That way your browser can find the files equally well on the server and offline (except in the case of image maps, which only work online).

In a pinch then, if you somehow trashed your whole public_html directory on the server, you could simple upload the entire hard drive folder "public_html" at once, using the Fetch menu command "PUT file or folder", to restore the entire contents in a single upload command. (You would probably have to re-create the empty directory using Zterm, before you could replace it, if you had actually deleted it!) Keep stuff out of your hard drive's public_html folder which doesn't belong "upstairs" on the server!

We keep an "html for upload" folder on our hard drive. It contains duplicates of files we've tested in our hard drive's public_html. When we've done the upload, we drag the source file in Finder form the upload folder to the public_html folder. We expect a Finder error notifying us a copy of the file already exists. We tell finder to go ahead and replace the existing copy. Sounds stupid, but it confirms we uploaded the right file, empties the upload folder, and ensures that everything on the hard drive is the same as what's in public_html upstairs.

We also keep a "graphics" and "graphics for upload" folder, and treat these the same way.

4. How do you make and use subdirectories?

The organization on the server is exactly analogous to the way you use folders in Finder, but the usage and html calls are not quite as straightforward. Calls to subdirectories are convenient going down to lower level, but not up to higher levels. Here''s how it works:

We keep a "graphics" subdirectory under the public_html root level directory. Where, before, your HTML "call" to an image (in the same directory) was <IMG SRC="mygraphic.gif">, now it is <IMG SRC="graphics/mygraphic.gif">. Foolproof; works every time.

But we also keep a subdirectory called "PAUG". Going from the home page (root level) index to the PAUG home page is easy. Where, before, your HTML call to another page (in the same directory) was <a href="PAUG.html">, now it is <a href="PAUG/PAUG.html">. So far, so good. But what happens when you're at the PAUG page and want to go UP a level, to the index.html page?

The browsers are not very good at "relative addressing". They get confused. From within the PAUG subdirectory, "public_html/index.html" will only get you an URL error, because this tells the browser to look for a folder called "public_html" inside the PAUG subdirectory. When you want to go UP to a higher level directory, the only way we've been able to get it to work is to give the FULL filepath: from the PAUG page, to get back to index.html, we provide the URL <a href="http://www.summitlake.com/index.shtml">.

Working within the same level subdirectory is exactly the same as working within the root level directory. As long as you don't cross to any higher levels, the call is the "short filepath", i.e., filename.extension or mysubdirectory/filename.extension.

Therefore, to reduce clutter, I also keep a folder called "graphics" in the PAUG subdirectory. Calling a graphic in this sub-subdirectory, from within the PAUG subdirectory, parallels the similar call made from the home index page: "graphics/mygraphic.gif". If I also wanted a PAUG HTML sub-subdirectory (say, for these Q&A pages -- I do not!), each page within it would have to make calls to the FULL filepath to hotlink it back to the higher level pages.

5. Don't you find you have duplication with multiple graphics folders?

Yes. When we're dealing with 4K icons, we don't care. It beats having a "full filepath" call for each of ten color dingleberry bullets -- a tremendous waste of time and web resources.

E-mail:Write Summitlake.comAlex Forbes
Return to HTML Q&A