Joaktree pour J4/5, voire 6 ! à venir ? (ça avance...)

[Fred2FR3]

https://www.w3schools.com/howto/howt...ve_element.asp ?

[RobertG]

Ce type de paramètre est défini dans du code JS d'origine Mootools qui n'est manifestement pas lu ou qui ne s'applique plus aux boutons en question. J'ai reproduit du code comparable dans la partie JS que j'ai ajoutée et qui fonctionne pour d'autres points, mais "active" ne s'ajoute pas à la classe comme voulu...

[Fred2FR3]

Tu as jeté un œil la dessus aussi ? : https://mootools.net/more/docs/1.0.2/Fx/Fx.Accordion

[RobertG]

Mootools n'est plus utilisé par Joomla! depuis un bon moment.
Et je n'ai pas trouvé de tuto pour convertir vers JQuery. Même un site spécialisé utilisant l'IA n'a pas été capable de traduire le tout début du script "jtAccordion = new Fx.Accordion" alors qu'il a pu me donner des équivalents pour le reste.

[RobertG]

En attendant, je cherche à régler cette question de mise à jour de structure de table. Dans la première version pour J3 de Joaktree, que Niels avait nommée 1.5.0, lors d'une mise à jour de la version, l'ajout d'un champ se basait sur une ancienne version que des utilisateurs de la version pour J2.5 n'avait pas atteinte, étant encore en 1.4.4 si je ne me trompe, donc leurs tables ne sont pas à jour, champ 'cat_id' absent

            switch ($old_version) {
                case '1.5.0.beta.1' :
                            switch ($new_version) {
                                case '1.5.0.beta.2': // continue
                                case '1.5.0.beta.3': // continue
                                case '1.5.0':          // continue
                                         // Table joaktree_trees
                                        $update_queries[] =
                                            'ALTER IGNORE TABLE '
                                           .'#__joaktree_trees '
                                           .'ADD catid           int(11)                   NULL '
                                           .'AFTER  root_person_id ';      
                                        // end: joaktree_trees
                                        break;
                                default: break;                                
                            }
                            break;
                            
                default:    // continue
                            break;
            }
​

Je n'arrive pas à trouver comment forcer cet ajout pour les versions antérieures à '1.5.0.beta.1' qui migreraient en 2.0.0 si j'arrive au bout de ce projet.
Y a-t-il, sachant que c'est du texte provenant d'un champ varchar de la base, un moyen d'inclure les versions antérieures à cette 1.5.0.beta.1 ou y aurait-il une requête possible pour tester le champ et si besoin l'ajouter ?

PS : en réalité, dans les versions suivantes jusqu'à la 1.5., j'ai ajouté d'autres champs via d'autres requêtes en me basant sur le même principe ancienne vers nouvelle version, me basant sur mes propres sites qui évoluaient et ceux de deux ou trois autres utilisateurs. Grosse erreur, ii me semble pour qui passerait de 1.5.0 ou inférieur à 1.5.3 puisque les ajouts en 1.5.1 et 1.5.2 ne seraient pas exécutés.
Je me demande donc s'il serait possible de gérer cette mise à jour avec un "$update_queries[]" de chaque ajout dans un try catch, sachant que lorsque le champ existe, MySQL renvoie une erreur.
Toute la création puis mise à jour passe par deux fonctions de création et d'update, et c'est cette partie update sur laquelle je butte...

[RobertG]

Bien ! après bien des prises de tête et l'aide de cavo789 dans cette discussion : https://forum.joomla.fr/forum/d%C3%A...cture-de-table
l'import des données de GedCom semble bien avancer, bien que le message signalant sa fin ne s'affiche pas, peut-être en lien avec les ID de source et d'arbre.
Restent par ailleurs plusieurs fonctionnalités de création/modification de sources et d'arbres qui génèrent des erreurs actuellement incompréhensibles...

Actuellement, l'affichage côté site est fonctionnel sur une version 5.2.0 beta 2 et PHP 8.3, à condition d'activer les cookies dans la configuration de l'extension. La réécriture d'URL ne pose pas de problème de fonctionnement, mais certaines adresses ne sont plus réécrites comme en version J3.
Une fois identifié avec des droits de gestion, la création, la modification et la suppression de données depuis le site ne fonctionnent pas, faute de pouvoir pour le moment déterminer la cause du non-affichage des formulaires correspondants.

[RobertG]

En travaillant avec une nouvelle source ajoutée directement depuis la base de données, l'import se fait bien, mais l'info de fin de traitement n'apparaît toujours pas.

