[fait] Déracinons WRI

Message par **Dominique** » 23 oct. 2014, 19:34

Salut

Une proposition que je veux faire depuis longtemps et que je note pour quand une bonne âme aura un peu de temps: permettre d'exécuter WRI dans un répertoire d'une URL. Par exemple: http://dom.refuges.info/test/

Warning: include(/home/users/dom/www.refuges.info/controlleurs/test.php): failed to open stream: No such file or directory in /home/users/dom/www.refuges.info/test/controlleur.php on line 84

Warning: include(): Failed opening '/home/users/dom/www.refuges.info/controlleurs/test.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear:/home/users/dom/www.refuges.info/test/includes:/home/us ... ./modeles/:') in /home/users/dom/www.refuges.info/test/controlleur.php on line 84

Warning: include(/home/users/dom/www.refuges.info/vues/test.html): failed to open stream: No such file or directory in /home/users/dom/www.refuges.info/test/controlleur.php on line 101

Warning: include(): Failed opening '/home/users/dom/www.refuges.info/vues/test.html' for inclusion (include_path='.:/usr/share/php:/usr/share/pear:/home/users/dom/www.refuges.info/test/includes:/home/us ... ./modeles/:') in /home/users/dom/www.refuges.info/test/controlleur.php on line 101

Bon, d'accord ce n'est pas très utile en prod mais j'aimerais bien faire ça pour des tests.
... la prochaine fois que quelqu'un touche au contrôleur central

Message par **sly** » 23 oct. 2014, 23:08

Totalement pour, ça serait bien plus propre (D'ailleurs, j'aurais mis ma main à couper que c'était opérationnel ça !)

Message par **sly** » 27 oct. 2014, 17:51

Voilà qui devrait être corrigé

J'ai pas testé très profondément, donc peut-être que tout ne passe pas.

La ligne :
RewriteBase /

est à retirer manuellement du .htaccess se trouvant à la racine, ou reprendre le modèle htaccess.modele.txt

Message par **Dominique** » 28 oct. 2014, 21:38

Salut

je n'ai pas bien compris ce que tu as fait, mais ça n'a pas l'air de marcher: http://dom.refuges.info/deracine/
Et je ne vois pas comment ça pourrait marcher...

Tant que tu te bases sur $_SERVER['DOCUMENT_ROOT'] tu auras la racine de ton sous domaine, pas l'endroit où s'exécute ton script:
'DOCUMENT_ROOT' => '/home/users/dom/www.refuges.info',
'SCRIPT_FILENAME' => '/home/users/dom/www.refuges.info/deracine/index.php',
'SCRIPT_NAME' => '/deracine/index.php',

Je ne connais pas tout sur apache (qui y prétendrait !) mais je ne connais qu'un moyen de retrouver la racine de l'arbo site quand elle n'est pas au premier niveau du sous domaine: parcourir la chaîne des répertoires jusqu'à ce qu'on trouve un fichier donné (par exemple routage.php).
C'est un peu lourd, mais je l'ai déjà vu faire.

Autrement, pourquoi ne pas tout avoir en relatif ? (avec éventuellement un <base href="http://dom.refuges.info/deracine/"></base> si nécessaire)

***EDIT*** En fait, tout est en dur dans tous les fichier: <link rel="shortcut icon" href="/images/favicon.ico" />
Il n'y a aucun moyen de relocaliser ça. Il faut reprendre tous les fichiers

Dis moi si tu as une meilleure idée ?

***P.S. qui n'a rien à voir*** Pourquoi ne mets tu pas ton .htaccess directement comme ça dans le GIT ? ça passe très bien.

Message par **sly** » 29 oct. 2014, 16:40

Je ne dis pas que ce que j'ai fais marchera dans tous les cas, mais j'ai fais un minimum de tests quand même avant de dire que ça marchait ;-)

Désolé d'ailleurs, j'aurais dû indiquer une démo, que voilà :
http://sly.refuges.info/demo/

Mon commit est là :
https://github.com/sletuffe/www.refuges ... 7d12ff182d

L'idée en gros est de faire une soustraction de $_SERVER['DOCUMENT_ROOT'] (qui contient le chemin sur le serveur jusqu'au / du site)
par dirname(__FILE__) qui contient le chemin dans lequel se trouve le script en cours, pour obtenir donc le sous-chemin relatif à /

Dominique a écrit : Autrement, pourquoi ne pas tout avoir en relatif ? (avec éventuellement un <base href="http://dom.refuges.info/deracine/"></base> si nécessaire)

