Bonjour *
L'article est intéressant mais n aborde que l'OS file system desktop mais pas le file system server avec php et CMS ni le protocole http et encore moins comment les navigateurs se comportent selon le type de path /URL et protocole !!.
http://www.alsacreations.com/astuce/lire/78-quelle-est-la-diffrence-entre-les-chemins-relatifs-et-absolus.html.

Les fichiers php ( pure ou dans logique CMS ) ajoute des variables qui permettent de définir le path ( C:) ou url ( http) qui sera généré selon les contextes ( url vers extension avec paramètres).


Il semble que le mode relatif est avant tout pour les développeurs ...A confirmer ...
le path absolu évite aux navigateurs de devoir concaténer le path du fichier chargé avec celui du path de la ressource définie dans le fichier .

Au niveau de quel fichier php est concaténer les paths selon la configuration relatif /Absolu au niveau des différents CMS ( wordpress Drupal joomla ) en supposant que je souhaite avoir des liens pour les différents attributs de liens ( src href ) du type ="./xx/yyy/..." et pas ="/xx/yyy/ ?


Wordpress

database table "wp_options" column "siteurl" and "home"
liens : utilise syntaxe //* ( pour cdn ?)
file ?
backeEnd GUI ?

Drupal
database ?
http: $realpath = drupal_realpath($uri);
........$path = str_replace($_SERVER['DOCUMENT_ROOT'].'/','',$realpath);
http server : *.htaccess
......................DocumentRoot /your/full/path/to/drupal
file php function : drupal_realpath($uri);
backend GUI ?

Joomla

database ?
file ?
liens : utilise syntaxe /***
backEnd GUI ?



Est il possible que firefox ( cas b) fonctionne en protocole file avec lien de type <link href="/*/*.css"> ?
*
FIREFOX
use "/"
about:config security.checkloaduri
reconnait le protocol file:///
a) file:/// <link href="./**" fonctionne
b) file:/// <link href="/**" ne fonctionne pas
c) http <link href="/**" fonctionne
d) http <link href="./**" fonctionne


chrome
use "/"
reconnait le protocol file:/// et convertit C:/ en file:///C:/
file:/// <link href="./**" ne fonctionne pas

IE
use "\"
reconnait le protocol C:\ et convertit file:///C:/ en C:\
<link href="./**" fonctionne


Merci
Modifié par 75lionel (12 Dec 2015 - 16:55)
Les chemins serveurs sont très largement définis en absolus pour une question d'organisation et de viabilité du code. Des milliers d'includes avec des chemins relatifs ce n'est pas gérable. Ces chemins sont parfois définis à la main ou il est facile de les déterminer directement en php (avec __file__ par exemple) mais ne sont jamais utilisés côté client pour construire des urls tout simplement car il n'est jamais rendu possible d’accéder à la racine du serveur de cette façon.
À ce propos, voici un bug, largement méconnu, que j'avais constaté sous WordPress :

WordPress se comporte parfois de manière étrange sur certains chemins relatifs au niveau du thème : le CMS va d'abord chercher le chemin relatif à partir de la racine du site, puis en cas d'échec il va entamer une recherche de chemin relatif à partir du thème. Pour peu que l'on ait mis à la racine un dossier comportant le nom exact du chemin relatif... et c'est le bug. C'est pourquoi sous ce CMS il vaux mieux utiliser des fonctions dédiées telles que get_template_part() ou locate_template().
Modifié par Olivier C (13 Dec 2015 - 06:15)
En faisant des include directement alors ? C'est assez surprenant en effet.

Il faut toujours utiliser les fonctions dédiées comme il y a les thèmes enfants, le dossier page-templates et sûrement encore d'autres endroit où wordpress va chercher des templates.
bzh a écrit :
En faisant des include directement alors ? C'est assez surprenant en effet.

include ou require, le comportement sera le même sur ce point.