Les avertissements suivants se sont produits :
Warning [2] Undefined array key 0 - Line: 1640 - File: showthread.php PHP 8.2.18 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/showthread.php 1640 errorHandler->error_callback
/showthread.php 915 buildtree




Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Les bugs (core, modules) non corrigés - Comment les traitez-vous ?
#1
Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 1.11.2.1
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Salut

ce post en réaction à un problème qui m'a foutu les boules...

D'abord les faits :

Je mets en place le module de recherche, je le configure, fais mes templates, et je teste, notamment pour voir comment ça se comporte sur le module CGBlog. Tout se passe correctement, dirait-on : j'ai une page dédiée à l'affichage des résultats de recherche, et deux pages pour mon blog : sommaire et détail. Bon. Les résultats de recherche s'affichent correctement, chuis content, puis je clique sur le résultat d'une recherche qui doit me mener sur une page du blog, et là, PAF, le contenu s'affiche dans la page de résultats de recherche et non dans la page de détail du blog.
Je vérifie ce que j'ai configuré, notamment le nom de la page détail dans CGBlog, je désactive les pretty urls au cas où, mais rien à faire.
Je vérifie les paramètres du search et je trouve un paramètre detailurl= qui permet d'indiquer la page dans laquelle les résultats doivent être redirigés pour les modules. Mieux que rien ; j'ajoute donc detailpage="blog-detail" à mon tag {search}, mais rien n'y fait.
Je mets des print_r dans le code du module de recherche, pour chercher à comprendre, j'y passe un bon moment mais ma detailpage n'est pas prise en compte.
Je me dis qu'il doit y avoir un bug, je vérifie et revérifie mes conclusions, pour être sûr, bref, tout comme si j'étais au boulot !
Je vérifie la construction du formulaire de recherche dans le source php, et là surprise ! le detailpage n'est pas utiisé...
Alors j'ai la fine idée d'aller voir sur la forge quels sont les bugs pendants :p de ce module, et là, illumination : detailpage n'est pas traité, ya une fiche de bug avec le code à ajouter pour résoudre le bug, depuis 2011
J'applique la rustine, dans action.default.php et hop, ça marche.

Maintenant la remarque

C'est pas fiable, perte de temps énorme et obligation de tripatouiller dans le source pour faire marcher le module, aucune visibilité du problème à la base... pas cool du tout çà ! je regrette pas mon choix de cmsms, mais ce genre de problème est proprement horripilant ! j'espère que c'est rare et que je vais pas rencontrer çà à chaque fois que je veux faire quelque chose de vraiment propre et fini...

D'autant que la solution utilisée va marcher mais uniquement pour un et un seul module additionnel, puisqu'il n'y a qu'une seule detailpage indicable... à la limite, mieux vaudrait traiter le problème en semi-dur dans le action.dosearch.php pour rechercher la page de détail à utiliser en fonction du module...

Et la question pour finir

Comment traitez-vous ce genre de problème en terme de gestion de sources ?

* Usinagazification n°1. Appliquer la modif dans le source, le noter dans un coin (précisément, dans un document spécifique), et vérifier / reporter les modifs à chaque nouvelle version de cmsms, et en même temps suivre la buglist du (des) modules concernés pour supprimer ma modif lorsqu'elle ne sera plus nécessaire, si cela arrive un jour...

* Usinagazification n°2. Dupliquer tout le module en search2, corriger, et refaire la manip à chaque nouvelle version.

* 3 ???


Messages dans ce sujet

Atteindre :


Utilisateur(s) parcourant ce sujet : 2 visiteur(s)