[clos] Evolution du logiciel du forum vers PhpBB 3.2

[sly]

Modération : transfert forum perte id_user
Voir :
http://dom.refuges.info/forum/viewtopic.php?t=6338

le user sly_ "anonymisé" aurait dû être sly vu que c'est sly qui avait posté le message initialement.

***EDIT DOM*** CORRIGE
Je n'avais pas vu que tu gardais l'user si connecté :oops:

[sly]

Faut il changer la date d'un ancien post si transfert forum ?

Quoi qu'on choisisse, ça aura des inconvénients et avantages, mais lequel est le moins pire ?

Si M. bidule ajoute sur la fiche un message en Mai 2010 disant qu'il est content de la bouffe, un modérateur passe par là en Mai 2017 et il le transfert sur le forum. (Passons sur le fait qu'il aurait dû le supprimer ;-) ) l'avis de M. Bidule est maintenant daté de Mai 2017 sur le forum ce qui est trompeur.

Cas actuel :
L'avis de M. Bidule est bien daté de Mai 2010 mais le message s'insert au petit bonheur la chance par date loin dans les archives, parfois au milieu d'une discussion sans rapport.

j'ai envie de quand même préférer le 2ème cas


***EDIT DOM*** CORRIGE
Je pense comme toi qu'il faut garder la date initiale
Au départ, j'avais pensé que voir son post dans la zone "dernier post" consolerait l'auteur de le voir disparaitre de la fiche mais, si c'est un commentaire récent, il sera bien en dernier et si c'est du ménage ancien, ça ne nécéssite pas une grande pub.

[sly]

***EDIT DOM*** CORRIGE
Comme j'adore résoudre beaucoup de problèmes compliqués avec une solution simple, j'ai fait comme ça : https://github.com/RefugesInfo/www.refu ... hp#L56-L69

Pour l'élégance par contre, on repassera ;-)
Du parsing de html après un appel http, faut pas trop que le nom des classes css/div changent.
ça rejoint un peu mon idée javascript où on appel une route qui fournie le bandeau.
Mais là ça marche, c'est le principal.

P'tet que créer une route pour ce besoin qui ne fournirait que le bandeau réduirait la dépendance au format de la page. Mais on a le temps, le prochain qui prendra le mur nettoiera ça ;-)

***EDIT DOM***
Sur que c'est relou! Mais c'est ce qui génère le moins de code.
Et puis, dans un sens contexte PHP incompatible MVC / PhpBB, ce n'est pas si idiot.
C'est ce qui est le plus indépendant à moins que quelqu'un se mette à saccager les balises <début & fin de tête & pied>, ce que personne n'a de raison valable de faire.
Pour les CSS, j'inclue la feuille de style WRI qui est toujours unique !
Bon, ça sollicite un peu ton DNS mais pas plus le SQL qui serait appelé de toute façon. Autant qu'il le soit avec un contexte propre.

J'ai changé pour la page la plus légère au niveau contrôleur : https://github.com/RefugesInfo/www.refu ... hp#L56-L69
J'ai pensé à une vue neutre aussi mais le jeu en vaut il la chandelle ? Controleur, ...

C'est sur que ça ne règle pas l'archi du bandeau dans le MVC mais j'ai un peu envie de limiter les modifs à PhpBB dans un premier temps histoire de ne pas mélanger les pb.


***EDIT DOM***
J'ajoute que pour exécuter du code WRI (qui appelle PDO) dans du code PhpBB (Qui passe par $db), on se retrouve avec 2 accès à la MDB.
En ajoutant les incompatibilités autoload de classes, bon debug :satan: (j'ai essayé :calimero: )

***EDIT DOM***
J'oubliais, on ne peut pas évaluer du PHP dans un template PhpBB ni inclure un fichier en dehors de l'arbo du forum.
Il faut donc évaluer le bandeau WRI quelque part et le réinjecter en variable PhpBB de toute façon.

Ensuite, tu as dû remarquer que listener.php s'exécute dans un "namespace". Pour quelqu'un comme moi qui n'a pas eu l'occasion d'en approfondir la théorie, ça revient à jouer une partie d'échecs avec la règle du jeu de GO :)

***EDIT DOM***