Il me faut maintenant sélectionner un individu à associer à l'arbre correspondant à la source de données. Pour ça, un lien ouvre une page (en pop-up en J3 mais en simple page de type component en J5, et du code JS spécifique affecte les valeurs correspondant à l'individu choisi, ce code qui utilisait Squeezebox de Mootools est maintenant inopérant, et la classe "modal" que le lien dans la page d'appel de la liste d'individus utilise n'a plus que l'effet de cacher le titre du bouton... Si je supprime la classe, le titre est bien affiché, la nouvelle page s'ouvre en grand, mais je ne peux pas la fermer en sélectionnant une personne.
Le fichier intègre "HTMLHelper::_('bootstrap.modal', 'a.modal'); "

Auriez-vous une idée de comment gérer cette migration ?

[RobertG]

Bonjour,

Il y a tant de choses à régler que ça me permet de passer de l'une à l'autre !

J'ai avancé côté site où les données sont correctement affichées. Les modules et plugins (sauf celui de recherche standard que je n'ai pas testé mais qui ne provoque pas d'erreur lors de son édition) fonctionnent.
En revanche, je suis toujours bloqué pour cette modification en frontal. Je laisse pour plus tard.

Dans l'administration, après avoir réussi, en modifiant le type de certains champs de la base, à obtenir un import qui paraît complet mais qui est assorti d'une absence d'affichage de dates sur le site, ce qui demande de reprendre l'exploration de cet import, j'ai mis le paquet sur la possibilité de créer une source de données : la modification fonctionnait, mais pas la création qui fermait le formulaire sans enregistrer. Avec JDump (que j'avais modifié pour pouvoir l'utiliser sous J4 et J5), j'ai pu obtenir la cause de cette erreur : un champ de table qui n'avait pas de valeur par défaut.
Je vais donc pouvoir repartir sur un tout nouveau site et de nouveaux tests, le gros problème étant cette différence entre les enregistrements sans problèmes en J3 contre ceux bloqués en J4/5 pour des questions de type de champ ou de valeur par défaut non définie.

Je ne suis quand même pas au bout de mes peines...

[RobertG]

Vraiment démoralisant de n'avoir aucun interlocuteur codeur qui puisse m'indiquer des pistes...

Ma question concernant le fonctionnement de gestion de formulaires en frontend qui échoue en MariaDB 10 alors qu'il fonctionne en MariaDB 11, posée ici et sur deux autres forums dont celui de joomla.org a été vue environ 150 fois à cette heure, sans la moindre réaction...

Peut-être celle-ci aura-t-elle plus de succès ? Dans le code, je rencontre des lignes de ce type dont j'imagine qu'il s'agit d'inverser la valeur , est-ce bien le cas ?

$query->set(   ' living = !living ');

J'ai dit que j'avais réussi à importer les données GedCom, c'est exact mais par défaut, tous les individus sont créés considérés vivants, et plus tard dans l'import, en fonction de leur date de naissance et de décès ou information permettant de les déclarer décédés, la valeur de "living" passe de 1 à 0. Cette deuxième phase n'est pas fonctionnelle, avec comme inconvénient que tous les individus étant considérés vivants, la confidentialité veut que pour un simple visiteur toutes les dates et cartes associées aux individus sont masquées, et qu'il faut donc être identifié pour y accéder. Il me faut donc comprendre pourquoi ce champ ne prend pas sa valeur réelle et donc savoir si cette syntaxe est correcte ou s'il faut en utiliser une nouvelle.
Merci de vos conseils !

[pmleconte]

Bonjour Robert,

Je ne connais pas cette syntaxe, cependant, j'ai vu quelque chose du type = NOT : voir https://ourcodeworld.com/articles/re...olumn-in-mysql

Pascal

[RobertG]

Bonjour et merci Pascal,

j'ai trouvé simple : living = abs(living - 1); ce qui doit donner le même résultat que NOT.
Pour le moment, ça ne change rien à l'import, il faut que je comprenne pourquoi la mise à jour des lignes ne se fait pas...

[pmleconte]

Tu as réussi à créer l'éternité. Trop bien

[pmleconte]

As-tu l'environnement nécessaire pour deboguer ?

[RobertG]

Non, je n'ai que echo, var_dump et dumpVar (de JDump que j'avais adapté à J4).
J'ai essayé de comprendre ce que Visual Studio Code et autres pourraient m'apporter, mais c'est trop compliqué pour moi, je n'ai plus la force...

[pmleconte]

Je t'ai envoyé un message en MP