OVH Cloud OVH Cloud

require avec Free

10 réponses
Avatar
MERIGON Olivier
Bonjour,

j'ai un site hebergé par Free dont l'organisation est la suivante:

Un repertoire [Graphic] a la racine qui contient le fichier HeadPage.php lui
meme contenant une fonction headpage().

Lorsque j'inclue ce fichier a partir d'un script php situé a la racine du
site de cette facon:
require("Graphic/HeadPage.php");
tout va bien, par contre a partir d'un script situé dans un sous repertoire
require("../Graphic/HeadPage.php");
les fonctions qu'il contient se sont pas disponnibles comme si le fichier
etait inclu sans erreur mais sans avoir tenu compte de son contenu.

Alors que cela fonctionne parfaitement sous linux avec apache+php.

Quelqu'un aurait une idée ?
Merci d'avance

10 réponses

Avatar
ghost
tu peux essayer
require("$DOCUMENT_ROOT/Graphic/HeadPage.php");

"MERIGON Olivier" a écrit dans le message de
news:3f71df8b$0$27049$
Bonjour,

j'ai un site hebergé par Free dont l'organisation est la suivante:

Un repertoire [Graphic] a la racine qui contient le fichier HeadPage.php
lui

meme contenant une fonction headpage().

Lorsque j'inclue ce fichier a partir d'un script php situé a la racine du
site de cette facon:
require("Graphic/HeadPage.php");
tout va bien, par contre a partir d'un script situé dans un sous
repertoire

require("../Graphic/HeadPage.php");
les fonctions qu'il contient se sont pas disponnibles comme si le fichier
etait inclu sans erreur mais sans avoir tenu compte de son contenu.

Alors que cela fonctionne parfaitement sous linux avec apache+php.

Quelqu'un aurait une idée ?
Merci d'avance


Avatar
Jean-Marc Molina
Je te conseille de mettre TOUS tes scripts au même niveau, à la racine par
exemple et d'utiliser une hiérarchie de répertoires pour tes ressources :
images, etc...

Ça t'évitera tous ces problèmes d'include et require. Le fonctionnement de
ces fonctions étant différent selon les serveurs et surtout selon le
contexte de ton application : simple page ? traitement d'un formulaire ?...

J'ai perdu des heures à mes débuts en PHP pour comprendre comment tout cela
fonctionnait. Il faut bidouiller avec les variables PHP mais vraiment la
solution la plus efficace, c'est de stocker ses scripts dans un même
répertoire.
Avatar
MERIGON Olivier
Merci pour votre reponse,
vous avez raison, g finis par faire ca...


"Jean-Marc Molina" a écrit dans le message
de news: bku3oq$ic1$
Je te conseille de mettre TOUS tes scripts au même niveau, à la racine par
exemple et d'utiliser une hiérarchie de répertoires pour tes ressources :
images, etc...

Ça t'évitera tous ces problèmes d'include et require. Le fonctionnement de
ces fonctions étant différent selon les serveurs et surtout selon le
contexte de ton application : simple page ? traitement d'un formulaire
?...


J'ai perdu des heures à mes débuts en PHP pour comprendre comment tout
cela

fonctionnait. Il faut bidouiller avec les variables PHP mais vraiment la
solution la plus efficace, c'est de stocker ses scripts dans un même
répertoire.


Avatar
M.D
Dans l'article <3f71df8b$0$27049$,
disait...
Bonjour,

j'ai un site hebergé par Free dont l'organisation est la suivante:

Un repertoire [Graphic] a la racine qui contient le fichier HeadPage.php lui
meme contenant une fonction headpage().

Lorsque j'inclue ce fichier a partir d'un script php situé a la racine du
site de cette facon:
require("Graphic/HeadPage.php");
tout va bien, par contre a partir d'un script situé dans un sous repertoire
require("../Graphic/HeadPage.php");
les fonctions qu'il contient se sont pas disponnibles comme si le fichier
etait inclu sans erreur mais sans avoir tenu compte de son contenu.




http://support.free.fr/web/php/php4.html

[...]
Chemin d'inclusion

Dans le cadre de la réalisation d'un site important, il est possible de
centraliser les fichiers fréquemment inclus.

Pour cela, un répertoire est ajouté par défaut à la liste de recherche
des fichiers inclus.
Il n'est pas créé par défaut, pour ce faire, il suffit de créer un
répertoire nommé "include" (sans les guillemets et en minuscules) à la
racine du site web.

