This is a nice idea, but technically not that easy. config.php is 
loaded before registry.php, so the method would have to be moved to 
config.php, but this file is automatically generated and should not 
contain any functions. We can't move the function to the Registry 
class either, since the webroot detection relies on the filesystem 
path of the current file, and Registry.php can be at different 
locations related to the horde root directory.

But any ideas how to solve this issue are welcome.

What about making $conf['cookie']['path'] in conf.php use the same 
directory detected by _detect_webroot() ?

If your asking how to fix your webroot setting for *your* 
installation, you can simply set the $webroot variable to what you 
know it should be. (/horde by the looks of it for you).

I'm still unable to comprehend what I am supposed to do here.  This is 
what the beginning of my /horde/config/registry.php file looks like.   
I get the URL trying to duplicate itself 
(/horde/kronolith/month.php/horde/kronolith/month.php) on any 
add/update within Turba & Kronolith.  These are the 2 apps that we 
utilize within the groupware.  Server is running PHP4 as CGI. Can 
anyone tell me what to change in here to get this corrected?  Sorry 
for my ignorance on this, but I simply don't know much about this 
stuff and what to do with those files attached above.  Thank you for 
anyone that can help me.

Joely



if (isset($_SERVER['PHP_SELF'])) {

     $webroot = preg_split(';/;', $_SERVER['PHP_SELF'], 2, 
PREG_SPLIT_NO_EMPTY);

     $webroot = strstr(dirname(__FILE__), DIRECTORY_SEPARATOR . 
array_shift($webroot));

     if ($webroot !== false) {

         $webroot = preg_replace(array('/\\\\/', ';/config$;'), 
array('/', ''), $webroot);

     } elseif ($webroot === false) {

         $webroot = '';

     } else {

         $webroot = '/horde';

     }

} else {

     $webroot = '/horde';

}



$this->applications['horde'] = array(

     'fileroot' => dirname(__FILE__) . '/..',

     'webroot' => $webroot,

     'initial_page' => 'login.php',

     'name' => _("Horde"),

     'status' => 'active',

     'templates' => dirname(__FILE__) . '/../templates',

     'provides' => 'horde'

);

We're upgrading from Horde 3.0.4 to 3.1.4 - the webroot detection 
doesn't work for us in either version:



Webroot: /webmail/webroot.php

__FILE__: /appl/webmail/horde/webroot.php

$_SERVER['SCRIPT_URL']: not set

$_SERVER['SCRIPT_NAME']: /webmail/webroot.php

$_SERVER['PHP_SELF']: /webmail/webroot.php



Our apache setup is done this way:

   Alias /webmail /appl/webmail/horde

After upgrade from 3.1.3 to 3.1.4 webroot detection on my system does 
not work anymore. Login screen loops constantly to 
http://mail.example.com/index.php/login.php



webroot.php script results from root and config Horde directories:



URL: http://mail.example.com/webroot.php



Webroot:

__FILE__: /var/www/html/horde/webroot.php

$_SERVER['SCRIPT_URL']: not set

$_SERVER['SCRIPT_NAME']: /webroot.php

$_SERVER['PHP_SELF']: /webroot.php



URL: http://mail.example.com/config/webroot.php



Webroot: /config

__FILE__: /var/www/html/horde/config/webroot.php

$_SERVER['SCRIPT_URL']: not set

$_SERVER['SCRIPT_NAME']: /config/webroot.php

$_SERVER['PHP_SELF']: /config/webroot.php



mail.example.com configured as virtual host of DocumentRoot 
/var/www/html/horde



Apache 2.2.4/PHP 5.1.6

Hey Guys,

the patch v3 doesn't work for my installation. Waht could be wrong?



     *  Webroot: /config

     * __FILE__: /srv/www/htdocs/horde/config/webroot.php

     * $_SERVER['SCRIPT_URL']: not set

     * $_SERVER['SCRIPT_NAME']: /config/webroot.php

     * $_SERVER['PHP_SELF']: /config/webroot.php

