rocknbil - 5:57 pm on Apr 2, 2010 (gmt 0)
Well, first, consider the SEO impact.
Let's say that's indexed. If you make it a php file to include the navigation, you're going to have to do one of two things:
- add a rewrite rule with a 301 header to point from the .html to the php,
- set your server config to parse .html as php (which, although, I think is possible, I'm not even sure if it is.)
Otherwise the indexing for those pages will tank.
There is a second option, one not many seem to agree with, but comes out of the philosophy, use the right tool for the job.
PHP is a rich dynamic scripting language. It is designed to do a lot of things, like Perl or ASP, of which "includes" are really a minor asset. So IMO, converting an entire website to PHP just to use includes is overkill.
Server side includes is a technology far older than PHP that is designed to do **exactly** this: include files. Although it can do a few other things, this is what it's designed for. Most linux servers support SSI, and if they don't, it can easily be enabled. There are several up sides to this.
1. Normally files are parsed for SSI by the extension of .shtml, which would present the same problem mentioned above. You can **easily** set your server to parse .html files for SSI directives by adding this to your root .htaccess file:
AddHandler server-parsed .html
That's it, now when the server serves .html files, it will look for SSI directives. While it's true this puts more strain on the server, this is really not much of an issue today, whereas it was in the 90's. You should see little or no difference in server perfomance.
2. Even the directives are easy. There are two main directives you'd work with, virtual and file. You'd use file for includes in the same directory, virtual for includes in other directories. Example 1,
<!--#include file="your-navigation.txt" -->
Would put the content of your-navigation.txt in place of the above line. The space before --> is important.
<!--#include virtual="/my-includes-directory/your-navigation.txt" -->
3. So now, you don't have to change your extensions or worry about losing indexing for framed pages, which is, I think, the biggest advantage. You wouldn't have to make and rewrites for the framed files, but you WOULD have to add rewrite rules for the framesets themselves. An example,
<frameset rows="109,*" frameborder="0" border="0">
<frame src="navigation.html" name="nav" id="nav">
<frame src="about-us-content.html" name="content" id="content">
about-us-content.html is already indexed, no worries. But for about-us.html, in your .htaccess you'd do
RewriteRule ^\/*about-us.html$ /about-us-content.html [R=301,NC,L]
Insuring all your link juice for about-us.html is now pointing to about-us-content.html.
For nav files that are now includes (navigation.html in the above example,) you could just rewrite those to the most helpful file possible representing your previous nav - sitemap.html. :-)