Les bugs (core, modules) non corrigés - Comment les traitez-vous ?

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - Version imprimable

+- Forum CMS Made Simple FR (https://forum.cmsmadesimple.fr)
+-- Forum : Général (https://forum.cmsmadesimple.fr/forum-3.html)
+--- Forum : Général (https://forum.cmsmadesimple.fr/forum-10.html)
+--- Sujet : Les bugs (core, modules) non corrigés - Comment les traitez-vous ? (/thread-2364.html)

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - didjeko - 14/11/2012

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 ???

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - jce76350 - 14/11/2012

Cela aurait été bien de respecter la charte et de donner les éléments demandés
Wink

Citation :Alors j'ai la fine idée d'aller voir sur la forge quels sont les bugs pendants 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

Ha oui c'est une bonne idée d'aller voir voir sur la forge, déjà pour vérifier sa version !

sans élément précis de ta part on peux supposer que
tu parles du [#7327] parameter "detailpage" not working with the default action ???
qui est traité depuis le ; Date: 2012-05-03 11:50 par calguy1000 qui est le développeur qui tient le plus à jour ces modules et la dernière version est la 1.9.8 Released On: 2012-06-03 19:01

pour le reste de ta prose ...

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - didjeko - 14/11/2012

Mes éléments sont les mêmes que ceux de mes autres posts ; j'étais en dernière version, ça n'a pas changé. Le module manager me dit qu'il n'y a aucun module à mettre à jour, d'ailleurs.
Je parle du bug trouvé ici, #6018 Search module.
Ce que je ne comprends pas, c'est que ma version du search est 1.7.7, qui est installée avec cmsms version 1.11.2.1.
Et dans l'archive cmsmadesimple-1.11.2.1-english.tar.gz, sur le site officiel, c'est bien la version 1.7.7 qui est fournie (je viens de revérifier dans l'archive).

Le reste de ma prose pose de bonne questions.
Notament celles-ci :
Comment peut-on deviner que la version officielle ne contient pas la dernière version du module search ?
Dans dev.cmsmadesimple.org :
- le module search n'apparaît pas dans la liste alphabétique des modules
- en cherchant 'Search', on trouve un lien sur le serch module qui indique que la dernière version est 1.5.4 (2009-03-17).
- L'onglet Bug Tracker donne 2 bugs :6018, 8239.

Même avec toute la meilleure volonté du monde, comment s'y retrouver ?
accessoirement, où trouver le lien pour télécharger cette version du module ?

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - didjeko - 14/11/2012

D'ailleurs, les versions en téléchargement en haut de cette page contiennent également le module search en version 1.7.7 Big Grin

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - didjeko - 14/11/2012

J'ajoute, parce que j'apprécie moyennement ce ton mi-agacé mi-supérieur de petit chef de bureau :
- que j'ai pas attendu que tu me le dises pour vérifier et savoir vérifier mes niveaux de version, alors c'est pas la peine de te comporter comme si tu étais le seul à le savoir
- que je vois pas pourquoi ni sur quoi tu te fondes pour supposer que ma version n'est pas à jour
- que l'info V 1.11.2.1 placée dans mon post suffit, puisqu'ayant installé cette version j'ai de fait les modules du core qui sont livrés avec,
- qu'avoir le n° de version du search n'aurait servi à rien puisque, si tu es en 1.11.2.1, tu as forcément la v1.7.7 de search,
- que si tu avais lu la fiche de bug que tu cites en référence tu aurais sûrement noté que le bug est toujours ouvert, donc que la modif n'est pas disponible ; en l'indiquant sur ton post, au moins, ça aurait servi à quelque chose
- que si tu avais vérifié dans une installation de la dernière version avant de poster, tu te serais rendu compte de la véracité de mes dires.

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - isa46 - 14/11/2012

Ah! le module search moi y m'a planté en pleine instal donc a priori y'a pas grand chose à faire

autrement pour charger un fichier sans changer le core y'a la solution du dossier module_custom qu'on crée à la racine
ensuite on respecte les imbrications des dossiers comme dans le module initial
moi j'avais essayé avec le module news
module_custum-->news--> template-->fichier.php

A creuser

Juste un lien pour voir

un autre lien

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - didjeko - 15/11/2012

mm, ça marche pas pour un fichier source php. J'ai appliqué cette méthode mais c'est toujours le fichier action.dosearch.php du module search qui est appelée, pas celle sous module_custom/Search. Je vais quand même garde le principe pour stocker une copie de mon nouveau fichier ainsi que du fichier correspondant de la version, suffixé par le n° de version cmsms par sécurité.

Cela étant, et pour ceux que ça intéresse, j'ai trouvé un moyen temporaire pour résoudre le problème suivant : lorsque le search trouve des résultats dans un module "cherchable", comment faire pour que, lorsqu'on clique sur le lien de résultat de recherche, la page s'affiche dans la page détail correspondant au module ?
Une modification de "detailpage" dans le formulaire de recherche ne suffit pas, puisqu'on indique une seule et même page détail, qui sera utilisée quel que soit le module.

Soit la config suivante :
le blog a une page de détail spécifique, de même que les news ont la leur.
Il faut donc pouvoir accéder à cette page pour l'indiquer lors de la création du lien de résultat de recherche, dans le fichier action.dosearch.php, dans le bloc qui suit la ligne 296

Code :
[== PHP ==]

          if ($moduleobj != FALSE)

            {

                     // DEB MODIF

                     // détermination de la page détail suivant le module

             if ($modulename == 'CGBlog') {

                $thepageid = $moduleobj->GetPreference('default_detailpage');

             } elseif ($modulename == 'News') {

                 $thepageid = $moduleobj->GetPreference('detail_returnid');

             }

                     // FIN MODIF

              if (method_exists($moduleobj, 'SearchResultWithParams' ))

A étendre pour chaque module susceptible d'accepter le search et possédant un champ pour une page détail par défaut...

Les bugs (core, modules) non corrigés - Comment les traitez-vous ? - jce76350 - 21/11/2012

Pour information les bugs sur le modules "standards livrés" avec l'archive CMSms
ne sont plus mis à jour sur la forge depuis longtemps .... c'est pour cette raison qu'il ne sont pas à jour individuellement sur la forge
donc si bug avec ces modules il faut aller dans la forge http://dev.cmsmadesimple.org/bug/list/6

Dans la future version majeure les modules standards avec l'archive CMSms seront TOUS inclus dans le core