Tentative de migration d'un composant en J! 4

[RobertG]

Bonjour,

J'ai un problème de repérage de fichier/ligne de code à propos d'une erreur bloquante (tentative d'adaptation d'un composant à J! 4) : une variable arrive incorrectement et je ne trouve pas comment remonter à sa génération.
Le message s'affiche

0 A query must be a string or a Joomla\Database\QueryInterface instance, a SimpleXMLElement instance was given.

La ligne concernée est

$db->setQuery($query);

Ce qui est curieux, c'est qu'un echo placé par l'auteur initial juste au-dessus de cette ligne n'affiche rien, pas plus qu'un var_dump
Comment Xdebug pourrait-il faire mieux qu'un print_r par exemple, ou qu'un dumpVar de Jdump ?
J'ai essayé de faire suivre cette ligne de débogage par

var_dump(debug_backtrace());

après avoir regardé la manuel PHP, mais rien ne s'affiche.
Si par contre j'utilise

dumpVar ($query, " Lookup Qry <br/>");

j'ai bien une interception de la valeur de $query, mais je ne sais pas comment interpréter le message d'erreur (pourquoi un SimpeXMLElement object ?) :

backtrace me renvoie via Jdump un tableau de 20 lignes avec des noms de fichiers et lignes concernées, mais que je ne sais pas mieux interpréter !

Pouvez-vous me conseiller ?
Merci d'avance,
Robert

[roland_d_alsace]

Hello Robert.

Comme l'indique le message $query est mal composé.
Ce doit être soit une chaine soit une instance de JDataBaseQuery (query interface).

Là tu as une instance xml ou quelque chose comme cela (voir le code de ta fonction dumVar, car c'est étrange que le var_dump ne donne rien).

Regarde :
https://api.joomla.org/cms-3/classes...ethod_setquery

Il est bien dit :
$query mixed
The SQL statement to set either as a JDatabaseQuery object or a string.

Dans tous les cas, il y a quelque chose qui a du changer en amont.

Là il semblerait que tu ais une classe, avec une propriété 0 et des méthodes (probablement une instance de type simplexmlelement, mais je ne connais pas la fonction dumpVar que tu utilises).

Ta chaine sql semble être dans $query->0 ??

Le code serait donc plutôt :

$db->setQuery($query->0); 

Mais même si cela fonctionne, je ne l'utiliserais pas, car comme dit plus haut, il doit y avoir un autre problème dans le code.

[RobertG]

Merci Roland !

Le problème est justement de remonter.
Pour cette erreur-ci, cela venait du fait que la variable récupérant le SQL n'était pas en "(string)" mais brute. Pourquoi est-ce que ça ne posait pas de problème en J3??? Une fois corrigé, l'erreur change (sur getErrorNum : 0 Call to undefined method Joomla\Database\Mysqli\MysqliDriver::getErrorNum() , réglé)... Mine de rien, ça avance !

J'oubliais : JDump est une extension permettant d'avoir dans un pop-up ou onglet le résultat d'affichages type var_dump (dumpVar), du système, de messages et aussi de backtrace (je l'ai découvert hier). Matthias Verraes sur Github pour J! 3 https://github.com/mathiasverraes/jdump et adaptation à J! 4 par schnuti https://github.com/schnuti/files
Il me permet d'avoir des infos que var_dump ou print_r ne renvoient pas lorsque L! 4 renvoie une erreur 0.

[RobertG]

Bonjour,

Ce sur quoi je butte aujourd'hui est un "nettoyage" de texte intempestif.
Je devrais avoir dans l'adresse "file=1|fr-FR|g.general|com_actionlogs.ini" (ce qui est le cas en J! 3 mais aussi plus tôt dans le code J! 4) mais la variable "$file" arrive débarrassée des "pipe" dans une fonction dont le rôle est de récupérer via un explode sur ces pipe les différents constituants de cette chaîne.
Pour le moment, impossible de trouver où ce nettoyage intempestif se produit !

Je n'ai pas précisé plus haut, mais faute d'arriver à faire fonctionner sur mon site de test "Localise" et d'être capable de trouver où il faudrait intervenir dans son code, l'extension que je tente d'adapter à J! 4 est "FSJ Translate Manager Pro" abandonné il y a plusieurs années par son auteur, extension que j'ai longtemps utilisée pour les traductions d'extensions et la génération de packs d'installation de fichiers de langue.

Ce que j'essaie de comprendre c'est pourquoi cette ligne renvoie la valeur sans pipe alors qu'en J! 3 JRequest la renvoie avec

$file = JFactory::getApplication()->input->get('id');  //JRequest::getVar('id');

[roland_d_alsace]

Hello.

Le filtre appliqué par défaut est CMD (donc pour les variables d'url standards).

CMD = Allow a-z, 0-9, underscore, dot, dash. Also remove leading dots from result.
Donc le pipe ne passe pas.

Si tu ne veux aucun filtre il faut utiliser RAW en 3ème parametres de la méthode get de Jinput.

Voir : https://docs.joomla.org/Retrieving_r...a_using_JInput

Je ne pense pas que cela ait changé sous J4.

[RobertG]

Merci Roland,

Ce que je ne comprends donc pas, c'est pourquoi je récupère parfois la valeur avec et d'autre fois sans pipe... ce que corrige en effet l'utilisation du filtre "raw".
Maintenant, je me retrouve avec une fenêtre modale jQuery si j'ai bien compris, avec curieusement une erreur 403 sur l'accès à un fichier image, le reste de la fenêtre étant blanc et vierge, empêchant de voir la page au-dessous, qui contient toutes les chaînes et leur valeurs...
La console signale que plusieurs fichiers js présents dans le dossier de la librairie du composant ne peuvent être chargés, erreur 403 comme poour l'image, avec en entête "strict-origin-when-cross-origin".

[RobertG]

Nouvelle incompréhension ! J'ai masqué le pop-up pour avoir accès à la traduction du fichier. (en version J! 3, pas de pop-up à l'affichage, il n'y en a que pour signaler la nécessité d'enregistrer)
L'adresse de la page est