Exemple

Vous avez un fichier 'global.php' contenant diverses informations ou
méthodes.
Vous souhaitez y accéder depuis n'importe où de votre site sans le
recopier dans chaque sous-répertoire ou inscrire le chemin relatif
jusqu'à ce fichier dans chacun des programmes.

* Vous devez donc créer "include" (sans les guillemets et en
minuscules) et y stocker votre fichier "global.php" (il se trouve donc
dans include/global.php vu depuis FTP)

* Pour l'appeler depuis un fichier .php quelque soit l'endroit où il se
trouve à l'intérieur de votre site, il suffit de faire :

<? include("global.php"); ?>
ou encore

<? require("global.php"); ?>
(selon la méthode d'inclusion souhaitée)
[...]

--
Marc

Avatar
Thibaut Allender
"Jean-Marc Molina" wrote in message
news:bku3oq$ic1$
Je te conseille de mettre TOUS tes scripts au même niveau, à la racine par
exemple et d'utiliser une hiérarchie de répertoires pour tes ressources :
images, etc...


je ne voudrais pas devoir mettre les mains dans un de tes sites alors ;)

faut quand meme pas exagerer, a la racine, il doit y avoir "index.php" et
c'est tout

ensuite, on peut faire un repertoire pour les includes (genre
/includes/php/)
includes peut aussi servir a contenir les css et les js
(/includes/css/,/includes/js/)

on evite egalement d'utiliser des noms de fichiers, et on utilise des
repertoires, c'est bcp plus propre et organisé

par exemple au lieu d'avoir index.php linké a gallerie.php, on cree un
index.php dans le repertoire /gallerie/ et un link juste "/gallerie/"

on peut effectivement ensuite mettre d'autres php dans /gallerie/ mais il
vaut tjrs mieux utiliser des repertoires

d'ailleurs cette gestion par repertoire permet de mieux se faire referencer
dans google, pour qui l'url est tres importante

par contre, les ressources ne doivent pas etre partagees ! on ne va pas
aller chercher un script dans /test/ depuis /gallerie/ avec des chemins
tordus genre "../test/blah.php"

tout ce qui est commun va dans /includes/php/ et on y accede vian
$DOCUMENT_ROOT comme le dit si bien ghost.

a+

Avatar
Lionel
MERIGON Olivier wrote:
Merci pour votre reponse,
vous avez raison, g finis par faire ca...


Personnellement cette solution ne me convient pas.
Pour les includes chez Free il me semble que tu peux tous les mettre dans le
répertoire "includes" à la racine de ton serveur.
ce répertoire se trouve dans le include_path.
il suffit de faire un require("monFic.php") ou que tu sois et ca fonctionne.

Avatar
Jean-Marc Molina
Bonnes remarques Thibaut mais il faut tout relativiser.
Il existe plusieurs méthodes pour organiser un projet web.
L'une n'est pas forcément plus mauvaise qu'une autre.
C'est après avoir rencontré de trop nombreux problèmes avec ces histoires
d'include/require que j'ai décidé d'opter pour une hiérarchie des
ressources, mais d'utiliser un répertoire commun pour les scripts PHP.

on evite egalement d'utiliser des noms de fichiers, et on utilise des
repertoires, c'est bcp plus propre et organisé


Un site ne comporte pas forcément des centaines de scripts alors qu'il
contient souvent de très nombreuses ressources.
Centraliser ces scripts à la racine est une autre façon de les organiser.

Dans ton exemple on peut avoir un script galerie.php à la racine et un
répertoire images/galerie qui contient les images des galerie. Ou bien un
index.php dans ce répertoire comme tu le proposes.

d'ailleurs cette gestion par repertoire permet de mieux se faire
referencer dans google, pour qui l'url est tres importante


Je ne vois pas vraiment la différence, pour Google une url reste une url.

par contre, les ressources ne doivent pas etre partagees !


Dans certains cas on n'a pas le choix, ça dépend encore une choix des
projets.
Par exemple si on utilise un système de modèle/template, les scripts
index.php et galerie.php ont tous les 2 besoins des scripts entête.php et
pied_de_page.php. Si galerie.php se trouve dans un sous-répertoire, il faut
inclure ces 2 fichiers. Ce qui peut poser des problèmes pour tout lier car
parfois c'est un sous-sous-répertoire, les rubriques et catégories d'un site
pouvant être nombreuses. On se retrouve avec des trucs du genre : include
('..galerieentête.php'); .

