Appel aux classes Joomla! 4

[RobertG]

J'ai beau tourner virer et me référer à d'autres composants, rien à faire, les boutons de sauvegarde sont toujours sans effet. Un "var_dump" dans la fonction "edit" du fichier "controllers/jt_applications.php" me dit bien que j'y passe lorsque j'ouvre le formulaire de création d'une nouvelle source GedCom, mais les boutons de validation ne renvoient manifestement pas à la fonction "save" du même fichier...
L'annulation fonctionne, pas l'enregistrement :

            ToolBarHelper::title($isNew ? JText::_('JTAPPS_TITLE_NEW') : JText::_('JTAPPS_TITLE_EDIT'), 'application');
            ToolbarHelper::saveGroup(
                [
                    ['apply', 'apply'],
                    ['save', 'save']
                ],
                'btn-success'
            );
            ToolbarHelper::divider();
            ToolbarHelper::cancel('application.cancel');
            ToolbarHelper::divider(); 

[RobertG]

J'ai déjà vu ces pages, mais pas trouvé quoi faire pour que les boutons d'enregistrement fonctionnent.

[starter866]

https://developer.joomla.org/roadmap.html#4

https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4

[RobertG]

Ce qui est pénible, c'est de ne pas avoir d'instructions sur par quoi remplacer ce qui est devenu obsolète et/ou qui doit être modifié.
Par exemple, pour les boutons, si je comprends bien, "annuler" est directement géré par Joomla! en utilisant 'application.cancel' et les boutons d'enregistrement et de sauvegarde par l'application, mais que j'utilise 'apply' et 'save' seuls ou précédés de application, component ou joaktree, ils restent inactifs.
si quelqu'un peut m'éclairer, je l'en remercie par avance.

[starter866]

exemple:

Joomla3

defined('_JEXEC') or die;
JLoader::register('BannersHelper', JPATH_ADMINISTRATOR . '/components/com_banners/helpers/banners.php');

if (count($errors = $this->get('Errors')))
        {
            throw new Exception(implode("\n", $errors), 500);
        }

joomla4

namespace Joomla\Component\Banners\Administrator\View\Banner;
use Joomla\CMS\MVC\View\HtmlView as BaseHtmlView;
defined('_JEXEC') or die;

if (count($errors = $this->get('Errors')))
        {
            throw new \JViewGenericdataexception(implode("\n", $errors), 500);
        }

[starter866]

Concernant les boutons "enregistrer" et " enregistrer et fermer" inopérant et en comparant (dans com_banners) le fichier view.html.php (J3) et HtmlView.php (J4) il y a pas mal de changement),

[RobertG]

Le plus facile est fait !

[starter866]

C'est bon ça fonctionne, aussi bien sur une première installation, ou après désinstallation

[RobertG]

Tu as raison, à moitié seulement.
En testant la désinstallation-réinstallation sur une 3.9 j'ai une erreur de duplicate entry sur la première ligne de la table display_settings :

$update_queries[] = 'INSERT INTO #__joaktree_display_settings (code, level, ordering, published, access, accessLiving, altLiving ) VALUES ("ENGA", "relation", 1, 1, 1, 3, 0)';

Cette erreur n'est pas signalée par la 4.0
Pour gérer la réinstallation si ces tables sont conservées après désinstallation, il ne faut pas utiliser de "INSER INTO" tel quel mais peut-être passer par "INSERT IGNORE INTO". A tester... (ça fonctionne sur une version 3.9)

[starter866]

Ce que je veux dire, c'est que j'ai l'impression que comme certaines table existent, le script s'arréte.

[RobertG]

Dans la mesure où c'est avec la mention "IF NOT EXISTS", il n'y a pas de raison pour que les tables n'existant pas ne soient pas créées lorsque celle-ci est présente, et pourtant en effet, il y a un blocage quelque part lors d'une réinstallation. La table citations est créée, puis plus rien.

Pour la table citations, j'ai été obligé de doubler sa ligne de suppression pour que ça fonctionne. Pourquoi ? mystère !

En supprimant manuellement la table displays_settings, la réinstallation semble bien réinstaller toutes les tables, sauf la dernière, tree_persons : problème de version 4.0 ?
Il faut que j'essaie l'installation/désinstallation de cette version de Joaktree sur une 3.8 ou une 3.9 pour voir, ne m'étant jamais essayé à cette procédure, mais seulement à l'installation et utilisation.

[starter866]

Après plusieurs essais, effectivement, il reste les 5 tables définies dans le joaktree.script.php

