Re: Server Side Include translator as PHP functions

From: Date: Wed, 12 Oct 2011 04:23:42 +0000
Subject: Re: Server Side Include translator as PHP functions
References: 1 2 3 4 5 6 7 8 9  Groups: php.general 
Request: Send a blank email to php-general+get-315246@lists.php.net to get a copy of this message
On Sun, Oct 9, 2011 at 12:36 PM, Tedd Sperling <tedd.sperling@gmail.com> wrote: > On Oct 9, 2011, at 11:41 AM, Complex wrote: > >> Tedd, >> >> The crucial detail you're lookign for is my lack of choice or control >> in the matter, for all sorts of reasons that are actually quite stupid >> but not possible for *me* to change, and not possible for anyone else >> to change quickly. Thus I am looking for a solution to the problem at >> hand, instead of a suggestion for what the entire org should be doing >> instead. I know what they should be doing instead, but that's not my >> decision. It's not like I'm building a new website this way; I'm >> trying to move forwards with an existing and large website. The more >> different code-bases we have for different parts of the site, the >> harder it will be to actually change to something else (PHP-based, I >> pray). >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > Without debating the question of choice, if I was confronted with a large web site that used > SSI, I would inform the client of such and put together a bid as to my time to bring the site up to > date. If not, then I think I would pass on working the site. In my experience, it's not worth > my additional time to try to work around "out of date" technologies. > > It is also been my experience that when I am confronted with something large scale, and when > approved by the client, I simply do a site-wide find and replace (namely change > "<!--#include" to "<?php include") and then evaluate all occurrences prior > to changing. That usually gives me a good idea of the breath of the problem. > > In addition, considering the "<!--#include" has basically the same purpose as > "<?php include", while it may be a wide-spread problem, I do not see it as a serious > problem to address. Certainly, when including files that have a different suffix ".shtml" > as compared to ".php" you will find that the Server will treat them differently but > that's pretty easy to fix -- just change the files suffix or possibility write code in a > .httacess file that would cause the interpreter to consider shtml files the same a php. > > Of course, I may not fully understand the problem. Of course, if it was just mapping includes, that would be too simple to require much of a general solution. However SSI is more than just includes. That's where it gets interesting.

« previous php.general (#315246) next »