avoir en relatif quels types de chemin ? Coté include en php, il n'existe (ou "devrait exister !") qu'un seul include indiquant un chemin, c'est dans routage.php à la racine :
require_once ('./includes/config.php'); Qui se charge alors d'ajouter comme "include_path" les chemins de ce qu'il faut, lui aussi en relatif.

Dominique a écrit : ***EDIT*** En fait, tout est en dur dans tous les fichier: <link rel="shortcut icon" href="/images/favicon.ico" />
Il n'y a aucun moyen de relocaliser ça. Il faut reprendre tous les fichiers :(
Dis moi si tu as une meilleure idée ?

ça, c'est beaucoup plus embêtant. Et remplacer /images/favicon.ico par ./images/favicon.ico risque fort de ne pas suffire, car l'url n'étant plus gérée pour représenter de vrai dossiers, on peut tres bien avoir une ressource http://www.refulges.info/je/me/marre/bien/avec/mes/urls et qui fera foirer toute tentative de relativité.

Idée ? oulla, heu... et toi ?

Message par **sly** » 29 oct. 2014, 16:44

Bon, à que je me suis fais avoir, on oublie tout ce que j'ai dis concernant le "ça marche" j'avais créer mon dossier demo sans me rendre compte que ça appelait toujours les fichiers de la zone hors demo, je re-tente...

Message par **sly** » 29 oct. 2014, 18:03

On oublie à nouveau ce que je viens juste de dire avant, on peut mettre à jour sa version pour tester, car j'ai corrigé ma correction.

J'ai pas pu m'empécher de faire un bon ménage de nom, de variable et de factorisation, donc ça peut très bien avoir des problèmes, prudence donc à celui qui passera en prod.

La "déracination" coté php devrait donc être possible maintenant. Toutefois la multitude de sympathiques
href="/vues/style.css" et autres src="/vues/toto.js" du coté http/html devrait vous montrer une version... très "vintage" de refuges.info :
http://sly.refuges.info/demo/

Je vois pas trop d'idées à part reprendre chaque fichier. Mais pour remplacr par quoi ? utiliser la variable qui indique le "sous dossier"
genre :

Code : Tout sélectionner

<link type="text/css" rel="stylesheet" href="/vues/style.css.php" />
au lieu de &#58;
<link type="text/css" rel="stylesheet" href="<?php $vue->project_root?>vues/style.css.php" />

Je n'entame rien avant d'avoir confronté les points de vue

Dominique a écrit : avec éventuellement un <base href="http://dom.refuges.info/deracine/"></base> si nécessaire

Je ne connaissais pas cette balise, mais c'est une très intéressante opportunité. ça ne règlera pas tout, notamment dans les gml/kml ou même le (brrrr) forum.
Ça n'empêchera pas qu'il faudra passer toutes les vues en revue mais on pourrait alors écrire du plus simple comme :
<link type="text/css" rel="stylesheet" href="vues/style.css.php" />

Message par **Dominique** » 29 oct. 2014, 18:39

sly a écrit :Je ne connaissais pas cette balise, mais c'est une très intéressante opportunité. ça ne règlera pas tout, notamment dans les gml/kml ou même le (brrrr) forum.

T'inquiète pas pour le forum: il est entièrement relatif

D’ailleurs, il est déjà déraciné: ...refuges.info/forum/..
Donc la base ne lui fera pas peur.

sly a écrit :L'idée en gros est de faire une soustraction de $_SERVER['DOCUMENT_ROOT'] (qui contient le chemin sur le serveur jusqu'au / du site)
par dirname(__FILE__) qui contient le chemin dans lequel se trouve le script en cours, pour obtenir donc le sous-chemin relatif

A m____ j'avais oublié le __FILE__ ! Bonne idée pour le calcul de la base.

Message par **sly** » 29 oct. 2014, 20:01

On fait quoi ?
On se tente un truc à base de :
balise base + tout refaire au format href="vues/style.css.php"

Donc ni du relatif : ./../truc/machin
ni de l'absolu par lien

Mais de l'absolu factorisé ?

On commence à remplacer tous les "/" par des "" ?

Message par **Dominique** » 29 oct. 2014, 22:00

