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:[EMAIL PROTECTED]


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.



-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to