Alternatives to Server Side Includes

Other methods to get same result

[silverbytes]

I need to put a piece of repetitive code in all my pages. All pages are .htm (can't change that due to another reasons).

Now a server side include would be ok. But in that case I should rename my pages .shtml to work. Can't do that.

The question: what method allows to put a reference or line of code to insert the real code the same way a server side include does to get:

1) Easy maintainance
2) Light pages (or at least without the whole piece of long code)

Any ideas?
Library objects from Dreamweaver doesn't count (they add the code anyway in all your pages...)

Help!

[jatar_k]

what about using the standard SSI and adding this to, either, .htaccess or httpd.conf

AddHandler server-parsed .htm

then you can use SSI in .htm files
Configuring your server to permit SSI [httpd.apache.org]

you could also use php to do it and add

AddType application/x-httpd-php .htm

then use the include [ca.php.net] function

[silverbytes]

Someone told that before. Also said the overall performance of website would be affected because the parsing of each htm page.
I don't understant much but sound ugly to me...
What do you say about?
What about an iframe? is W3C accepted? would be a solution?

[edited by: tedster at 8:02 pm (utc) on June 25, 2004]
[edit reason] splice from Browsers Forum [/edit]

[jatar_k]

>> I don't understant much but sound ugly to me...

I have done it for 5 yrs and never had a problem with performance because of the server parsing each file.

[MatthewHSE]

Someone told that before. Also said the overall performance of website would be affected because the parsing of each htm page.
I don't understant much but sound ugly to me...

I have .html and .htm pages parsed for SSI. For me it makes sense because every single non-cgi page on my site needs to use an SSI. I like the .html file extension better than .shtml, which tends to shock visitors when they catch a glance at it for the first time in their address bar. So, parsing .html pages for SSI was just the logical choice.

Besides which, I think parsing for SSI only takes a couple of milliseconds. So the performance hit really is negligible for most sites.

[D_Blackwell]

I raised a similar question here: Includes [webmasterworld.com] and am still sorting out what my follow up questions need to be. While I mull it over, I've temporarily set up a couple pages each of .php, .shtml, and .htaccess for existing .html pages. There doesn't seem to be much difference in the effort required.

[Krapulator]

I think that if the only active part of the page was the SSI that the extra proccessing overhead would be practically undetectable.

[ogletree]

Add

AddType application/x-httpd-php .htm .html

to your .htaccess file and use <?php include("top.html");?> as your includes so if you decide later you need some server side stuff you can. SSI is just includes and you would have to redo all the pages just to add some php code.

[msr986]

If you don't need to parse all of your html, you can use the xbithack; Then you can choose which html pages get parsed.

Use 'XBitHack on' in your .htaccess file, then set each html file you want parsed to have user-execute permission.

The XBitHack directive controls the parsing of ordinary html documents. This directive only affects files associated with the MIME type text/html. XBitHack can take on the following values:

off - No special treatment of executable files.
on - Any text/html file that has the user-execute bit set will be treated as a server-parsed html document.

[Rhys]

I invented my own htm include workaround; I use it for the menu bar on every page on the site, so I can update site-wide with just one little edit: it goes like this-
Wherever on the page use this call -
<SCRIPT LANGUAGE="JavaScript" src="../menu.js"> </SCRIPT>
which calls a script file which has the main navigation menu written as one long line without CR's and enclosed inside this line -
document.write(" Menu written using single all 'single quotes' ");

I keep a menu2.js file with ../ additions for the next nested level, etc. In practice, I can do an entire site re-vamp in a few minutes using the css file and these menu bar files. A further advantage is that pages render faster with the reduced code content.

[tedster]

Yes, iframes are another possible solution. Watch your DTD, but they are certainly part of the W3C recommendations.

Watch out also for people arriving directly at the iframed page and having it orphaned from the parent page. Lost traffic, most of the time, so at least include some basic navigation into your main website in the iframed page.

Note that using SSI does NOT mean your pages are any lighter, because the server will write that mark-up into the file it serves any way. It just looks lighter in your development environment. Iframe code will also mean that the server needs to find a second document and serve it up. Again, no savings to the end user, although there is "some" savings for the search engine spiders.

[bruhaha]

Now a server side include would be ok. But in that case I should rename my pages .shtml to work. Can't do that

Not really a problem. In fact, you can use server side includes, without renaming your pages, by directing the server to parse .htm pages.

Simply add the following line to an .htaccess file in the root directory:
AddHandler server-parsed .htm

If you want the server to parse other file-types simply add them to the list, thus:
AddHandler server-parsed .htm .html .shtml

Note that this directive will cause the server to parse all pages of the listed type, which slows down the serving to the page a bit. If you only wish to use SSI in one subset of .htm pages, and they are within a particular directory(ies), place a copy of the suggested .htaccess file only in that directory(ies). .htm files outside those directories will not be parsed.