Quand on parle de CMS, de traitement de formulaire... On se retrouve parfois
coincé car ces fonctions ne fonctionnent pas toujours de la même façon. Ça
dépend du contexte. Si on utilise le script tel quel, l'include sera
relatif, par contre si ce script a été soumis par un formulaire, on se
retrouve en absolu... Enfin c'est l'idée, j'ai abandonné cette croisade. Et
jongler avec les variables PHP ne permet pas de résoudre ces problèmes, ça
dépend aussi des serveurs... Et un projet ne doit pas reposer sur une
technologie en particulier.

Pour en revenir aux ressources, on peut aussi parler des graphismes,
scripts, contenus... Je ne vois pas comment un site dynamique peut
fonctionner si les ressources ne sont pas partagées.

Donc d'après mes expériences j'ai du mal à voir comment je pourrais
organiser un site de cette façon.

Dernière remarque, pour les urls on peut aussi dissimuler l'utilisation des
.php avec les modules du serveur web, rewrite pour Apache par exemple qui
permet de transformer http://www.monsite.com/monscript.php en
http://www.monsite.com/monscript/index.php par exemple. On voit ça un peu
partout, ça reste un exemple.

Avatar
Thibaut Allender
"Jean-Marc Molina" wrote in message
news:bl1aso$psa$
Centraliser ces scripts à la racine est une autre façon de les organiser.


bof... si on regarde un OS, a la racine d'un disk dur, on ne trouve jamais
des fichiers, mais bcp de repertoires (mais ca n'est pas forcemment un bon
exemple car un site n'est pas un OS)

Dans ton exemple on peut avoir un script galerie.php à la racine et un
répertoire images/galerie qui contient les images des galerie. Ou bien un
index.php dans ce répertoire comme tu le proposes.


moi je vois plutot la racine comme l'accueil du site, et dans l'accueil, on
n'a que l'index, ensuite on va dans d'autres parties, donc d'autres
repertoires, avec des fichiers qui n'ont rien a voir avec l'accueil et qui
donc n'ont pas a etre placés au meme niveau que celui ci

je dis ca, car pour moi, un repertoire contient des donnes qui sont liees
entre elles

d'ailleurs cette gestion par repertoire permet de mieux se faire
referencer dans google, pour qui l'url est tres importante


Je ne vois pas vraiment la différence, pour Google une url reste une url.


je voulais dire qu'on peut avoir plus de detail avec des repertoires :

/galerie/photos/ c'est mieux que /galeriephoto.php

d'un coté on a 2 mots, de l'autre un seul
comme google cherche sur les mots entiers et pas les portions, si on cherche
"galerie+photo" le premier sera trouvé, pas le 2e

je ne sais pas si galerie_photo.php permet ce "split"


Par exemple si on utilise un système de modèle/template, les scripts
index.php et galerie.php ont tous les 2 besoins des scripts entête.php et
pied_de_page.php. Si galerie.php se trouve dans un sous-répertoire, il
faut

inclure ces 2 fichiers. Ce qui peut poser des problèmes pour tout lier car
parfois c'est un sous-sous-répertoire, les rubriques et catégories d'un
site

pouvant être nombreuses. On se retrouve avec des trucs du genre : include
('..galerieentête.php');


oui, c'est ce que j'explique dans le point suivant, tout ce qui est commun
va dans un seul et meme repertoire, independant des autres

Pour en revenir aux ressources, on peut aussi parler des graphismes,
scripts, contenus... Je ne vois pas comment un site dynamique peut
fonctionner si les ressources ne sont pas partagées.


on s'est mal compris
quand je dis qu'elles ne doivent pas etre partagees, je veux dire que des
ressources qui se trouvent dans /galerie/ ne doivent etre utilisees que par
les scripts egalement contenus dans ce repertoire

si par contre on doit y acceder depuis /galerie/ et /test/ alors on les
place en dehors des deux, par exemple dans /common/images ou
/common/includes

d'ailleurs, je suis plutot partisan du "tout partagé", c'est a dire que je
place toutes les images du site dans /data/images/

comme ca, on cherche pas a travers tout le site ou est telle image, on est
sur de la trouver la
et si on doit utiliser la meme depuis 2 scripts, le lien est simple :
"/data/images/...", toujours en absolu

Donc d'après mes expériences j'ai du mal à voir comment je pourrais
organiser un site de cette façon.


ca fait 5 ans que je developpe et j'en ai essayé des methodes ;)

Dernière remarque, pour les urls on peut aussi dissimuler l'utilisation
des

.php avec les modules du serveur web, rewrite pour Apache par exemple qui
permet de transformer http://www.monsite.com/monscript.php en
http://www.monsite.com/monscript/index.php par exemple. On voit ça un peu
partout, ça reste un exemple.


oui, on peut meme aller plus loin avec le rewrite ;)

