Je viens de mettre un site en ligne chez 1and1 et pour une raison infecte et mystérieuse les racines de DOCUMENT_ROOT et realpath() ne sont pas les mêmes !! En effet, il manque un niveau au chemin retourné par realpath(). C'est totalement pénible et illogique alors voici un bout de code pour arranger ça (des fois que ça arrive à d'autres) :

function myrealpath($path)
{
	$real = realpath($path);
	$root = $_SERVER['DOCUMENT_ROOT'];

	$root_len = strlen($root);

	if (substr($real, 0, $root_len) != ($root))
	{
		$parts = explode(DIRECTORY_SEPARATOR, $real);
		
		$pos = strpos($root, DIRECTORY_SEPARATOR . $parts[1] . DIRECTORY_SEPARATOR, 0);
		
		if ($pos)
		{
			$real = substr($root, 0, $pos) . $real;
		}
	}
	
	return $real;
}

Ce qui donne (pour le site):
au lieu de :
Cela correspond donc bien à la racine:
Voilà. C'est tout pourrit mais ça peut être utile

realpath() résout tous les liens symboliques, et remplace toutes les références /./, /../ et / de path puis retourne le chemin canonique absolu ainsi trouvé. Le résultat ne contient aucun lien symbolique, /./ ou /../.

Il est fort probable que ton DOCUMENT_ROOT et ton realpath() représentent les mêmes chemins mais avec un lien symbolique /kunden => / ou bien /kunden/homepages => /homepages
Donc même si les deux chemins ne sont pas identiques, ce n'est pas catastrophique…

Ben c'est catastrophique pour moi qui utilise très souvent la chaine DOCUMENT_ROOT pour récupérer l'URL d'une adresse absolue... ici l'URL par rapport au chemin réel et la racine du site.

Ce problème est apparut en demandant l'interprétation des script PHP par la version 5. Ici (chez 1and1) avec la directive suivante : AddType x-mapp-php5 .php

Je pense que 1and1 utilise une vilaine redirection tout moche. Il n'y a qu'a voir le tableau $_SERVER pour voir le bordel qu'ils mettent dedans. Moi qui migrait tous mes sites de OVH vers 1and1, je vais y réfléchir à deux fois...

