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.
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>
I have never heard of this, but why would you want SSI's processed last in the first place?
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.
Well, it appears that we all misread a little bit! Sorry for steering the topic off-track. It would be perfect for doing that! Kudos to you! :)