|FrontPage Tips - FP Includes|
Nesting FrontPage Includes for maximum usability.
Before proceeding with this topic, it is suggested that you read a previous topic on developing your main FrontPage Includes. The previous topic is a primer for this one on Nesting FrontPage Includes.
Developing FrontPage Includes [webmasterworld.com]
Tutorial for Building FP Included Content
Now that you've developed your primary FP Includes, you can go one step further and start nesting includes for maximum usability. Let me give you an example of where nesting includes can be of benefit.
Let's say you have a medium to large size site and your navigation menus change based on the section that they are in. This type of scenario usually means that you have multiple includes, each one specific to its section within your web.
You may have a group of links in that navigation that are static, i.e.
Home ¦ About ¦ Locations ¦ Site Map ¦ Contact ¦ Legal
Instead of repeating those in each of your primary includes, you can make one include and then nest it into your primaries. Remember, FP Includes are built just like any other page. With nested includes, there are a few things you leave out. For instance, if you have a primary left hand menu that has a containing wrapper, you would not include the containing wrapper code in your nested include page. You would only place the content that is to be nested. The code in your nested include should be a continuation of the primary include.
There is one drawback to using Nested Includes. Since you are not including the containing wrapper information in the nested include, when you preview that page (the nested include) in WYSIWYG mode, you will not see any styling that is applied to that wrapper. Once nested and previewed in the primary include, all is fine. Its not a big deal, but I wanted to list the one con of using nested includes which that is the only one I can think of. ;)
Quick Tip 1
If you are as strict as I am when it comes to coding, you'll want to make sure that you bring your first opening tag up next to the
<body> tag and then bring the
</body> tag up to the last closing tag. This will ensure a seamless transition in your included code.
Quick Tip 2
If you are building pages with .asp extensions, FP will not show any
<webbot> tags at the browser level when viewing source. This is really cool as it prevents source viewers from determining whether or not it is an FP web.
If you are building pages with .htm extensions, FP will show the
<webbot> tags (startspan and endspan) in the source at the browser level.
I've not yet figured out why this occurs, but I'm happy that it does. If there is anyone out there using other extensions like .php, .jsp, .cfm, etc. and FP included content, are your
<webbot> tags showing at the browser level when viewing source?
Quick Tip 3
FP includes also work in the
[edited by: pageoneresults at 5:09 pm (utc) on Dec. 14, 2004]
Good stuff, P1R.
|If you are building pages with .htm extensions, FP will show the <webbot> tags (startspan and endspan) in the source at the browser level. |
In FP03 these, and a lot of other stuff, can be stripped out with the "Optimize HTML" tab in the publishing dialogue.
The only FP-speciific stuff I haven't been able to remove since (finally) upgrading about a month ago is the "Micorsoft Border" meta; might be because of the way I first set the sites up some years ago, haven't quite figured it out yet.
Hey, I think I've just discovered that you don't need FP extensions on the server to have this work.
<!--webbot bot="Include" U-Include="includepage.htm" TAG="BODY" -->
but it works just like a non FP site using
i.e. you can use FP includes and FTP your site to a server that doesn't have FP extensions and FP's webbot blah, blah, blah still works.
Can anyone confirm?
Sure. That's because this...
...is pulling includepage.htm as the file is served.
<!--webbot bot="Include" U-Include="includepage.htm" TAG="BODY" -->
...saves includepage.htm in every file in which it is included on your local machine. Each file is a "whole," nothing is done server side.
Likewise, whenever you change and save includepage.htm changes are written to each of the other files at the same time. (If you have a very large site a bunch of memory comes in real handy.)
Ah, that's a big help. Thanks, mate.
|...saves includepage.htm in every file in which it is included on your local machine. Each file is a "whole," nothing is done server side. |
Can you believe I've never worked locally with FrontPage?
|Likewise, whenever you change and save includepage.htm changes are written to each of the other files at the same time. (If you have a very large site a bunch of memory comes in real handy.) |
When doing this at the level I edit, which is at the browser level, changes to included content are fairly quick. In fact, I'm working on a large site now and making changes to included content. Those includes are referenced in hundreds of pages and are saving and updating in under 30 seconds. ;)
Editing at the Browser Level
IE > Tools > Internet Options > Programs > HTML Editor > Microsoft FrontPage
Right click IE Toolbar > Customize > Edit > Add
By doing the above, I can browse to any sites that I manage and make edits on the fly. Once you add the Edit button to your toolbar, editing sites is a breeze. I wear a headset so I can easily work with clients while on the phone making changes for them. Yes, it is that simple. Just the other day, I changed the look and feel of a clients site right before his eyes (about 5 minutes of work). That was fun!
Backup you say? We backup at the server level multiple times throughout the day. I bring down copies of sites at various time schedules so that I too have backups available. One of these days I might try the publishing feature of FP. ;)
P.S. You will need to have FP Extensions installed and configured so that you can edit at the browser level.
Hmm, I hear what you are saying. But the only things less reliable than PCs and software are hosting companies and servers.... so I'll keep working locally and publishing ;)
|Quick Tip 3 |
When using includes in your <head></head>, be sure to change the tag attribute as shown below...
<!--webbot bot="include" u-include="include-head.asp" [b]tag="head"[/b] -->
|Hmm, I hear what you are saying. But the only things less reliable than PCs and software are hosting companies and servers.... so I'll keep working locally and publishing ;) |
I clearly understand your concerns with the hosting issues. I have a very good working relationship with our host and trust them to perform as they have for the past 4+ years.
Not to go too far off topic. The above method of editing that I use is great for setting up a CMS. ;)
I won't tell anymore than that!
|Just the other day, I changed the look and feel of a clients site right before his eyes (about 5 minutes of work). That was fun! |
Wow! Never new you can edit at the browser level. I've worked "hot" on remote sites thru FP, but this is much hotter. Definitely going into my traveling bag o' tricks.
Ah, this explains why you prefer absolute URIs. Absolute URIs are not so convenient to use when you are doing include pages on your local copy and then publishing ;)