Mais justement, utiliser DOCUMENT_ROOT peut être très bien en local où tu as tes fichiers dans C:/www, pas de problème : mais sur des serveurs mutualisés, il faut bien se douter que tout ça est subdivisé et que cette variable d'environnement n'est peut-être pas la plus appropriée. Si tu veux avoir des chemins relatifs à partir de la racine de ton site, alors utilises simplement "/chemin/vers/la/ou/est/ton/fichier.php" le premier "/" (surtout pas précédé d'un point) étant la racine de ton site correspondant à $_SERVER['HTTP_HOST'].

Hmpf. Je ne sais pas quoi penser de tout ça. Après tout DOCUMENT_ROOT et real_path() fonctionnent correctement chez les hébergeurs que je connais (infomaniak, ovh, 1and1, free). C'est seulement parce que j'ai demandé l'interprétation des fichiers par la version 5 de PHP que j'ai rencontré ce problème chez 1and1.

Je ne travaillant que sur des serveurs mutualisés, et pourtant je n'ai jamais rencontré ce problème. De toute façon je ne vois pas le rapport avec le fait qu'il soit mutualisé ou non. Si DOCUMENT_ROOT est la base de notre site alors relapath('./') devrait au moins renvoyer la même base. A moins qu'une particularité infecte et mystérieuse ne me dépasse...

Pour référence, le tableau associatif $_SERVER:

Array
(
    [CONTENT_LENGTH] => 361
    [CONTENT_TYPE] => multipart/form-data; boundary=---------------------------8050578221329
    [DBENTRY] => /kunden/homepages/19/d200146652/htdocs:d0000#CPU 6 #MEM 10240 #CGI 18 #NPROC 12 #TAID 44671331 #WERB 0 #LANG 2 #STAT 1
    [DOCUMENT_ROOT] => /kunden/homepages/19/d200146652/htdocs
    [HTTP_ACCEPT] => text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png;q=0.5
    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [HTTP_ACCEPT_ENCODING] => gzip,deflate
    [HTTP_ACCEPT_LANGUAGE] => fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
    [HTTP_CONNECTION] => keep-alive
    [HTTP_COOKIE] => PHPSESSID=fa43c7bf111f679fbe23442d74c0e0bd
    [HTTP_HOST] => www.sideralsante.fr
    [HTTP_KEEP_ALIVE] => 300
    [HTTP_REFERER] => http://www.sideralsante.fr/wd/wdpublisher/
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
    [PATH] => /bin:/usr/bin
    [REDIRECT_DBENTRY] => /kunden/homepages/19/d200146652/htdocs:d0000#CPU 6 #MEM 10240 #CGI 18 #NPROC 12 #TAID 44671331 #WERB 0 #LANG 2 #STAT 1
    [REDIRECT_MAGIC_QUOTES] => 0
    [REDIRECT_PHP_VER] => 5
    [REDIRECT_REDIRECT_DBENTRY] => /kunden/homepages/19/d200146652/htdocs:d0000#CPU 6 #MEM 10240 #CGI 18 #NPROC 12 #TAID 44671331 #WERB 0 #LANG 2 #STAT 1
    [REDIRECT_REDIRECT_MAGIC_QUOTES] => 0
    [REDIRECT_REDIRECT_PHP_VER] => 5
    [REDIRECT_REDIRECT_SCRIPT_URI] => http://www.sideralsante.fr/wd/wdpublisher/
    [REDIRECT_REDIRECT_SCRIPT_URL] => /wd/wdpublisher/
    [REDIRECT_REDIRECT_STATUS] => 200
    [REDIRECT_REDIRECT_UNIQUE_ID] => R0HATNTjco8AAELo4lg
    [REDIRECT_SCRIPT_URI] => http://www.sideralsante.fr/wd/wdpublisher/
    [REDIRECT_SCRIPT_URL] => /wd/wdpublisher/
    [REDIRECT_STATUS] => 200
    [REDIRECT_UNIQUE_ID] => R0HATNTjco8AAELo4lg
    [REDIRECT_URL] => /wd/wdpublisher/index.php
    [REMOTE_ADDR] => 84.101.140.154
    [REMOTE_PORT] => 50937
    [SCRIPT_FILENAME] => /homepages/19/d200146652/htdocs/wd/wdpublisher/index.php
    [SCRIPT_URI] => http://www.sideralsante.fr/wd/wdpublisher/
    [SCRIPT_URL] => /wd/wdpublisher/
    [SERVER_ADDR] => 87.106.114.76
    [SERVER_ADMIN] => [email protected]
    [SERVER_NAME] => sideralsante.fr
    [SERVER_PORT] => 80
    [SERVER_SIGNATURE] => 
    [SERVER_SOFTWARE] => Apache/1.3.33 (Unix)
    [UNIQUE_ID] => R0HATNTjco8AAELo4lg
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => POST
    [QUERY_STRING] => 
    [REQUEST_URI] => /wd/wdpublisher/
    [SCRIPT_NAME] => /wd/wdpublisher/index.php
    [STATUS] => 200
    [ORIG_SCRIPT_FILENAME] => /kunden/homepages/19/d200146652/htdocs/wd/wdpublisher/index.php
    [ORIG_PATH_INFO] => /wd/wdpublisher/index.php
    [ORIG_PATH_TRANSLATED] => /kunden/homepages/19/d200146652/htdocs/wd/wdpublisher/index.php
    [ORIG_SCRIPT_NAME] => /wd/wdpublisher/index.php
    [PHP_SELF] => /wd/wdpublisher/index.php
    [REQUEST_TIME] => 1195491404
    [argv] => Array
        (
        )

    [argc] => 0
)

Si tu es en PHP5, tu peux utiliser une des constantes magiques.

Sur ta page index (à la racine de ton site s'entend), crées ceci:

<?php
define("RACINE", realpath(dirname(__FILE__)));
//...
?>

Et remplace partout ton $_SERVER['DOCUMENT_ROOT'] par RACINE. Le problème sera résolu en deux temps trois mouvements

Ca a l'air sexy, mais ça ne marche pas non plus :
Il manque toujours le '/kunden/'...

A noter que les fichiers '/homepages/19/d200146652/htdocs/wd/wdpublisher/admin/welcome.php' et '/kunden/homepages/19/d200146652/htdocs/wd/wdpublisher/admin/welcome.php' sont tous les deux valides.

Comment ça ça ne marche pas ? L'idée, c'est de pouvoir construire des chemins absolus par rapport à a position de ton fichier index. Si avec ou sans le répertoire de base "kunden/" ça reste valide, alors ça devrait fonctionner...

Si je trouve 5mn ce soir, je ferai des tests en ligne sur 1&1, c'est quand même bizarre ton truc.

À vue de nez, je dirais qu'il y a simplement un lien symbolique /homepages -> /kunden/homepages.
Le document_root est défini dans Apache "à la main" donc ils mettent bien ce qu'ils veulent en valeur, mais realpath résolvant les liens symboliques, on a le VRAI chemin.

À vérifier bien sûr, mais ça me saute aux yeux.


Note : dirname(__FILE__) donne déjà un chemin absolu, appeler realpath() au-dessus n'est donc pas nécessaire.

@Cyrano: Si tu teste le code chez 1and1, n'oublie pas de demander l'interprétation par PHP5 en mettant "AddType x-mapp-php5 .php" dans un fichier .htaccess

Tu peux également donner l'extension .php5 à tes fichiers

Tu peux également donner l'extension .php5 à tes fichiers

Pas nécessaire sur 1&1 avec l'ajout de la ligne mentionnée, ligne qu'on trouve normalement dans le fichier de configuration de Apache mais qu'on doit mettre dans un .htaccess et dans ce cas le PHP utilisé sera bien PHP5.

Je sais bien, je voulais juste indiquer que, par défaut, 1&1 avait mis à disposition l'extension .php5 pour les scripts PHP5.

Après, j'avoue avoir un .htaccess à la racine de mon espace pour être en PHP4 par défaut et en PHP4 uniquement pour les fichier .php4

Personnellement, je trouverai ça totalement chiant d'avoir à changer l'extension de mes fichiers pour pouvoir disposer de quelque chose qui tombe sous le sens : un interpréteur à jour.

De toute façon, je quitte 1and1, ils ont supprimé le forfait d'entrée qui était très attractif (14€/an) par une version trois fois plus chère. Retour chez OVH donc, où l'herbe est plus verte et le serveur bien plus compétant.

Note qu'un serveur est rarement compétent en lui-même