php require directory being rewritten?

SentientParadox

This appears to be an unusual problem. I've posted this at Joomla.org and in my site host's forum and no one so far has an answer.

I have a configuration.php file that I want to move outside my public_html folder.

I've tried moving it, renaming it and replacing the original with a require function in the replacement file.

For example:

Original configuration.php resides in:

home/my_folder/public_html/mysite_folder

(It's an add-on domain)

I move the file to:

home/my_folder

and rename it:

something.ext

Then I place a new file called configuration.php in:

home/my_folder/public_html/mysite_folder

with the code:

<?php

 require( dirname( __FILE__ ) . '/home/my_folder/something.ext' );

 ?>

I have also tried the following:

<?php

 require( dirname( __FILE__ ) . '/../something.ext' );

 ?>

Both paths produce the same result. When I try to open the home page in browser I get:

Warning: require(/home/my_folder/public_html/mysitefolder/home/my_folder/something.ext) [function.require]: failed to open stream: No such file or directory in /home/my_folder/public_html/mysitefolder/configuration.php on line 2

Fatal error: require() [function.require]: Failed opening required '/home/my_folder/public_html/mysitefolder/home/my_folder/something.ext' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/my_folder/public_html/mysitefolder/configuration.php on line 2:eek:

Take a close look at the directories in the error. It seems wherever configuration.php is, the entire path above it, from home down is already being set and added on top of the directory I specified somewhere else. I've checked .htaccess, and php.ini,

There is no php.ini, and no .htaccess within "mysitefolder"

.htaccess is in public_html, but only contains server set information for my parked and redirected domains.

There is php.ini within public_html also, which I have not edited. I've only copied what I think is the relative information from it:

; All the values in the php.ini-dist file correspond to the built in
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the built in defaults will be identical).



;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"  

include_path = ".:/usr/lib/php:/usr/local/lib/php"   ;
;
; Windows: "\path1;\path2"
include_path = ".:/usr/lib/php:/usr/local/lib/php"   ;

; The root of the PHP pages, used only if nonempty.
; if PHP was not compiled with FORCE_REDIRECT, you SHOULD set doc_root
; if you are running php as a CGI under any web server (other than IIS)
; see documentation for security issues.  The alternate is to use the
; cgi.force_redirect configuration below
doc_root =

; The directory under which PHP opens the script using /~username used only
; if nonempty.
user_dir =

; Directory in which the loadable extensions (modules) reside.
extension_dir = "./"

; Whether or not to enable the dl() function.  The dl() function does NOT work
; properly in multithreaded servers, such as IIS or Zeus, and is automatically
; disabled on them.
enable_dl = On

; cgi.force_redirect is necessary to provide security running PHP as a CGI under
; most web servers.  Left undefined, PHP turns this on by default.  You can
; turn it off here AT YOUR OWN RISK
; **You CAN safely turn this off for IIS, in fact, you MUST.**
; cgi.force_redirect = 1

; if cgi.nph is enabled it will force cgi to always sent Status: 200 with
; every request.
; cgi.nph = 1

; if cgi.force_redirect is turned on, and you are not running under Apache or Netscape 
; (iPlanet) web servers, you MAY need to set an environment variable name that PHP
; will look for to know it is OK to continue execution.  Setting this variable MAY
; cause security issues, KNOW WHAT YOU ARE DOING FIRST.
; cgi.redirect_status_env = ;

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting
; this to 1 will cause PHP CGI to fix it's paths to conform to the spec.  A setting
; of zero causes PHP to behave as before.  Default is zero.  You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; cgi.fix_pathinfo=0

; FastCGI under IIS (on WINNT based OS) supports the ability to impersonate
; security tokens of the calling client.  This allows IIS to define the
; security context that the request runs under.  mod_fastcgi under Apache
; does not currently support this feature (03/17/2002)
; Set to 1 if running under IIS.  Default is zero.
; fastcgi.impersonate = 1;

; cgi.rfc2616_headers configuration option tells PHP what type of headers to
; use when sending HTTP response code. If it's set 0 PHP sends Status: header that
; is supported by Apache. When this option is set to 1 PHP will send
; RFC2616 compliant header.
; Default is zero.
;cgi.rfc2616_headers = 0

Host is currently running:

Apache version 1.3.37 (Unix)
PHP version 5.1.6

