Google
 
Web smallbusinessbrief.com

View Full Version : New Article - Simple Server Side Includes Tutorial


thejenn
10th May 2005, 03:18 PM
Full Text: http://www.searchengineguide.com/claiborne/2005/0510_sc1.html

Some Snippets:

"An easy way to manage pages in your site is by replacing chunks of repeating code, such as your navigation links, with server side include (SSI) files."

"SSI files can simplify the maintenance of your site. Information that may change from time to time or that replicates across many pages can be replaced with SSI files. Then, when you alter that include file, every page on your website changes where the included file is being read. "

Mel
16th May 2005, 05:45 AM
This is always a great idea to implement in a new site, but changing all the page names in an old site (especially a large site) can be a pain, and it can create another problem in that the changed page names will be seen by the search engines as new pages and your rankings and traffic will drop until the newly renamed pages are indexed and ranking.

Since I always host on Unix servers I prefer to add a snippet to the .htaccess file which allows the nomal .htm or .html pages to be parsed for php includes.

Once you find the .htaccess file in your root directory (you may have to use the -a paramenter in some FTP programs like WS-FTP to see the .htaccess file as it is normally a hidden file) just add a space at the bottom of the file and then add:

RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html
AddHandler server-parsed .htm
AddHandler server-parsed .html

Save your modified file back to the root directory again, and your php includes will be parsed without the need to change your page extensions.

gilmorejay
16th May 2005, 09:16 AM
Jenn,

I do agree that since using server side scripting to include is the best way to manage all sorts of repeated data. My new site is going to be PHP from the start for two reasons. One is to handle the repeated information like the navigation, header, and footer information. The other is that in the near future I will be adding a MYSQL database for articles and searching facililty.

There were several minor errors and omissions in the article. One is that SSI is a separate command directive that runs on web servers such as Apache and uses CGI to complete other tasks. As the author pointed out, you can use scripts to call server parsed INCLUDES on a page load. The most common languages for this use today are PHP and ASP as indicated.

In addition, it was not made clear that you only need to rename and name new files as .php and .asp when they contain includes or a scripted command in either of this language. The example "header.php" can just as easily be "header.html" or "header.htm" so long as it doesn't contain additional includes or php/asp commands. It is not a good idea to name files not containing php as .php because they will need to be processed separately by the php processor. This will unnecessarily increase load on the web server.

On the comment by Mel. Yes you can do this, but if I am not mistaken, this will cause every single page on the site to be parsed whether it has any embedded scripts and commands or not. Yes, it will save you from the fact of losing Search Engine Positioning which is very important but if you have a huge site on an older server you might be setting yourself up to bog down the server and running into timeouts and slow page loads. If you are building a new site start it out right and use the right extensions from the get-go.

Please note, I am not a php/MYSQL programmer. I have a very basic knowledge of these languages and would recommend checking out goggle for other resources. I do feel that this is an extremely important article though as it highlights one of the best ways ease management of both simple sites and complex e-commerce sites.

Best to all.

Sincerely,

Jay
Developer/Consultant

StupidScript
17th May 2005, 07:47 PM
Server-side includes are an excellent way to re-use code, manage global site changes and more. Most of you already use them in the form of <link 'd style sheets and <script ... src=

Imagine a 500-page site. You need to change the copyright date on each page.

Without using SSI of some kind, you would need to open each file and change the date either with search-and-replace or manually. This would also update the last-modified date, causing some changes in the way certain search engines rank the pages. Then you'd re-upload the entire site.

Using SSI, you would open the included "footer" page, make the date change to that file, and re-upload it (or simply make the change at the server). The "real" page's last-modified timestamp is left unchanged, as only an include has been modified.

gilmorejay, after a lot of research and performance testing, all of our Linux servers are set up to parse .html files with the PHP engine. We did this because, when we started, .php files were not treated the same as .html files by the search engines. Here's where the performance issues creep in:

1) Network speed
This is the biggest bottleneck in almost any server situation. It doesn't matter how many processors or how much RAM you have, you'll only be able to shove so much data through the pipe.

2) Processor load
This was our biggest concern with parsing .html files through PHP. Fortunatley, the Zend Accelerator and PEAR that are included with modern PHP do an excellent job of reducing the processor load by multi-threading the parsing process, reading PHP code into a separate memory space and allowing us to cache the HTML parts of the files for re-use on the next request. In effect, PHP only parses the entire .html file one time, and then only needs to parse the PHP parts of it on subsequent requests. The same is not true of .php files, which are completely parsed with each request. It's true you can cache some of the PHP stuff for re-use, but it's not nearly as clean as caching the HTML stuff.

Through benchmarking and other performance testing, we have found there to be no problem at all with running .html files through PHP on a heavily-trafficed site (~40,000 hits per hour). The biggest problem is still the network speed. (I should note that different operating systems have different levels of success. When we switched from a FreeBSD environment to a Fedora Core 1 environment we saw a 60% increase in the speed of page delivery, for example.)

Server-side includes are far too important a tool to keep off your site because you are worried about performance issues. Keep your code clean, and you should be fine.

Oh ... by the way ... in our included PHP footers, we never need to update the copyright date, because we use PHP to write it:

Copyright © 2000-<?=date("Y")?> takes care of it forever.

;)