Unfortunately even after following the directions provided here I am 
still unable to get this to work in my personal installation and I 
would really like to.  I am on a Windows 2003 Standard Edition web 
server with PHP 5.2.1 running as a CGI .exe, you can go to 
http://wiki.spencerteck.com/phpinfo.php for details on my PHP 
installation to see if I am missing something there.  For an example 
of exactly what is happening you can go to 
http://webmail.spencerteck.com and you will see how the page redirects 
on me there.  You can go to 
http://webmail.spencerteck.com/config/webroot.php for the webroot 
output which I will leave up as well.  Any help or direction will be 
greatly appreciated as I have always been a fan of Horde Webmail but 
can't seem to get this to work on a Windows server with IIS 6.0.   
Thank you everyone.

After consulting with Jan, I'm closing this ticket.  All test cases 
that have been raised now pass the webroot test.



If someone has an issue with the way webroot is working, please post 
here and if necessary we will reopen this ticket to investigate.

     *  Webroot: /horde

     * __FILE__: /srv/www/poczta2/horde/webroot.php

     * $_SERVER['SCRIPT_URL']: not set

     * $_SERVER['SCRIPT_NAME']: /horde/webroot.php

     * $_SERVER['PHP_SELF']: /horde/webroot.php

php-4.3.9

Apache/2.0.52 (CentOS)

horde-3.1.4

Works fine too, added to the unit test though, just to be sure.

Both covered with my recent fix, thanks.

Test case output from my MacBook:

     *  Webroot: /~bklang/hordehead

     * __FILE__: /Users/bklang/Sites/hordehead/webroot.php

     * $_SERVER['SCRIPT_URL']: /~bklang/hordehead/webroot.php

     * $_SERVER['SCRIPT_NAME']: /~bklang/hordehead/webroot.php

     * $_SERVER['PHP_SELF']: /~bklang/hordehead/webroot.php

Webroot:

__FILE__: /httproot/blaserblaser.ch/www/webroot.php

$_SERVER['SCRIPT_URL']: /webroot.php

$_SERVER['SCRIPT_NAME']: /webroot.php

$_SERVER['PHP_SELF']: /webroot.php



Webroot: /horde

__FILE__: /httproot/_mail/horde/webroot.php

$_SERVER['SCRIPT_URL']: /horde/webroot.php

$_SERVER['SCRIPT_NAME']: /horde/webroot.php

$_SERVER['PHP_SELF']: /horde/webroot.php



Apache 2.2.4 + PHP 5.2.2 @ Linux 2.6.21.1

And please give feedback on the output of the script attached to ticket 5322.

See bug 5322 and bug 5345 for some additional cases.

https://secure.humbapa.ch/agolution.ch/intern/whups/

works (returns 'intern')

http://bugs.agolution.ch/whups/

doesn't work (returns also 'intern' but should be '' -> I wrote that 
wrong on my last comment, sorry!)



I think it doesn't work because of this part:

if (strstr($webroot, $hordedir) === false) {

...

at this position $webroot is not set, so strstr will allways return false

Here's a new version which tries to catch the case of Horde installed 
to the base directory of the website.  It also eliminates a block of 
code which would have never been reached due to mutually exclusive 
logic.



Please test and let me know if it works in your environment.

Your latest patch treats SCRIPT_NAME, SCRIPT_URL, and PHP_SELF 
identically, even though PHP_SELF requires special handling.



I'm going to look again at your suggestion to see if there's a way to 
do what you're trying to do.

horde basedir visible (-> 'intern'):

https://secure.humbapa.ch/agolution.ch/intern/whups/

horde basedir not visible (should also be 'intern'):

http://bugs.agolution.ch/whups/



I rearanged the code because I wanted the 'is my basedir 
visible'-check on the first place. the reason was, that with your 
script, my page with the hidden basedir did not work. my modification 
returns the right basedir for both pages.
your right. I was only looking for a fast solution and did not think 
about that. :-)

I attached a new solution. it works for both of my pages.



thanks!

Can you give me an example of your webroot?  Did your modification 
make path detection work, or just avoid checks that would fail anyway?



Also, the way you reordered the checks mean that the check for 
$_SERVER['SCRIPT_URL'] and $_SERVER['SCRIPT_NAME'] will never be 
reached if $_SERVER['PHP_SELF'] is not set.  Was that intentional?  I 
don't know under what circumstances that would be true, but I do not 
see any reason why the latter should depend on the former.

