Re: Server Side Include translator as PHP functions
| From: | tamouse mailing lists | 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.