Du parsing de html après un appel http, faut pas trop que le nom des classes css/div changent.

En fait, je ne fais pas de parsing mais un split de string avec un token (string) "<div id="entete">" de sorte que je ne suis pas dépendant de l'intégrité du HTML entre mes tokens.

ça rejoint un peu mon idée javascript où on appel une route qui fournie le bandeau.

Tout à fait, avec l'avantage de ne pas impliquer l'utilisateur dans l'intégration du morceau de bandeau et de ne pas lui faire traverser le WEB

Enfin, l'archi PhpBB change à chaque version majeure (3.0, 3.1, 3.2) et il faut se repayer le debug en essayant de comprendre ce qui a changé (chemineur est resté en 3.1 par exemple, qui n'utilise pas du tout les mêmes stockages BBcode que 3.2).

Bref, plus on sera indépendant entre les archis WRI et PhpBB, plus on pourra utiliser nos nuits à autre chose qu'à intégrer.

[Dominique]

P'tet que créer une route pour ce besoin qui ne fournirait que le bandeau réduirait la dépendance au format de la page.

Voilà. Bandeau et pied extraits suivant le MVC avec une route, un contrôleur et tout...
https://github.com/RefugesInfo/www.refu ... hp#L55-L64

ça fait un appel DNS+apache de plus mais ça ne semble pas te gêner (moi non plus)
J'ai refait des essais pour rester en interne mais, décidément, ça nous amène trop loin...

[sly]

Bon, ça sollicite un peu ton DNS

ça il est clair que ça n'est en rien un problème !

S'il pouvait y avoir quelque chose qui m'inquiète coté système, ça n'est certainement pas une histoire de performance. Plus par contre l'éventualité d'une option de sécurité à la c.. qui va débarquer "par défaut" dans 5 an et qui interdira php de faire des appels http ou des appels http vers localhost.
Mais ça me paraît quand même assez peu probable.

J'ajoute que pour exécuter du code WRI (qui appelle PDO) dans du code PhpBB (Qui passe par $db), on se retrouve avec 2 accès à la MDB.
En ajoutant les incompatibilités autoload de classes, bon debug :satan: (j'ai essayé :calimero: )

Double accès à la db, si ça n'était que ça, je considérerais que c'est une victoire !.
Non, là ou j'ai galéré sur mes tests c'est l'histoire de namespace, de variable global et sans doute d'autres ou, n'ayant pas passé l'étape 2, je n'ai pas encore été confronté.

[Dominique]

Non, là ou j'ai galéré sur mes tests c'est l'histoire de namespace, de variable global et sans doute d'autres ou, n'ayant pas passé l'étape 2, je n'ai pas encore été confronté.

Tout à fait... Et l'autoload des classes.
Mais ce qui m'inquiète le plus, c'est la très grande inventivité des développeurs de PhpBB qui peuvent introduire une nouvelle techno à la prochaine release qui va nous remettre à 0 côté debug sans certitude de s'en tirer à chaque fois.
Finalement, la requête AJAX intra-site n'est peut être pas si débile (après tout, un serveur SQL marche comme ça) !
Ce qui m'aurais embêté, c'est de charger le bandeau à partir de l'explorateur. Parce que ça fait traverse le réseau en +. Quoi que certains serveurs en abusent....

[sly]

Voilà. Bandeau et pied extraits suivant le MVC :) avec une route, un contrôleur et tout...
https://github.com/RefugesInfo/www.refu ... hp#L55-L64

Avec ça on devrait s'affranchir des contraintes de parsing html. Nikel.

Je m'arrangerais pour peut-être remettre les balises fermantes de html et body dans une vue histoire de vraiment sortir tout le html vers /vues
mais c'est un détail.

Je m'étais de toute façon dit que ça faisait un peu bidouille c'est if (en_tete) if (pied) j'en profiterais peut-être pour faire ça un peu moins "if if if" mais rien ne presse

[Dominique]

Je m'arrangerais pour peut-être remettre les balises fermantes de html et body dans une vue histoire de vraiment sortir tout le html vers /vues
mais c'est un détail.

J'ai en tête un template "page" qui contiendrait les balises ouvrantes et fermantes <html> <head> & <body> et qui inclue bandeau, vue et pied.

