J'ai un petit problème que je n'arrive pas à résoudre, mais qui doit
pourtant être simple, mais bon...
J'ai un fichier, disons insertion.php, qui va être utilisé pour être
inclu dans d'autres par des require_once.
Dans ce fichier, je fais des tests, en allant ouvrir des fichiers sur
mon site qui se trouvent dans d'autres répertoires; par exemple
fichier/monfichier que je vais lire avec des fread; et je vais également
avoir des appels d'autres pages selon les cas. Ces pages peuvent être
situé à d'autres niveaux de l'arborescence.
Le problème, c'est que j'inclue ce insertion.php dans différentes pages
php, qui ne se trouvent pas toutes au même niveau.
Par exemple :
A la racine, je vais avoir une page index.php qui inclue ce fichier pour
des tests.
Dans un autre répertoire, disons repertoire "ici" un autre fichier
index. php (donc "ici/index.php") qui appelle également mon fichier
insertion.php.
Le problème, c'est que j'ai mon serveur localhost où je bosse, qui
ensuite sera installé sur mon site accessible à tout le monde.
Comment faire pour que mes adresses fonctionnent correctement sur les
deux situation (localhost et site) et dans tous les cas de figure.
C'est à dire que lorsque j'appelle insertion.php, je ne sais jamais dans
quel répertoire je suis.
J'ai tenté de récupérer $_SERVER["DOCUMENT_ROOT"] que je mets
systématiquement devant les adresses de fichiers à ouvrir ou de pages
php, dans ce style :
$repertoire = getenv("DOCUMENT_ROOT")."/";
Et ensuite les appels étant $repertoire."ici/index.php" par exemple.
Ca marche dans certains cas mais pas dans d'autres.
J'ai ensuite essayé avec $_SERVER["SERVER_NAME"]
Pareil que plus haut, ça fonctionne dans certains cas et pas dans d'autres.
J'ai enfin tenté de faire tout simplement des chdir("/") avant mes
appels, ça ne marche pas mieux.
Alors bien entendu, je pourrai pour chaque appel, mettre les adresse
complètes "http://...", et les rechanger quand j'installe tout sur le
site, avec le risque d'en oublier en cours de route, même en utilisant
une constante donnant la racine des adresses.
Mais je ne trouve pas ça très propre, et j'aimerai éviter.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Denis Beauregard
Le 17 Jun 2010 21:46:21 GMT, Michel écrivait dans fr.comp.lang.php:
Bonjour,
J'ai un petit problème que je n'arrive pas à résoudre, mais qui doit pourtant être simple, mais bon...
J'ai un fichier, disons insertion.php, qui va être utilisé pour être inclu dans d'autres par des require_once.
Dans ce fichier, je fais des tests, en allant ouvrir des fichiers sur mon site qui se trouvent dans d'autres répertoires; par exemple fichier/monfichier que je vais lire avec des fread; et je vais également avoir des appels d'autres pages selon les cas. Ces pages peuvent être situé à d'autres niveaux de l'arborescence.
Le problème, c'est que j'inclue ce insertion.php dans différentes pages php, qui ne se trouvent pas toutes au même niveau.
Par exemple :
A la racine, je vais avoir une page index.php qui inclue ce fichier pour des tests.
Dans un autre répertoire, disons repertoire "ici" un autre fichier index. php (donc "ici/index.php") qui appelle également mon fichier insertion.php.
Prenons pour acquis que le code est testé en local puis sur le serveur. La solution est très simple.
Pour des répertoires de niveau supérieur, on utilise ../ Pour des dossiers de même niveau, on peut faire ../ici/ et pour un niveau inférieur, ici/
Par exemple, le fichier à inclure est incl/f.php
Depuis incl/a.php, on inclut f.php Depuis dossier/a.php, on inclut ../incl/f.php Depuis a.php, on inclut incl/f.php
C'est identique à un lien vers une autre page...
Denis
Le 17 Jun 2010 21:46:21 GMT, Michel <nospam.moi@free.fr> écrivait dans
fr.comp.lang.php:
Bonjour,
J'ai un petit problème que je n'arrive pas à résoudre, mais qui doit
pourtant être simple, mais bon...
J'ai un fichier, disons insertion.php, qui va être utilisé pour être
inclu dans d'autres par des require_once.
Dans ce fichier, je fais des tests, en allant ouvrir des fichiers sur
mon site qui se trouvent dans d'autres répertoires; par exemple
fichier/monfichier que je vais lire avec des fread; et je vais également
avoir des appels d'autres pages selon les cas. Ces pages peuvent être
situé à d'autres niveaux de l'arborescence.
Le problème, c'est que j'inclue ce insertion.php dans différentes pages
php, qui ne se trouvent pas toutes au même niveau.
Par exemple :
A la racine, je vais avoir une page index.php qui inclue ce fichier pour
des tests.
Dans un autre répertoire, disons repertoire "ici" un autre fichier
index. php (donc "ici/index.php") qui appelle également mon fichier
insertion.php.
Prenons pour acquis que le code est testé en local puis sur le
serveur. La solution est très simple.
Pour des répertoires de niveau supérieur, on utilise ../ Pour des
dossiers de même niveau, on peut faire ../ici/ et pour un niveau
inférieur, ici/
Par exemple, le fichier à inclure est incl/f.php
Depuis incl/a.php, on inclut f.php
Depuis dossier/a.php, on inclut ../incl/f.php
Depuis a.php, on inclut incl/f.php
Le 17 Jun 2010 21:46:21 GMT, Michel écrivait dans fr.comp.lang.php:
Bonjour,
J'ai un petit problème que je n'arrive pas à résoudre, mais qui doit pourtant être simple, mais bon...
J'ai un fichier, disons insertion.php, qui va être utilisé pour être inclu dans d'autres par des require_once.
Dans ce fichier, je fais des tests, en allant ouvrir des fichiers sur mon site qui se trouvent dans d'autres répertoires; par exemple fichier/monfichier que je vais lire avec des fread; et je vais également avoir des appels d'autres pages selon les cas. Ces pages peuvent être situé à d'autres niveaux de l'arborescence.
Le problème, c'est que j'inclue ce insertion.php dans différentes pages php, qui ne se trouvent pas toutes au même niveau.
Par exemple :
A la racine, je vais avoir une page index.php qui inclue ce fichier pour des tests.
Dans un autre répertoire, disons repertoire "ici" un autre fichier index. php (donc "ici/index.php") qui appelle également mon fichier insertion.php.
Prenons pour acquis que le code est testé en local puis sur le serveur. La solution est très simple.
Pour des répertoires de niveau supérieur, on utilise ../ Pour des dossiers de même niveau, on peut faire ../ici/ et pour un niveau inférieur, ici/
Par exemple, le fichier à inclure est incl/f.php
Depuis incl/a.php, on inclut f.php Depuis dossier/a.php, on inclut ../incl/f.php Depuis a.php, on inclut incl/f.php
C'est identique à un lien vers une autre page...
Denis
Jean-Francois Ortolo
Bonjour
Pas besoin de getenv()
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie racine de l'arbosrescence des fichiers manière Unix.
La racine, il me semble, est toujours : /
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux différents de répertoire, me paraît délicat.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers relatifs, et jamais absolus.
Bien à vous.
Amicalement.
Jean-François Ortolo
Bonjour
Pas besoin de getenv()
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence
racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes
réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie
racine de l'arbosrescence des fichiers manière Unix.
La racine, il me semble, est toujours : /
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je
tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux
différents de répertoire, me paraît délicat.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers
relatifs, et jamais absolus.
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie racine de l'arbosrescence des fichiers manière Unix.
La racine, il me semble, est toujours : /
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux différents de répertoire, me paraît délicat.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers relatifs, et jamais absolus.
Bien à vous.
Amicalement.
Jean-François Ortolo
Denis Beauregard
Le 18 Jun 2010 15:19:53 GMT, Jean-Francois Ortolo écrivait dans fr.comp.lang.php:
Bonjour
Pas besoin de getenv()
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie racine de l'arbosrescence des fichiers manière Unix.
C'est même à éviter, à moins de vouloir embêter un peu un copieur de site avec des adresses absolues. "un peu" parce que facile à contourner.
La racine, il me semble, est toujours : /
Non. Il y a ici au moins 3 environnements.
Sur le PC à la maison (EasyPHP par exemple), la racine est le dossier programmé dans l'interface d'administration.
Sur le serveur, pour Internet, la racine correspond au nom du domaine, souvent public_html ou un nom similaire, mais parfois, redirection.
Sur le serveur, pour l'usage interne, la racine est celle du système (on supposera Linux par défaut) et le répertoire de travail pourrait être alors /home/mondomaine/public_html qui serait aussi www.mondomaine.com/
Il faut donc utiliser des adresses relatives et éviter les adresses absolues.
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux différents de répertoire, me paraît délicat.
Mais non. Il suffit de se rappeler du niveau du dossier et d'utiliser le bon nombre de ../ ce qui est assez facile à valider en local.
Disons que ce n'est pas recommandé si on développe plusieurs applications indépendantes sur le même serveur, mais que c'est pratique si on a par exemple les mêmes entêtes ou bannières un peu partout dans le site.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers relatifs, et jamais absolus.
C'est la meilleure solution.
Denis
Le 18 Jun 2010 15:19:53 GMT, Jean-Francois Ortolo
<ortolo.jeanfrancois_nospam@domain.invalid> écrivait dans
fr.comp.lang.php:
Bonjour
Pas besoin de getenv()
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence
racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes
réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie
racine de l'arbosrescence des fichiers manière Unix.
C'est même à éviter, à moins de vouloir embêter un peu un copieur de
site avec des adresses absolues. "un peu" parce que facile à
contourner.
La racine, il me semble, est toujours : /
Non. Il y a ici au moins 3 environnements.
Sur le PC à la maison (EasyPHP par exemple), la racine est le dossier
programmé dans l'interface d'administration.
Sur le serveur, pour Internet, la racine correspond au nom du domaine,
souvent public_html ou un nom similaire, mais parfois, redirection.
Sur le serveur, pour l'usage interne, la racine est celle du système
(on supposera Linux par défaut) et le répertoire de travail pourrait
être alors /home/mondomaine/public_html qui serait aussi
www.mondomaine.com/
Il faut donc utiliser des adresses relatives et éviter les adresses
absolues.
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je
tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux
différents de répertoire, me paraît délicat.
Mais non. Il suffit de se rappeler du niveau du dossier et d'utiliser
le bon nombre de ../ ce qui est assez facile à valider en local.
Disons que ce n'est pas recommandé si on développe plusieurs
applications indépendantes sur le même serveur, mais que c'est
pratique si on a par exemple les mêmes entêtes ou bannières un peu
partout dans le site.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers
relatifs, et jamais absolus.
Le 18 Jun 2010 15:19:53 GMT, Jean-Francois Ortolo écrivait dans fr.comp.lang.php:
Bonjour
Pas besoin de getenv()
La variable $_SERVER['DOCUMENT_ROOT'] contient bien l'arborescence racine des fichiers, accessible en php.
Cependant, il me semble, que même pour les fichier ( sous toutes réserves me corrige qui veut ), ce n'est pas la peine d'avoir la vraie racine de l'arbosrescence des fichiers manière Unix.
C'est même à éviter, à moins de vouloir embêter un peu un copieur de site avec des adresses absolues. "un peu" parce que facile à contourner.
La racine, il me semble, est toujours : /
Non. Il y a ici au moins 3 environnements.
Sur le PC à la maison (EasyPHP par exemple), la racine est le dossier programmé dans l'interface d'administration.
Sur le serveur, pour Internet, la racine correspond au nom du domaine, souvent public_html ou un nom similaire, mais parfois, redirection.
Sur le serveur, pour l'usage interne, la racine est celle du système (on supposera Linux par défaut) et le répertoire de travail pourrait être alors /home/mondomaine/public_html qui serait aussi www.mondomaine.com/
Il faut donc utiliser des adresses relatives et éviter les adresses absolues.
Sous toutes réserves.
En ce qui me concerne, je n'ai jamsi fait ce que vous évoquez, car je tiens à au moins un semblant de norme dans la programmation de mon site.
Cette pratique d'inclure un même script à partir de plusieurs niveaux différents de répertoire, me paraît délicat.
Mais non. Il suffit de se rappeler du niveau du dossier et d'utiliser le bon nombre de ../ ce qui est assez facile à valider en local.
Disons que ce n'est pas recommandé si on développe plusieurs applications indépendantes sur le même serveur, mais que c'est pratique si on a par exemple les mêmes entêtes ou bannières un peu partout dans le site.
En ce qui me concerne, j'utilise toujours des chemisn de fichiers relatifs, et jamais absolus.
C'est la meilleure solution.
Denis
Pascal
Michel a écrit :
Bonjour,
Bonjour,
J'ai un fichier, disons insertion.php, qui va être utilisé pour être inclu dans d'autres par des require_once. [...] Le problème, c'est que j'inclue ce insertion.php dans différentes pages php, qui ne se trouvent pas toutes au même niveau.
La solution classique, entre autres retenues par les frameworks, est d'avoir une page d'entrée unique, avec une variable indiquant la page finale demandée. Si l'inclusion se fait dans la page d'entrée, plus de problème de répertoires à gérer, et une seule inclusion suffit.
Souvent, mais pas toujours, cette page s'appellera "index.php", et la variable sera nommée "page", "pageid" ou "pid". La page finale, qui par exemple s'appelait "toto.php", sera appelée sous la forme "index.php?page=toto", et sera incluse dans "index.php".
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une page d'erreur. Cela oblige surement à revoir la structure du site, mais le gain en est important.
Merci
Pas de quoi.
Michel
Cordialement, Pascal
Michel a écrit :
Bonjour,
Bonjour,
J'ai un fichier, disons insertion.php, qui va être utilisé pour être
inclu dans d'autres par des require_once.
[...]
Le problème, c'est que j'inclue ce insertion.php dans différentes pages
php, qui ne se trouvent pas toutes au même niveau.
La solution classique, entre autres retenues par les frameworks, est
d'avoir une page d'entrée unique, avec une variable indiquant la page
finale demandée.
Si l'inclusion se fait dans la page d'entrée, plus de problème de
répertoires à gérer, et une seule inclusion suffit.
Souvent, mais pas toujours, cette page s'appellera "index.php", et la
variable sera nommée "page", "pageid" ou "pid".
La page finale, qui par exemple s'appelait "toto.php", sera appelée sous
la forme "index.php?page=toto", et sera incluse dans "index.php".
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour
autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une
page d'erreur.
Cela oblige surement à revoir la structure du site, mais le gain en est
important.
J'ai un fichier, disons insertion.php, qui va être utilisé pour être inclu dans d'autres par des require_once. [...] Le problème, c'est que j'inclue ce insertion.php dans différentes pages php, qui ne se trouvent pas toutes au même niveau.
La solution classique, entre autres retenues par les frameworks, est d'avoir une page d'entrée unique, avec une variable indiquant la page finale demandée. Si l'inclusion se fait dans la page d'entrée, plus de problème de répertoires à gérer, et une seule inclusion suffit.
Souvent, mais pas toujours, cette page s'appellera "index.php", et la variable sera nommée "page", "pageid" ou "pid". La page finale, qui par exemple s'appelait "toto.php", sera appelée sous la forme "index.php?page=toto", et sera incluse dans "index.php".
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une page d'erreur. Cela oblige surement à revoir la structure du site, mais le gain en est important.
Merci
Pas de quoi.
Michel
Cordialement, Pascal
John GALLET
La solution classique, entre autres retenues par les frameworks, est d'avoir une page d'entrée unique, avec une variable indiquant la page finale demandée.
Attention, si c'est codé avec les pieds -ce qui est assez souvent le cas- c'est la porte ouverte à tristement célèbre faille de sécurité des includes dynamiques.
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une page d'erreur.
Cette interdiction est primordiale, j'insiste.
a++ JGA
La solution classique, entre autres retenues par les frameworks, est
d'avoir une page d'entrée unique, avec une variable indiquant la page
finale demandée.
Attention, si c'est codé avec les pieds -ce qui est assez souvent le
cas- c'est la porte ouverte à tristement célèbre faille de sécurité des
includes dynamiques.
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour
autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une
page d'erreur.
La solution classique, entre autres retenues par les frameworks, est d'avoir une page d'entrée unique, avec une variable indiquant la page finale demandée.
Attention, si c'est codé avec les pieds -ce qui est assez souvent le cas- c'est la porte ouverte à tristement célèbre faille de sécurité des includes dynamiques.
Bien sûr, il faudra en contrepartie gérer un arbre de navigation, pour autoriser "toto" et interdire "lulu", par exemple, ou rediriger vers une page d'erreur.
