This is a discussion on include file path problem within the PHP Language forums, part of the PHP Programming Forums category; Jerry Stuckle ha scritto: > Motosauro wrote: >> Raheem ha scritto: >>> Hello, >>> >&...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Jerry Stuckle ha scritto:
> Motosauro wrote: >> Raheem ha scritto: >>> Hello, >>> >>> I built a development version of a live website on my hosted account. >>> However the development version is having problems with finding >>> include files. After troubleshooting I was able to resolve the issue >>> by removing the ../ from the beginning of the include file path. But >>> now I am looking at making this modification hundreds of times in all >>> kinds of files. I'd like to keep the dev env similar to the live env >>> so I can port changes easily. Below is an example of working and non- >>> working include file definitions: >>> >>> working - include_once("dblib/db_con.php"); >>> non-working - include_once("../dblib/db_con.php"); >>> >>> But I dont understand why this would work in one server and not the >>> other. Is there some kind of setting in htaccess or php.ini that would >>> affect this? The dev env is running php 5.2.6. Appreciate your help. >>> >>> - Raheem >> >> >> A nice solution I use for keeping includes out of the way is to set >> two directives (they can be set in both php.ini and vhost file) >> Say your site has its root in /var/www/sitename/htdocs >> You create a dir which is: /var/www/sitename/includes >> then you set >> open_basedir('/var/www/sitename') >> And >> include_path='/var/www/sitename/includes'; >> >> So your includes cannot by any means be served on their own, since >> they are out of the directory tree served by your webserver >> Just a little bit safer >> :) >> > > You don't even need access to the php.ini file (not available at most > shared hosts). PHP can access anything on the file system your host > allows you to - and the better ones will allow you to access one level > below the web root. So you can use something like: > > include ($_SERVER['DOCUMENT_ROOT'] . '/../include/myinclude.php'); > > Assuming your document root points to /var/www/example/html, this gets > the file from /var/www/example/include. > > And if your hosting company doesn't give you access, you're probably > better off getting another hosting company, anyway. > Right: One need to remember to set (or check) the open_basedir directive I'd rather point to *include('include/myinclude.php')* though |
|
|||
|
Everyone, thanks for the comments. Jensen the live env uses
include_once("../dblib/db_con.php"). But that path does not work on the DEV env unless changed to include_once("dblib/db_con.php"). Using symlinks, I am able to get the DEV site working without modifying hundreds of references to the include files and also keep the dev and live files the same. Your fullpath suggestion makes sense but in this instance (adding functionality to a site built by someone else); changing to a fullpath syntax would require lots of code changes, which I would not be paid for, and could potentially break the site. I am leery about changing someone else's code (esp undocumented code) unless I absolutely have to. |
|
|||
|
Raheem wrote:
> Everyone, thanks for the comments. Jensen the live env uses > include_once("../dblib/db_con.php"). But that path does not work on > the DEV env unless changed to include_once("dblib/db_con.php"). Using > symlinks, I am able to get the DEV site working without modifying > hundreds of references to the include files and also keep the dev and > live files the same. Your fullpath suggestion makes sense but in this > instance (adding functionality to a site built by someone else); > changing to a fullpath syntax would require lots of code changes, > which I would not be paid for, and could potentially break the site. I > am leery about changing someone else's code (esp undocumented code) > unless I absolutely have to. > Then change your development environment to match that of the production system (that's how you should have it set up, anyway). You don't need symlinks if the two are set up the same way. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== |