[fait] Déracinons WRI

Répondre

Smileys
:D ;) :o :? 8) :lol: :oops: :twisted: :roll: :ours: :fille: :calimero: :troll: :saint: :forb: :avocat: :mouton: :rando: :vaudou: :noel: :) :( :shock: :x :P :cry: :excl: :?: :idea: :arrow: :| :sleep: :geek: :blue: :mrgreen:
Voir plus de smileys

Les BBCodes sont activés
[img] est activé
[url] est activé
Les smileys sont activés

Revue du sujet
   

Si vous souhaitez joindre un ou plusieurs fichiers, complétez les indications suivantes.

Taille maximum par fichier joint : 10 Mio.

Étendre la vue Revue du sujet : [fait] Déracinons WRI

par sly » 29 févr. 2016, 13:39

Un petit bug a été introduit sur la page des nouvelles et d'index ou une installation en sous dossier faisait générer une URL invalide.
Le code à problème se situe dans le générateur de lien local du format phpBB.

J'ai corrigé ce problème, mais cela pourrait, hélas, inclure comme contrepartie que tous les liens du forum vers des images soit inopérant si on utilise la base déjà existante (car les liens sont encodé sous la forme [img=/photo-transférée.jpg]

par sly » 27 nov. 2014, 10:30

corrigé

par sly » 24 nov. 2014, 16:54

+1

par leosw » 24 nov. 2014, 16:50

Salut,

Il y a un bug sur les liens géoloc :
https://github.com/sletuffe/www.refuges ... .html#L135

Ils ne doivent pas être déracinés, c'est un protocole je pense.

Léo

par sly » 01 nov. 2014, 19:23

ok avec tout ce que tu as écris.

par Dominique » 01 nov. 2014, 17:29

sly a écrit :Sachant que l'humain est fénéant et qu'un simple "/" marchera quand même dans nos zones de dév et en prod, il est fort à parier que la flemme/ l'inattention l'emportera sur le long terme et qu'on finira donc avec pas mal d'écriture de lien en "/" donc que wri sera indéracinable à nouveau à moins des s'atteler à un ménage régulier.
Pas grave si c'est pour du dev:
- En général, on teste une fonction dans un coin bien précis, pas l'admin du forum ni le texte des Wikis
- Si on passe sur un bug, comme justement on est en dev, on corrige et ça passe avec le reste.
Pour que l'utilisation soit bonne au fûr et à mesure, il faudrait que nos zones de dév soient par exemple dans des sous dossiers, ça nous obligerait à y penser...
Je ne crois pas: on verra les bugs en déraciné mais pas ceux en / (c'est ce qui est arrivé à ta première modif: elle marchait sur n'importe quel répertoire sauf sur : :))
Comme tu veux, je suis dispo ce week end pour réparer au cas où. Et nos utilisateurs sont les meilleurs débuggeurs ;-) Un 404 au mauvais endroit n'a de douloureux que si on a tapé une fiche de 10 bras de long et qu'on a ça à la validation !
Pour le reste, le risque de corruption de donnée dans notre base lié à ça me semble extrêmement faible.
Je me tâte
- d'un côté, rien n'est pressé sur le contenu du GIT. On peut attendre d'avoir une fonction ou correction intéressante,
- d'un autre côté, livrer tout ce mic mac avec une autre fonction également nouvelle ou dans l'urgence n'est pas le plus malin.

J'ai d'autres trucs à livrer incessamment. On peut attendre.

par sly » 01 nov. 2014, 13:25

Dominique a écrit : Il suffisait de remplacer les href=, src=, action="/... par ...="<?=$config[sous_dossier_installation]?>...
J'avais ça en vue, mais je l'avais écarté de prim abord car cela alourdissait pas mal l'écriture de liens internes. Sachant que l'humain est fénéant et qu'un simple "/" marchera quand même dans nos zones de dév et en prod, il est fort à parier que la flemme/ l'inattention l'emportera sur le long terme et qu'on finira donc avec pas mal d'écriture de lien en "/" donc que wri sera indéracinable à nouveau à moins des s'atteler à un ménage régulier.

Dans le framework laravel (que j'utilise professionnellement) les templates utilisent une syntaxe {{url('route')}} qui permet la construction d'un lien tenant compte des sous dossiers.
ou cette syntaxe : {{HTML::style('css/bidule.min.css')}}
qui construit la balise pour le style avec l'url en absolue.

bref, rien d'incroyablement économe en nombre de caractères non plus. Je pense donc que <?=$config[sous_dossier_installation]?>/truc.css n'est pas plus mauvais qu'ailleurs.

Pour que l'utilisation soit bonne au fûr et à mesure, il faudrait que nos zones de dév soient par exemple dans des sous dossiers, ça nous obligerait à y penser...
- Les textes des Wiki qui sont dans la base et ne supporteront pas <?=$config[sous_dossier_installation]?> :(
Argh et oui, of course, les liens ont été tapés "à la main" et à une époque où on avait pas pensé à ça. Donc on a fait du "Voir ici : /ajout-point/ pour ajouter un point". Pas dramatique pour les dév qui seront dans un sous dossier, mais non propre. (Heureusement que la majorité des liens sont vers le wiki lui même et donc que l'url est dynamiquement créée)

On doit pouvoir s'en sortir quand même car on utilise la syntaxe phpBB :
[ url=/exportations/formulaire_exportations.php]
si ça commence par un "/" j'ai qu'a automatiquement convertir en un lien tenant compte du sous-dossier


Peut être quelques tests supplémentaires avant de mettre en prod ?
Comme tu veux, je suis dispo ce week end pour réparer au cas où. Et nos utilisateurs sont les meilleurs débuggeurs ;-) Un 404 au mauvais endroit n'a de douloureux que si on a tapé une fiche de 10 bras de long et qu'on a ça à la validation !
Pour le reste, le risque de corruption de donnée dans notre base lié à ça me semble extrêmement faible.

par Dominique » 31 oct. 2014, 19:44

Deuxième tentative: Exit <base />
Il suffisait de remplacer les href=, src=, action="/... par ...="<?=$config[sous_dossier_installation]?>...
Il reste bien quelques points chauds quand on est déraciné mais ce n'est pas grave car c'est du debug, on les corrigera au fur et à mesure:
- (connexion / déconnexion)
- Les textes des Wiki qui sont dans la base et ne supporteront pas <?=$config[sous_dossier_installation]?> :(
La version à la racine marche impec.
Peut être quelques tests supplémentaires avant de mettre en prod ?

par sly » 31 oct. 2014, 10:19

bien reçu. Je ne fais pas de mise en prod.

ps: haaaa, je me disais bien que le forum ne se laisserait pas faire sans combattre !

par Dominique » 31 oct. 2014, 09:40

J'ai un peu avancé:
- correction du calcul de url_base qui ne marchait pas quand le site est à la racine :)
- mise en relatif de tout ce que j'ai trouvé en src, href et dans les formats exportés.
Uploadé en git master.

Reste un problème là où je ne l'attendais pas: le forum n'a pas supporté la <base> :oops:
Faut que je réfléchisse à la façon la plus élégante de traiter le pb.
Donc ne pas faire de pull pour l'instant sinon on n'a pas les jolies petites icônes du forum (ça permet de se servir du forum mais c'est bien gênant quand même)

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) :satan:

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 :)

par sly » 29 oct. 2014, 22:32

phpBB 3 ?


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

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 :oops: juste ton post. C'est une idée géniale. Je conaissais __FILE__ mais je n'avais pas pensé à faire la comparaison :idea:
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).

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 !

Haut