http://www.monsite.com/galerie/photos/vacances/france

redirige vers http://www.monsite.com/galerie.php, ce dernier script
analysant les differentes parties de l'url (photos, vacances, france)

c'est toujours mieux que galerie.php?gal=photos&type=vacances&lieu=france ;)

a+


Avatar
Jean-Marc Molina
Bonjour Thibaut,

Le problème de choisir une structure pour ses répertoires c'est un peu comme
le problème d'une base de données.
Enfin ça peut s'appliquer à tout...
Il y a la vue logique qu'on en a (conceptuelle) et la vue physique, que la
technologie nous oblige à utiliser. Windows ? Linux ? Il faut utiliser /, le
problème des include/require... Il faut donc trouver une solution et adapter
l'idée qu'on a d'une chose aux moyens que l'on a ou que l'on nous donne
parfois sous contrainte ^^.
Donc je pense qu'on est d'accord pour la logique, après le choix que l'on
fait dépend des projets.

"galerie+photo" le premier sera trouvé, pas le 2e


Je crois que Google utilise des mots-clés pour ses recherches, si
galerie.php contient les mots "galerie photo", il renvoie la bonne page.
Après que les données soient bien organisées, ça doit l'aider :). Moi
j'aurai nommé mon petit fichier "galerie_photo.php" pour que ça soit plus
lisible. Ma technique c'est de remplacer le / logique de mon répertoire par
un _ physique pour mes noms de fichiers...

ca fait 5 ans que je developpe et j'en ai essayé des methodes ;)


Et je crois qu'on a pas fini d'en découvrir :). Si on en avait fait le tour
ça serait presque déprimant :p

c'est toujours mieux que galerie.php?gal=photos&type=vacances&lieu=france
;)


Ça plaît aux geeks-développeurs-hackeurs mais le visiteur préfère clairement
avoir un beau /galerie ^^
Je n'ai jamais eu l'occasion de vraiment tester ce module sur un gros
serveur, je me demande si ça peut faire chuter les performances... Après
tout c'est à chaque hit qu'il rentre en jeu...

Merci Thibaut pour toutes ces remarques !

Avatar
Thibaut Allender
"Jean-Marc Molina" wrote in message
news:bl8kck$ojq$

Salut Jean-Marc,

Je crois que Google utilise des mots-clés pour ses recherches, si
galerie.php contient les mots "galerie photo", il renvoie la bonne page.


certes, mais si l'url contient aussi les mots recherchés, c'est encore
mieux, et ca fait gagner de precieuses places !

Après que les données soient bien organisées, ça doit l'aider :).


oui, l'ideal etant title + url + premiers mots de la page

j'aurai nommé mon petit fichier "galerie_photo.php" pour que ça soit plus
lisible. Ma technique c'est de remplacer le / logique de mon répertoire
par

un _ physique pour mes noms de fichiers...


oui, c'est une question de logique personnelle, mais esthetiquement je
prefere /galerie/photo/ que galerie_photo.php ;)

ca fait 5 ans que je developpe et j'en ai essayé des methodes ;)


Et je crois qu'on a pas fini d'en découvrir :). Si on en avait fait le
tour

ça serait presque déprimant :p


oui, je suis meme parfois revenu en arriere (essai puis abandon des
templates, header/footer ou include de la page dans une page unique... etc)

ca depend aussi bcp des projets

Je n'ai jamais eu l'occasion de vraiment tester ce module sur un gros
serveur, je me demande si ça peut faire chuter les performances... Après
tout c'est à chaque hit qu'il rentre en jeu...


oui, mais ca n'est rien comparé au traitement d'une page php complete !
j'utilise pas mal de rewrites et le module spelling est aussi activé, sur un
site qui fait quand meme un peu moins de 1 million de pages vues / mois, et
ca ne le perturbe pas plus que ca

ceci dit, au rewrite, il faut ajouter le parsing de l'url, qui est un peu
plus complexe que de "simplement" recuperer les variables GET

Merci Thibaut pour toutes ces remarques !


Et merci pour le "débat"

a+