Posted by Marek Kilimajer on 03/07/05 01:23

dirname(__FILE__)

and then get rid of the subpath where the check is made ('/include' for
example)

Leif Gregory wrote:
> Hello Richard,
>
> Friday, March 4, 2005, 11:41:29 AM, you wrote:
> R> http://php.net/set_include_path
>
>
> Ok... Maybe I should put all this together in one e-mail so that all
> the issues can be looked at...
>
> The problem:
>
> Finding a reliable method to include files, keeping in mind the
> following:
>
> 1. The site could be moved to a completely new host which could be of
> a different OS, and/or web server software, and could either be the
> one and only site on that host (dedicated server), or could be a
> virtual host (shared server).
>
> 2. The site could remain on the same host but is required to move to a
> new path. i.e. from htdocs/mysite to htdocs/mynewsite
>
> 3. The web host may or may not allow the use of .htaccess (Some Sambar
> configurations for example).
>
> 4. The method used would not affect any other virtual hosts. Meaning,
> the method used must be independent for each virtual host.
>
> 5. The method used would not utilize a folder where other virtual
> hosts could gain access to the included file (php.ini
> include_path).
>
> 6. The method (and this is the important one IMHO) would not require
> editing "x" number of pages in a site to change some static path
> that was set on each page.
>
> 7. The method used would not require a dedicated "include" file in
> every single folder of the site that could be included because it's
> in the same folder as the page needing it, because those would all
> have to be edited to fix the path if condition 1 or 2 was met.
>
>
> Previously proposed solutions:
>
> 1. PHP.ini include_path
> This affects all virtual hosts and would require administrative
> overhead to prevent the owners of each virtual host from gaining
> access to other virtual host's include files. I suppose you could
> set it to something like: include_path="/php/includes" and have a
> separate subfolder under that for each virtual host. But since that
> folder is outside the web folder, there would have to be some
> mechanism (additional FTP account) for each person to gain access
> to their own include folder to add/edit/delete files in that
> folder. Then if the site is moved and they aren't using an
> include_path, you have to fix all your pages.
>
> 2. set_include_path
> This means if your site moves, you must edit "x" number of pages in
> the site to correct the path.
>
> 3. An include file in every directory to set the include path.
> You'd have to edit "x" number of these files to correct the path if
> the site moves. This would be much less work than the previous
> item, but it could be a lot of work on very big sites where you
> don't have shell accounts to do some scripted find/replace with.
>
> 4. Use the full URL to the file in the include statement.
> See item 2.
>
> 5. $_SERVER["DOCUMENT_ROOT"] and $_SERVER['PATH_TRANSLATED']
> Not always available or incorrect see
> mid:1778675148.20050303102623@kwikin.com
>
>
> I may have missed some things, and if I've misunderstood how something
> should work, then please let me know. I'm just looking for a more or
> less foolproof method which doesn't require fixing code if the site is
> moved. The closest I can come to it is the function I wrote but is a
> pain because you have to put it in every page where you need an
> included file. Granted, you only have to do it once, and then you're
> done and a site move wont affect it, but it's still kludgy if you ask
> me.
>
> *******************
> <?php
> function dynRoot()
> {
> $levels = substr_count($_SERVER['PHP_SELF'],"/");
>
> for ($i=0; $i < $levels - 1; $i++)
> {
> $relativeDir .= "../";
> }
>
> return $relativeDir;
> }
> ?>
> *******************
>
> and then calling it as such:
>
> include(dynRoot() . 'includes/db_connect.php');
>
>
> I've had to move client sites between Sambar, Apache, IIS and Windows,
> Linux. Most times I've had to go in and fix include paths because one
> of the above solutions were originally used and wasn't viable on the
> new host.
>
> Thanks.
>
>

[Back to original message]