Working with Local Web Sites

Unlike most Office System products, FrontPage offers the ability to open both individual files as well as entire Web sites, as seen in Figure 15.1. When the user wants to edit a single page, there is no need to open the entire site. If the management of hyperlinks and navigational elements is required, you will need to open the site, even if you only want to edit a single page.

Figure 15.1. The File menu option in FrontPage provides the option to open both individual files and entire sites.

Reasons for only opening a single page of HTML can range from the editing of an HTML email piece (which FrontPage designs and develops very well) to editing or modifying a single page of content, where someone else is in control of site-wide issues. A developer will not want to introduce site-wide elements to these types of projects because that might be the job of the Webmaster.

Previous versions of FrontPage required that the user run a copy of Personal Web Server (or a more powerful Web server) on his site for any serious development process. With FrontPage's introduction of the disk-based Web, sites can be opened from any folder anywhere on your hard drive. This makes the Web design and maintenance process with FrontPage considerably easier than ever before.

A majority of users will simply access and edit site content on their computer with FrontPage 2003 and publish to their Web sites as needed. This approach requires an understanding of how FrontPage handles and manages sites based on a local hard drive.

NOTE

Previous versions of FrontPage used the term Webs to describe a Web site. With the increase in Web technology, Microsoft now refers to them as sites instead of Webs. If you read documentation that makes mention of previous versions of FrontPage, you will need to keep this issue in mind. You also shouldn't be surprised if FrontPage mixes the terms in this most recent release.

The first time you open a folder as a site, FrontPage will need to add a number of elements to the folder content to enable FrontPage's site-wide maintenance capabilities, as seen in Figure 15.2.

Figure 15.2. If you open a folder with FrontPage 2003 as a site, FrontPage will require you to make the folder a site.

There is no way around this process. If you are going to view content on a site-wide basis, FrontPage must build a site of your folder and add the appropriate metadata.

TIP

Don't let FrontPage's conversion of folders into sites concern you too much. For all intents and purposes, no content is changed and you can still access the folder as you would any other folder on your computer with any other application. FrontPage merely adds the meta information required to manage that folder content as if it were an entire Web site. Without this content, site-specific data such as navigational elements, included files, and search capabilities would be impossible.

Opening Versus Importing

Some might mistake FrontPage's Import Web Wizard (discussed in Chapter 14) with opening an existing site. They are completely different issues, and we'll discuss them both here.

FrontPage can only work with an existing FrontPage Web site. As shown previously in this chapter, if you use it to open nonFrontPage content, it will wrap a FrontPage Web site around the content and then allow you to edit it.

If the site you want to edit isn't directly accessible, you can use the FrontPage Import Web Wizard to import the site content into a FrontPage Web site that you can then update, edit, and publish at will.

It is very important to point out that just because you can import (most content from) any publicly accessible Web site using this tool, it doesn't mean that you have permission to do so. Make sure that you have permission before using this tool.

Understanding Subsites

As mentioned previously, when a site is created, FrontPage places site-specific content within hidden folders in the site (and in the folder holding the site). These folders hold security and access permissions, Web data, navigational elements, theme information, and the like.

Web design traditionally sorts site content into various folders within a site. This enables the developer to prevent a site from getting too overrun with content and provides a simple way to sort site content. An example of this can be seen in Figure 15.3.

Figure 15.3. Image, script, and ordering information in this site are stored in their own appropriately titled folders.

If the developer prefers, any folder within a site can be converted to its own site, creating what is called a subsite. In Figure 15.4, the Web site shown in Figure 15.3 has converted the Sales folder into its own subsite.

Figure 15.4. The folder called Sales from Figure 15.3 has now been converted to a subsite.

Unless security issues are set differently, visitors to a Web site won't know that they are in a subsite. To the visitor, the URL will make it appear as though he has just entered a new folder.

For more on subsites, see "Creating a Web Site," p. 251.

For more on setting access permissions to a site or subsite, see "Security and Administration of a Web Site," p. 323.

When you double-click any subsite from within FrontPage, the subsite will open in a new instance of FrontPage. If security settings require a different login and password than used to access the root site, FrontPage will require that they be entered before the site is opened.

NOTE

Because subsites are treated by FrontPage as their own entity, each subsite needs to be published on its own. Publishing a site that contains numerous subsites will not publish any subsite data each subsite will need to be individually published.

Converting Folders to Sites and Vice Versa

Converting a folder to a site is as simple as selecting the folder, right-clicking the folder, and selecting the Convert to Web option. FrontPage will confirm that this is the action you'd like to take and will warn you about its implications, as seen in Figure 15.2.

Any subsite can be right-clicked and converted back to a folder through the Convert to Web option. As per Figure 15.5, FrontPage will again warn you of the effects of this action.

Figure 15.5. When you convert a subsite back to a folder, FrontPage will warn you of the action's implications.

When to Create a Subsite Versus Using a Folder

At first, it might seem desirable to create a great number of subsites or to keep everything sorted by folders only. The most effective Web design strategy is a strategic mix of both. Because a developer can quickly change a folder back into a site and vice versa, a developer should feel free to make the changes as many times as needed.

Link Bars and Themes in Transition

If you convert a folder to a subsite or convert a subsite back to a folder, theme and link bar content will get "lost" in the translation.

If you convert a subsite back to a folder and the site containing that folder has a site-wide theme, the folder pages will also inherit that theme. If you convert a folder with theme content to a subsite, the subsite will not inherit the theme.

If you convert a subsite back to a folder that contains link bars, the nature of the bars will change considerably because there are new home and parent page structures throughout the entire site. FrontPage will handle each instance differently, so you will need to check that the site maintains the structure you were looking for.

In short, if you do change between one and the other and use either of these FrontPage technologies, never assume that FrontPage will be capable of sorting things out for you. Always double check your pages.

In short, the main reasons for creating subsites are if you need or desire separate access information to a certain area of the site or need site-wide content to be limited to a specific area. If a better organization of site content is all that's desired, folders work wonderfully.

TIP

If you are going to use any of the FrontPage site-wide capabilities, such as navigational elements, table of contents, and search, FrontPage will only navigate and present content from within that existing site. If you site is made up of multiple subsites, you won't be able to use this technology across them.

My Documents and My Web Sites

Windows 2000 and Windows XP place a My Web Sites folder within each user's My Documents folder when FrontPage 2003 is installed. The "My Web Sites" title can be a little misleading because it contains not just your Web sites, but the sites you have control over or are keeping a copy of.

By default, FrontPage will attempt to place sites within this folder. You aren't required to place them there; it only provides one standard for where sites might be located on your computer system.

This approach can create problems in Web design because if multiple people are working on the same site, they might not have access to your personal Web folders and therefore won't be able to do the work assigned to them.

Because FrontPage 2003 no longer requires a Web server for serious Web development capabilities, site content can be placed in any location on your hard drive(s) and is not required by FrontPage to be located in any specific area.

Place your Web sites in an area that makes sense to you and that can be accessed by everyone on your team.