I'm not sure if this only applies to ASP/SSI, but IIS6 (not sure about 7) does have a "parent paths" option. If you select your websites and go to the Scripts Configuration menu, under the options tab "Enable Parent Paths" is an option.

Hope that helps

>> I do them relative because the site runs locally on a subdir, not the domain root like the live server

Isn't this where your problem lies. You are keeping the scripts in two different locations with the same paths to the files. For your live site you might be going below the webroot to grab the include files, as with the local server you are going into the root directory.

For portability purposes, I could have a config file prepended to a script like this. Maybe it would look like the following:

if(stristr($_SERVER['HTTP_HOST'], 'local') ¦¦ (substr($_SERVER['HTTP_HOST'], 0, 7) == '192.168')) {
# local server
ini_set('include_path', '/dir/includes');
} else {
# live server
ini_set('include_path', '/includes');
}

or something along those lines. This way, you don't have to use anything more than just:

include('script.php');

eelix, the site has been built from day #1 in this environment; I always wanted it to be easily portable. The point is, it has worked, and continues to work, just 100% fine, on both my old IIS set-up and the current live Apache set-up. It's entirely independent of where it's running.

(The only calls are in sub-dirs from the root. It never goes below the root then back out. See examples above.)

Therefore, I am unwilling to make any changes to the site. I appreciate your code is a quick fix (although, I think like include_path in php.ini it also will NOT fix the real problem which is with fopen()...!). Because it works fine on other servers, it has to be a config thing... which is why I'm looking for such a solution.

Like npwsol's suggestion - although I'm afraid I can't find anything like "enable parent paths" in IIS7. Not even scripts configuration LOL. Nothing in its help either.

I have tested the site by copying it to c:\wwwroot\site, and hey whadya know? localhost/site now works fine.

So this is an issue with the application virtual path set-up. I have just wasted hours on Google and can't find any solutions. A few other sites that don't use relative paths work fine, also in virtual directories, so it's something to do with what IIS is showing PHP...

Note that above /site is still in a subdirectory, just it's real path is below wwwroot instead of a virtual path referencing another location. So the above discussion was a bit of a red herring. PHP and the script is working A-OK...

So any more ideas?

I have just made a new thread over in the IIS forum, so maybe this should direct there now.
[webmasterworld.com...]

This might be a Vista permissions issue (or not).

I set up Apache and an FTP server for development here, and if I FTP stuff into the www folder under Apache, it does not appear there.

It gets dumped to C:/blah/blah/Application Data/Apache/blah/blah/ or somesuch, as Vista will not me put user data into a folder that is seen as being an application.

.

I also met a similar problem to yours, with PHP, with my development vs. real server. In the end I specify the PHP Include path using this php_value include_path in the .htaccess file for the site. I leave both lines in there and comment one out, depending on where the file is destined for. That's also not ideal, but it works for me.

Yeah me too but it only covers includes, not other file references like fopen().

Permissions are all okay as far as I can tell - because a simple site will work fine in the same virtual dir [application] (and I can see other pages of the site, just not the main pages that use includes etc...

Okay I solved the fopen() problem, I had assumed it was related but apparently not!
(Permissions on hostAdmin.config).

BUT includes still fail.

The site works PERFECTLY in a subdir... i.e. if it locally located in wwwroot/site, then localhost/site accesses it just fine. But if it's an application [virtual dir] called 'site', then localhost/site fails with 'no such file' errors.

Anyone got any ideas?

I had the same problem with relative paths under IIS7 and PHP5. When I moved my app under wwwroot/ subdir, then relative paths did work. However, if I used different folder for my app, the relative paths didn't work.

After wasting several hours, trying to debug my app, I decided to try to check the current working directory of the php script in app root folder. I used the code sample from php manual (see dir()), then executed this peace of code from my app root folder. It gave out the list of files (exe, dlls...) from some windows/system32 subfolder (apparently IIS files in it). When I tried to put this script into the wwwroot folder and execute it, I got the expected list of files in the wwwroot. It was clear, that relative paths didn't work due to the different working directories.

I've made comparison of my app and wwwroot folder NTFS permissions and it turned out, that wwwroot had Users group assigned with read&execute and list folder permissions. My app root folder lacked this group. After giving the same permissions for Users group to my app root folder, relative paths started to work.

Don't know why, but apparently IIS7 needs this group assigned, to have set the proper working directory of the script. Anyway, my suggestion is to verify that Users group is assigned to your app folder with read, execute and list files permissions set.

Thanks Andrew. I just copied the site back to its original location, and made a new application, and tried adding Users. However it made no difference. Includes just don't work.

I believe I ensured permissions were identical on both locations before. For the time being I've given up, and am just running the site under wwwroot. I cannot believe that IIS7 is this bad, this difficult to set up for a simple PHP site! It's quite incredible.

I might see what dir() tells me.

In my case I used PHP 5.2.6 configured as ISAPI. What version do you use?

Found out, that there is simpler method to check working directory:
<?php echo getcwd(); ?>

I'm using the x64 compile of 5.2.5 via ISAPI also.

getcwd() gives a system32 subdir for me too:

c:\windows\system32\inetsrv

This is so retarded. I'm back to being unsure where the problem is, IIS or PHP?

I ran into this problem, too; giving the anonymous IIS user permissions to the parent directory fixed it.

I had a phpBB installation in "/wwwroot/phpBB/", with the user with read and execute permissions given permissions to directory. The pages in the/phpBB/admin/ directory worked correctly, but the pages in the root didn't. Giving the phpBB user read permissions to the /wwwroot/ directory fixed the problem.