// Do not drop tables, because they contain user settings
// $update_queries[] = 'DROP TABLE IF EXISTS #__joaktree_admin_persons ';
// $update_queries[] = 'DROP TABLE IF EXISTS #__joaktree_applications ';
// $update_queries[] = 'DROP TABLE IF EXISTS #__joaktree_display_settings ';
// $update_queries[] = 'DROP TABLE IF EXISTS #__joaktree_themes ';
// $update_queries[] = 'DROP TABLE IF EXISTS #__joaktree_trees ';

La table citations a étét bien effacée à chaque test.

Dans la table extensions de joomla, le composant est bien supprimé ainsi que dans la table menu de joomla.

Par contre en cas de réinstallation du composant (sans supprimer les tables restées manuellement) les fichiers sont bien installé mais pas les tables.

D'ou ma question.

Le fait que le script d'écriture des tables commence par

// Table joaktree_admin_persons
            $update_queries[] =
                'CREATE TABLE IF NOT EXISTS '
               .'#__joaktree_admin_persons '

et que cette table existe (puisque non supprimer lors de la désinstallation),

ce peut il que cela bloque ici ?

N'y aurait il pas une commande pour dire au script de passer à la suivant et ainsi de suite ?

[RobertG]

C'est très curieux !
Je suis passé aux tests sous PHP 7.1 et le comportement est le même que sous 7.0 : installation et création des tables sans problème.
Par contre, à la désinstallation, si je renvoie en fin de fonction un "return true" ou un "return false", voire pas de return" du tout, tout est bien désinstallé (sauf les 5 tables préservée, mais aussi cette table "citations" qui résiste), mais la référence au composant dans la gestion des extensions reste présente. Si par contre je renvoie "return $retval', j'ai une erreur affichée "undefined variable" mais l'entrée dans la table des extensions est bien supprimée !

J'ai hâte qu'Akeeba backup ait une version compatible 4, pour éviter un gros crash... et la toute dernière version de JDump n'est pas encore compatible 4.0 (jusqu'à prsent, comme je l'ai dit plus haut var_dump (ou print_r) ne m'ont strictement rien affiché lorsque j'avais de grosses erreurs.

[RobertG]

Bien, après de nouveaux essais, je confirme que tes lignes pour la récupération de la version sont correctes sous PHP 7.0, je ne sais pas pourquoi elles ne fonctionnaient pas lors de mon premier essai (sous PHP 7.1).
Pour les tables, Niels avait prévu d'en conserver, voir la dernière ligne de message dans le code. mais en fait, il y en a 6 qui restent lors de mes tests... #__joaktree_citations est conservée alors que c'est la première listée à supprimer.
J'ai eu une erreur de désinstallation, malgré l'ajout d'un return true à la fin de la fonction de désinstallation (après enqueueMessage) et une modifications des $application->enqueueMessage par JFactory::getApplication()->enqueueMessage
A la fin de la désinstallation :

Return value of Joomla\CMS\Installer\Adapter\ComponentAdapter::fin aliseUninstall() must be of the type boolean, null returned

La désinstallation se fait bien, en dehors de cette table "citations" et de ce message, mais le composant reste présent dans la liste des extensions (je n'ai pas encore cherché pourquoi, mais c'est peut-être à cause de cette erreur).
Fonctionnement identique sous PHP 7.1

[RobertG]

Merci d'avoir trouvé cette solution !
Par contre, je ne comprends pas pourquoi il est impératif que la version soit 1.5.3 (en dehors du fait que c'est la version la plus récente gérée actuellement au niveau de la création, en cas de première installation, ou de mise à jour pour les ajouts/modifications au niveau des tables).
Pour la désinstallation, il est fort possible que la liste des tables soit incomplète, pour expliquer que certaines soient conservées.

Pour les boutons, je l'ai aussi constaté et en comparant le code avec la page des contacts par exemple, au lieu de "apply", j'ai trouvé "contact.apply" et donc imaginé qu'il faudrait peut-être utiliser "joaktree.apply", mais ayant eu d'uatres erreurs, je ne m'y suis pas arrêté.
Bref, il y a du boulot en perspective !

Ce serait bien aussi que les développeurs ne se contentent pas de nous signaler qu'une fonction est devenue obsolète voire inutilisable, mais nous disent par quoi la remplacer...

Edit : problème, ce code pour récupérer la version est celui de la version précédente, pour Joomla! 3, et a planté la première fois que j'ai tenté l'installation. Je vais réessayer...