What can I do to ensure that apache(?) is looking at the specified directory as absolute instead of relative?

Does it have anything to do with "include_path" in php.ini?

I'm guessing I may need to alter either php.ini, or .htaccess, but no idea what would need to place in them, or maybe I need to contact the host about this.

Any help would be greatly appreciated!😉

bpat1434

Try doing:

<?php
$file = realpath(dirname(__FILE__).'/../../something.ext'));
require_once($file);
?>

Your path logic was wrong.
/home/<username>/public_html/mysite/configuration.php
./ is the "mysite" folder
../ is the "public_html" folder
../../ is the "<username>" folder.

So when you want to require a file outside of the document root, you need to take the current file's directory name (dirname(FILE)) which would be "mysite" and go up 2 levels to get to the "<username>" directory. Then look for configuration.ext in there.

If that doesn't work, try echoing out the $path variable...

SentientParadox

Thanks bpat1434,

Your explanation was much better than others I got. At least, it was easier for me to understand.🙂

I get now that "/../" means "look up", whereas before I though each "/../" was just a generic replacement of the actual directories that caused a different effect:rolleyes:

This did work fine. I would like to understand this a little better though, if you or anyone else would be willing to explain it a bit more.

What exactly would be causing the directory I wrote in to have the file's relative path added to the code that is in it?

Thanks a bunch!

bpat1434

Well, if you look at your error code from your original code:

Fatal error: require() [function.require]: Failed opening required '[color=red]/home/my_folder/public_html/mysitefolder/home/my_folder/something.ext[/color]' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/my_folder/public_html/mysitefolder/configuration.php on line 2

Take a look at the line in red. Notice how you have two "/home/myfolder/" items? Now, if you go to /home/my_folder/public_html do you have subfolder called "home" inside of it?

PHP can't write to any place that isn't accessible. Meaning that if the directory isn't present (or doesn't allow permission for PHP to write to it), PHP can't write to it. For example in Windows (I'm guessing you're using Windows if you're having trouble with paths like this) you tried to browse to "C:\Windows\system32\Windows\SysWOW64" (it's a 64-bit OS only folder) Windows would error stating that it can't find the destination. Same goes for linux. You can't write or read from something that isn't there. So while you thought "../" would put you at home, you misinterpreted what the "../" means.

So just for your info:
./ means "the current directory"
../ means "the directory above current directory"

[man]realpath[/man] will expand the ".." and "." in paths so "/home/my_site/public_html/mysite/../../" will become "/home/my_site/"

[man]dirname[/man] will get the directory name of the file that's passed to it. FILE is a super-global that references the currently executing file. So it would be "mysite" in this example.

I hope that helps. I'm sure it doesn't "clear" things up, but paths aren't really something to learn from a book, more of something you learn by doing and doing a lot of.

If you can play with Linux via SSH or via GUI, I'd suggest you do for a bit since you can run the commands cd (change directory) ../../../ to see where you go. Sometimes it's a trial and error thing as you first start out. But after a few weeks it becomes second nature.

SentientParadox

Thanks. Good explanation. The directories are all fine.

I have actually traced the problem, and it turns out this doesn't even belong in this forum. It should be in php. I put it in here because I thought there was something going on behind the scenes in my hosting environment.

I am now in the process of installing and configuring xampp for windows so I can test off line.

While installing and configuring, I encountered a similar, directory related problem.

I now realize I should have mentioned that my site is Joomla powered. What I've been looking for is in configuration.php with the $mosConfig_absolute_path statement.

I'll bet you'll be able to help with a different problem I'm having regarding the migration to test environment, but I'm going to put that one in the right forum (I think). under misc. tools. Thanks

SentientParadox

SentientParadox wrote:
I'll bet you'll be able to help with a different problem I'm having regarding the migration to test environment, but I'm going to put that one in the right forum (I think). under misc. tools. Thanks

Turns out the solution to the first problem became (in a kind of convolute way) the solution to the second problem.

I had just installed a local copy of my live Joomla site into a Xampp installation on a LAN drive. Using some of the information you gave me, I got the site up a running on the host computer, but couldn't get full access from a LAN computer. All I could manage to access was the home page, which was screwed up. No template, and no links worked.

I finally realized the problem was in the same $mosConfig_absolute_path statement.

$mosConfig_absolute_path = 'localhost/my

bradgrafelman

Don't forget to mark this thread resolved.