MS FrontPage —

Setting Publishing Preferences

Before you actually send your files out onto the Web, you need to supply FrontPage with some important information: what technology exists on the server you're publishing to and where exactly you're sending your files. You also have a few different options for specifying which pages FrontPage will publish.

Selecting a Remote Web Site

To access FrontPage's publishing options, open your site and select File » Publish Site. (You can also click the Web Site tab and, at the bottom of the document window, select Remote Web site view.) The Remote Web Site Properties dialog box appears (see Figure 13-2). If you don't see it, click the Remote Web Site Properties button on the upper right of the document window.

Before you can set all your Remote Web site details, you'll need to get the following information from your Web-hosting company or whoever is running your Web server:

  • The server address. If you're publishing to a site administered by a Web-hosting company, this is probably just your domain name (http://www.mysite.com/, for example).

  • The folder or directory in which your site should go. (If you're publishing to a server with FrontPage Server Extensions, you usually don't need to enter this info.)

  • Any user name and password you'll need to publish there.

Figure 13-2. This dialog box lets you tell FrontPage what software is on your destination server and how you want to send files there. Enter the exact destination location in the box at bottom. For example, if you've registered the domain name www.fleapower.com, you'd enter http://www.fleapower.com.

Publishing to a server with FPSE or SharePoint

If your server has FrontPage Server Extensions or SharePoint services on it, publishing is a breeze. On the Remote Web Site tab, just select the "FrontPage or SharePoint Services" radio button and enter the Web address for your site in the location box below.

Whenever possible, you should publish this way. Of course, if your site has any features that rely on Server Extensions or SharePoint, you have to publish using this option, or they won't work. But even if your site doesn't contain any of these special features, you should still use this method, if you can (that is, if the technology exists on your server). This method helps FrontPage keep track of all the info it uses to manage your site. Other publishing options will work, but they're a lot less helpful.

Your Web server can't have both FPSE and SharePoint services loaded on itonly one or the other. FrontPage lumps both methods together in the same radio button, because FrontPage communicates with both types of servers in the same way.

WebDAV

If you don't have FrontPage Server Extensions or SharePoint services installed, you may want to publish via WebDAV (Web Distributed Authoring and Versioning). WebDAV provides more control than FTP or disk-based publishing (both of which you'll read about in a moment), because it features additional controls (like document locking and version control) that let authors collaborate and edit files on a remote Web server without erasing each others' work.

FrontPage won't let you publish using WebDAV if your remote server features FPSE or SharePoint Services.

If you're publishing a personal or small business site through a Web host, you probably won't be using WebDAV. But if your site is part of a large corporate intranet, your administrator might choose this method. Publishing via WebDAV is pretty straightforward. In the Remote Web Site Properties dialog box, select WebDAV and then enter your site's URL in the "Remote Web site location" box.

FTP

FTP (File Transfer Protocol) is a relatively ancient, but still fairly dependable system for exchanging files between computers. Before Web-authoring programs like FrontPage helped with publishing, authors hand-coding HTML in text files had to publish their files using a separate program, entirely dedicated to FTP. Many Web design graybeards, as well as folks who use other Web sitecreation tools like Dreamweaver, still use FTP since it's all they really need. (See the box "FTP vs. HTTP" for more on the difference between FTP and FrontPage-specific publishing methods.)

When you select the FTP option, FrontPage asks you for a server address and provides a second field in which you need to enter a folder directory (see Figure 13-3). Before you fill out the dialog box, get this information from your Web-hosting company or whoever is running your Web server.

Also ask your host or server person whether or not you should turn on the Passive FTP checkbox. Passive FTP lets a computer communicate with a server, without requiring the server to initiate any commands. Microsoft added this feature because a lot of firewalls require it.