the new _detect_webroot() function did not work on my setup because 
the base directory of horde was not visible in the url path.



my patch changes the order of the different detection methodes. it now 
checks first if the base directory is visible in the url.

I've gone ahead and committed this; it works okay for me. Thanks!

I am unable to replicate your errors.  Using the patch and a fresh 
from FTP copy of Horde  3.1.3 on SuSE 10.0, I tried to replicate your 
setup.



In the below environment the patch worked perfectly, unmodified.



Here is what I did.  Please point out any differences you may see 
between our installs:



[bklang@meucci:~/public_html] (pts/0)

[Sun Nov 12 20:11:16]$ ls -l

total 5138

lrwxrwxrwx   1 bklang alkaloid-admins      11 Nov 12 20:10 horde -> 
horde-3.1.3/

drwxr-x---+ 14 bklang alkaloid-admins     592 Nov 12 15:08 horde-3.1.3/

-rw-r-----+  1 bklang alkaloid-admins 5232958 Aug 17 09:30 horde-3.1.3.tar.gz

-rwxr-x---+  1 bklang alkaloid-admins   19296 Jun  9 23:41 rtti



[bklang@meucci:~/public_html] (pts/0)

[Sun Nov 12 20:11:17]$ uname -a

Linux meucci 2.6.13-15.10-default #1 Fri May 12 16:27:12 UTC 2006 i686 
i686 i386 GNU/Linux



[bklang@meucci:~/public_html] (pts/0)

[Sun Nov 12 20:11:22]$ cat /etc/SuSE-release

SUSE LINUX 10.0 (i586)

VERSION = 10.0



[bklang@meucci:~/public_html] (pts/0)

[Sun Nov 12 20:11:29]$ rpm -q apache2 apache2-mod_php4 php4

apache2-2.0.54-10.8

apache2-mod_php4-4.4.0-6.20

php4-4.4.0-6.20

... an I use php as apache module, not cgi...

Sure. The mentioned server runs with SuSE Linux 10.0, Apache 2.0.54, 
PHP 4.4.0-6.



Maybe we should make a summary on which OS/Webservers/PHP versions the 
detection is not ok (what is $webroot on theese machines?)

ch:  Would you kindly respond with your exact platform (OS and Web 
Server) with versions and the PHP version you're using?

Example, one of my test machines is OS X 10.4.7 with Apache 1.3.33 and 
PHP version 5.1.4.



Thanks.

I'm using SymLinks to the different horde versions I have on the 
Webserver and your (2nd) patch gives me "/horde/index.php" when I'm 
using /horde as URL (which is a symlink to /horde-3.2.1). And then 
it's redirecting me to /horde/index.php/login.php which is totally 
false.

The original way is the better solution for me.



(and when I'm using the same method for the cookie-path, then I can 
disable the GET sessions as in 3.1.2)...

I investigated further.  On my SuSE 10.1 box (Apache 2.2.0, PHP 5.1.2) 
the variable is named SCRIPT_NAME instead of SCRIPT_URL.  This updated 
patch checks for and will use either.

Interesting... yes I also developed this patch on my MacBook.  I'll 
take another look at my Linux servers to see if anything similar can 
be done (I'm guessing not, or else you would have already done it :) )



I still would vote to include this patch as it does make path 
detection *much* more reliable and it doesn't break anything by being 
there even on servers without access to that variable.

What webserver are you using? I only seem to have it set on my iBook 
(macos/apache 1.3.x/php 5); I also checked linux/apache 1.3.x/php 5 
and windows/apache 2.0.x/php 5.

One issue I've always had with my Horde installs has been the 
automatic path detection in config/registry.php.   Tonight I took some 
time to try to find a better solution and I believe I found it.  This 
checks for the server variable $_SERVER['SCRIPT_URL'] and bases its 
guess off that.  In my tests it is reliable in many URL rewriting 
schemes as long as the base directory of horde is still visible in the 
URL path.  It also works if Horde is installed to '/'.



In case SCRIPT_URL is not available it will still fall back to the old method.