The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

My understanding is that server side includes are always processed first, however, I recently learned a way around this. I read an article that said if you needed an SSI processed last, use the include as js source file.

Code:

<Script Language=JavaScript src="someInclude.asp"></Script>

Your file include is called from the browser lastly. If the file's extension ends with asp, php, or cfm, it will be processed by its respective server.

Has anyone used this method?
<Edited by westmich on 01-26-2001 at 03:59 PM>

Firstly, SSI's are processed FIRST in a script. If they don't, they're broken. All SSI does is stick a text file's contents into the document. That is why it is unwise to have server-side script (i.e ASP) running in them. SSI's process first. Perhaps this was your problem?

The solution does sound plausible, but I would make sure SSI works before I check anything else. It really IS the best way.

I realize that the server spits out the SSI as plain text regardless of file extension. However, it is a good coding practice to name your includes with your respective server-side language for a couple of reasons. First, it helps to avoid confusion with larger sites and numerous pages. Second, it is a security measure. If you named your includes with .html or .inc, as some do, and someone discovered your URL, they could open the include and view the source. Whereas, if name it with .asp, .cfm, or .php, the server will process it first and then send the resulting text to the browser.

The 'trick' that I mentioned isn't really a server include. It a way of achieving the same affect, but having it happen last.

If I remember correctly someone had posted a question about wanting to use a certain include if A happened or a different include if B happened. Using this 'trick', they would be able to do just that.