Once you publish via FTP or WebDAV, your site is no longer, technically speaking, a FrontPage Web site. This means you won't be able to use the "Open Remote site in FrontPage" option discussed later this tutorial (see Publishing your Site). You will, of course, still be able to edit your site using FrontPage (if your development environment is on your own computer). But the point is that the version of your site that's now up and running on an FTP or WebDAV server is no longer anything you can get at with your FrontPage tools. Also, these two publishing methods won't let you use any Web elements that rely on FPSE or SharePoint.

Figure 13-3. Note that the Web site location begins with FTP instead of HTTP. To learn more about the difference between these two systems, see the box"FTP vs. HTTP."

FTP vs. HTTP

What's the real difference between publishing via FTP and entering an HTTP address under the FPSE/SharePoint option?

Imagine that the publishing process is like sending a delivery guy to bring your site up to the server. FTP is the courier who doesn't know anything about what's in his bag. He delivers the goods, but that's ithe doesn't share any details, and he doesn't hang out to chat about the quirky little preferences of what he's delivering. FTP is the Sergeant Schultz of Web delivery systems: it knows nothing about what it's delivering or why.

FrontPage's HTTP process, on the other hand, is a devoted, smart delivery man who anticipates your Web site's every need. He tells your remote Web server what he's delivering, where it should go, and passes on special requests from FrontPage to make sure your pages function correctly.

Since this process is built into FrontPage and works with Microsoft software on the server, it's no surprise that it's very smart about your FrontPage Web site. As you publish, this method doesn't just copy your site folder to the remote destination. It processes your site, adjusting indexes and links so they'll work in the remote location. In fact, if you compare code from the same page between your development site and your live Web server, it'll often be different. (A good reason not to use your published site as a backup.)

If a server has FPSE or SharePoint on it, always use that option to publish your siteeven if your site contains no special bells and whistles that require either of these tools.

Publishing to a disk-based site

Need to make a backup of your site? Using the publish command is the best way. If you select "File System" as your remote site, you can copy your site to another folder on your hard drive or a storage server. If you're on the move, you can even copy your site onto a CD, DVD, or any other kind of storage device.

Once you select File System in the Remote Web Site Properties dialog box, browse to or type the path. If you type in folder names that don't yet exist, FrontPage creates them. Then click OK. If the destination folder isn't already a FrontPage Web site, FrontPage asks you if you want to create a "web" (meaning "Web site") at that location. Click Yes.

Configuring Publishing Options

The basic sequence of steps involved in publishing (often called workflow) follows a consistent pattern: you publish your site, you make some more changes in your development environment, and then you need to publish again. But once most of your site's already up on the live server and you've edited only a handful of pages, you might ask yourself: why bother to replace the pages and files that haven't changed?

Fortunately, FrontPage lets you publish only those pages that have changed. To do this, FrontPage compares the copies of your site and uploads only new and updated files. This process can save you loads of time.

To set your file update preferences, open the Remote Web Site Properties dialog box and click the Publishing tab. Then tell FrontPage what it should publish.

Changed Pages only

If you select this radio button, FrontPage will push only new material up to the destination site. How does FrontPage tell what's new? In one of two ways, which you choose, in the Publishing tab's Changes section:

  • Determine changes by comparing source and destination sites. FrontPage compares actual site content. This method is the more accurate of the two, though it takes a little longer.

  • Use source file timestamps to determine changes since last publish. This process compares time and date information on each file and uploads only those whose edited time is later than the existing file. This method is more prone to error because timestamps on various machines are not always consistent or accurate.

Selecting "Changed Pages only" is the only publishing method in which FrontPage prompts you to delete any files that exist on your remote site, but not in your local site.

All pages, overwriting pages already on destination

If you select the "All pages" radio button, FrontPage copies over all the files in your site, both old and new. You won't need to wait around for FrontPage to compare the sites, but you may wait quite a while for the site to publish. Obviously, the first time you publish, you'll need to publish all pages. After that, you can opt to publish changed pages only, if you want.

If you've created subsites (Planning your Website Structure) within your site, you'll need to publish them separatelyunless you turn on the Include Subsites checkbox on the Publishing tab.