J'aime bien $config['document_root'] à partir de $_SERVER['DOCUMENT_ROOT'] - dirname(__FILE__) à un seul endroit bien central.
De là on fait découler tous les chemins appelés par apache / PHP (vu la stratégie de la RewriteRule + routage.php): ça devrait être le cas puisque c'est ta stratégie de départ.
Pour les chemins traité par le butineur dans le html: <base href="<?= $config['document_root']?>"></base> puis rendre tous les chemins relatifs (quelques / à enlever dans les vues/...).
Fait dans cet ordre, on devrait pouvoir le faire petit à petit sans rupture pour la prod qui est à la racine. Et si on en oublie, on peut y revenir plus tard quand on s'en aperçoit en test.
Le forum ne risque rien.
Restera le cas des gml/kml que je n'ai pas regardé. Je ne pense pas en avoir oublié.
Bon, ce n'est pas un feature très important. C'est juste un peu chiant pour tester

(surtout que depuis PGSQL, je ne peux plus tester sur mon wamp) on a donc le temps, mais je pense que c'est plus logique à terme.

Message par **sly** » 29 oct. 2014, 22:23

Dominique a écrit :J'aime bien $config['document_root'] à partir de $_SERVER['DOCUMENT_ROOT'] - dirname(__FILE__) à un seul endroit bien central.

Tu dis ça car tu as lu mon code ou juste par hasard ?
Si c'est par hasard, c'est amusant car c'est justement ce que j'ai fais tout à l'heure. A un détail près, je n'ai pas utilisé "document_root" comme nom car il peut prêter à confusion avec le "document_root" de apache. J'ai donc choisi :
$config['sous_dossier_installation']
qui vaudra "/" si le dossier d'installation est à la racine
et /ici/ s'il est dans le sous dossier "ici"

Dominique a écrit : De là on fait découler tous les chemins appelés par apache / PHP (vu la stratégie de la RewriteRule + routage.php): ça devrait être le cas puisque c'est ta stratégie de départ.

Dans presque tous les cas, le développeur n'a a en effet pas à y penser. Toutefois, dans les cas que j'indiquais, c'est à dire génération d'une url hors du contexte html
fichier kml/gml par exemple, génération pdf, url des icones récupérées par OL, etc.
Il faudra en tenir compte.

Dominique a écrit : Pour les chemins traité par le butineur dans le html: <base href="<?= $config['document_root']?>"></base> puis rendre tous les chemins relatifs (quelques / à enlever dans les vues/...).
Fait dans cet ordre, on devrait pouvoir le faire petit à petit sans rupture pour la prod qui est à la racine. Et si on en oublie, on peut y revenir plus tard quand on s'en aperçoit en test.

ça me va.

Dominique a écrit : Le forum ne risque rien.

Moins l'appel à notre config.php que j'ai dû réparer, sinon, je me suis inquiété pour rien en effet.

mais je pense que c'est plus logique à terme. :oops:

Tout à fait d'accord. Bon, ben, yapuka !

Message par **Dominique** » 29 oct. 2014, 22:30

sly a écrit :
Dominique a écrit :J'aime bien $config['document_root'] à partir de $_SERVER['DOCUMENT_ROOT'] - dirname(__FILE__) à un seul endroit bien central.
Tu dis ça car tu as lu mon code ou juste par hasard ?

J'ai même pas lu ton code

juste ton post. C'est une idée géniale. Je conaissais __FILE__ mais je n'avais pas pensé à faire la comparaison

Et pourtant, j'ai vu un code se payer des tests de fichiers sur tout le chemin (je ne me rapelle pas où, mais ça va me revenir).

Message par **sly** » 29 oct. 2014, 22:32

phpBB 3 ?

edit : Rhôôôôô que je suis taquin

Message par **Dominique** » 29 oct. 2014, 22:35

sly a écrit :Dans presque tous les cas, le développeur n'a a en effet pas à y penser. Toutefois, dans les cas que j'indiquais, c'est à dire génération d'une url hors du contexte html
fichier kml/gml par exemple, génération pdf, url des icones récupérées par OL, etc.
Il faudra en tenir compte.

Faut voir. Je ne vois pas pourquoi ça serait différent. En tout cas, ça ne doit pas nous ammener loin. Ne pas oublier que les extractions sont un peu déracinées /exportations/*.php
J'ai en fait l'idée de traiter les gml/... comme des pages comme les autres (j'ai même réussi à en faire générer par le système de template de PHPbb). Bonjour la factorisation

Message par **Dominique** » 29 oct. 2014, 22:37

sly a écrit :phpBB 3 ?

edit : Rhôôôôô que je suis taquin

NAN ! Ils ont juste tout fait en relatif (pour une fois qu'ils font simple)