administrator/index.php?option=com_fsj_transman&view=file&file=1|fr-FR|g.general|com_fsj_main.ini

Je veux récupérer le contenu de "file" pour enregistrer les modifications :

 $file = Factory::getApplication()->input->get('file','','raw');

dumpVar ($file) me dit que ce contenu est

1fr-FRg.generalcom_fsj_main.ini

Qu'est-ce qui peut expliquer ce résultat alors que je récupère la valeur correcte lorsqu'elle est liée à "id" dans une adresse

administrator/index.php?option=com_fsj_transman&task=file.edit&t mpl=&id=1|fr-FR|g.general|com_fsj_main.ini

[RobertG]

Bonjour,

Je tourne en rond !
Si je tente de récupérer en PHP l'adresse de la page en cours, je n'ai pas les paramètres, uniquement "administrator/index.php".
Pourtant, si je cherche la valeur de l'option avec input, je récupère bien "com_fsj_transman", mais je n'ai aucune valeur pour la suite. Plus perturbant pour moi, la recherche de "task" qui n'est pas dans l'adresse de la page me renvoie bien "apply" qui correspond au bouton d'enregistrement.
Comment pourrais-je visualiser la totalité de l'adresse réellement utilisée par Jinput ?

Si j'utilise getArray, je récupère ces infos :

[string] file = "1fr-FRg.generalcom_fsj_main.ini"
[string] header = ""
[string] option = "com_fsj_transman"
[string] strings = "{}"
[string] task = "apply"

Et si je vais voir dans le JS qui traite "apply",

data.file = jQuery('#form_file').val();

me renvoie aussi "1fr-FRg.generalcom_fsj_main.ini"
Impossible pour le moment de savoir où ces pipe ont été supprimés !

Edit : jQuery n'était pas chargé, une fois fait, je récupère la valeur correcte de "file", et j'arrive au problème suivant de la récupération des chaînes et valeurs...

[RobertG]

Bon, il y a certainement encore du travail : onglets secondaires qui n'apparaissent pas, doutes sur le JS, apparence de certaines pages, gestion de l'affichage de cette liste (cliquer pour voir la 2° page affiche la liste complète), plusieurs fichiers JS non chargés qui impactent les filtres de recherche...

Mais la liste est correcte et fonctionnelle, la création des nouveaux fichiers est correcte (avec les noms non précédés par le tag de langue), leur enregistrement est correct.

Bref, FSJ Translate Manager Pro, bien que bancal, est tout à fait capable de générer les fichiers de langue (placés dans les dossiers language et ne comportant pas le tag de langue au début du nom de fichier) sur la version 4 rc2 dev et PHP 8.0.6 en ligne, 8.0.7 en local.

Il me faut voir maintenant la question de la création des packs d'installation, en espérant que je ne butte pas sur du JS...

[RobertG]

Bonjour,

Pour les packs d'installation, ce n'est pas gagné ! Impossible de créer une définition de package, seul le bouton d'annulation est fonctionnel. Comme déjà dit, il y a des erreurs JS visibles dans la console, mais que je ne suis pas capable de gérer actuellement.

Je me suis donc attaqué à d'autres fonctions en commençant la gestion des options. Premier souci, les onglets. Pour la page d'options de Translate Manager, celui des permissions est inaccessible, mais je devrais trouver comment corriger, si je trouve de la doc et des exemples. Idem pour le composant maître qui comporte 3 onglets dont seul le contenu du premier est visible.
Ce que je ne comprends pas, c'est un message d'erreur lorsque je valide :

0 You have not supplied a valid HTTP status code

Or la ligne concernée est (après définition de $mainframe) :

$mainframe->redirect(Route::_("index.php?option=" .$this->_comname,false), $msg, 'message');

Si je supprime ", $msg, 'message'", l'erreur disparaît; Est-ce à dire qu'il me faut dissocier l'affichage du message, que cette syntaxe n'est plus valide ?

Merci d'avance !

PS : j'ai ceci qui est incorrect d'après la console (document.id is not a function), dans la tentative de validation de création de la définition d'un pack :

Joomla.submitbutton = function(task) {
if (task == 'package.cancel' || document.formvalidator.isValid(document.id('item-form'))) {
Joomla.submitform(task, document.getElementById('item-form'));
} else {
alert('Formulaire invalide');
}
}

Le remplacement de document.id par document.getElementById corrige

[RobertG]

J'avais été confronté à une erreur du même type, liée à une adresse erronée, mais avec cette extension, j'ai plusieurs fichier JS bloqués avec ce message :

La ressource à l’adresse « https://********.fr/libraries/fsj_co...j/fsj.admin.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff). index.php

Le fichier existe bien, son code commence par

jQuery(document).ready(function () {

Je n'ai pas trouvé quoi faire pour corriger. Même la désactivation de cette condition dans le plugin HTTP headers n'a pas d'effet positif...