[sly]

J'ai en tête un template "page" qui contiendrait les balises ouvrantes et fermantes <html> <head> & <body> et qui inclue bandeau, vue et pied.

héhé, pareil ;-)
Au final, ça reviendrait presque au même : ça déporte les "if + include(morceau_de_template)" dans une vue "page générique" au lieu du php qui contient les routes mais au moins ça donnera la satisfaction d'un truc mieux rangé.

Bon, j'ai encore rien commencé, c'est une idée "pour quand j'aurais le courage", si tu as une idée d'un truc simple et propre, vas y !

[Dominique]

J'ai en tête un template "page" qui contiendrait les balises ouvrantes et fermantes <html> <head> & <body> et qui inclue bandeau, vue et pied.

héhé, pareil
Au final, ça reviendrait presque au même : ça déporte les "if + include(morceau_de_template)" dans une vue "page générique" au lieu du php qui contient les routes mais au moins ça donnera la satisfaction d'un truc mieux rangé.

Bon, j'ai encore rien commencé, c'est une idée "pour quand j'aurais le courage", si tu as une idée d'un truc simple et propre, vas y !

C'est fait :
https://github.com/RefugesInfo/www.refu ... es.php#L99
https://github.com/RefugesInfo/www.refu ... _page.html

ça permet aussi à chaque contrôleur de décider s'il veut entete_et_pied :
On a le niveau template à utiliser (EX: $vue->template="point.json")
Et, dans le cas général : $vue->template='_page.html' qui inclue $vue->type.'.html'

J'ai traité aussi la gestion, avec une bidouille de plus restera à la passer en MVC...
https://github.com/RefugesInfo/www.refu ... #L104-L106

[sly]

C'est fait :
https://github.com/RefugesInfo/www.refu ... es.php#L99
https://github.com/RefugesInfo/www.refu ... _page.html

Simple, efficace, plus propre qu'avant: Nikel.
J'avais peur de voir des if fleurir dans _page.html mais même pas en fait, vu que toutes nos pages html ont bandeau/pied c'est propre et lisible, et les balises qui s'ouvrent se ferme dans le même fichier (et ça compte ça pour ne pas s'embrouiller)

J'ai traité aussi la gestion, avec une bidouille de plus :( restera à la passer en MVC...

Hé ouais, je contemple depuis des années ce dossier /gestion, mais voilà, c'est moins sexy de trifouiller un truc de backoffice que de belles pages vues par tout le monde.
Et donc, idem, j'ajoute des magouilles en me disant que je devrais reformater ça comme le reste, mais la flemme me domine ;-)

[sly]

les mails d'inscriptions/notification arrivent en provenance de contact@la-foret.info


***EDIT DOM*** CORRIGE
Une habitude de debug...
A ne pas oublier lors de la vraie migration.
Se change dans "Paramètres des e-mails" (à 3 endroits !)"

[sly]

Ici :
https://dom.refuges.info/forum/viewtopic.php?f=1&t=5206

Le nom du premier (identifié et non modérateur) qui a posté apparaît en blanc sur vert très clair, et c'est difficilement lisible


***EDIT DOM*** CORRIGE
Ha ben ce bug là, il fallait le trouver !
Chapeau

[sly]

https://dom.refuges.info/forum/viewtopi ... 629#p19629

Un message posté à 23h18 après transfert s'affiche datant de 01h18 le lendemain
Doit y avoir un GMT+2 pas pris en compte quelque part ou pris en compte 2 fois


***EDIT DOM***
Corrigé un peu au lance flamme.
Je ne garantis rien en cas d’utilisateur sur un fuseau différent ou de passage été/hiver (que ne gère toujours pas PhpBB).
Revoir les discissions:
http://www.refuges.info/forum/viewtopic.php?t=5726
http://www.refuges.info/forum/viewtopic.php?t=7765

[sly]

française s'est transformé en fran??aise

https://dom.refuges.info/forum/viewtopi ... 35&p=19629


***EDIT DOM*** CORRIGE
Bien vu.
Bien traité au dev mais une optimisation l'avait fait sauter
Pour la petite histoire, la faute à request_var ('m', '') qui traffique la chaine. Il faut prendre les infos directement dans $_POST.