A propos du composant Localise pour Joomla! 4

[RobertG]

Bonjour,

Pour cesser de mélanger deux discussions, j'ouvre celle-ci concernant le composant Localise (destiné à la traduction des fichiers de langues).
Comme je l'ai dit ailleurs, les champs de filtre, notamment de la partie "traductions", ne se remplissent pas sur l'ensemble des sites hébergés en ligne (que ce soit en PHP 7.4 ou en PHP 8.0), alors que sur un site en local (Wampserver 64) ils sont bien fonctionnels de la 7.3 à la 8.0.7.

J'ai cru que c'était une question de base de données car en local j'étais en MySQL alors qu'en ligne, sur deux serveurs, les bases sont des MariaDB. Mais en passant la base locale en MariaDB, même version que sur un des serveurs, les listes de filtres s'affichent bien.

Faute donc de trouver la cause sur les serveurs distants, j'ai commencé à faire hier des tests en local.
Première constatation : dans la liste des fichiers, seuls ceux du noyau et ceux de Localise sont présents, rien pour Akeeba backup qui est installé sur le site, mais utilise les anciens noms, nécessitant de supprimer "en-GB_" de ces noms pour les voir affichés dans la liste (et "fr-FR_" si une traduction partielle existe).

Deuxième point : tant que je suis en version 7.3 ou 7.4, l'enregistrement des modifications des traductions fonctionne, mais si je passe en PHP 8.0, lors de l'enregistrement s'affiche cette erreur, avec échec de l'enregistrement :

The arguments array must contain 2 items, 1 given

La référence au fichier Text.php, comme on l'a eu pour l'affichage du panneau d'administration il y a quelques temps m'a fait aller jeter un coup d'œil sur le fichier localise.php où il manque une parenthèse fermante

 public static function getPluralSuffixes($count)
{
if ($count == 0)
{
return array('ONE', '1';
}

La correction n'a rien changé à l'erreur.

[jfque]

Il manque aussi l'accolade de fermeture de la fonction, mais c'est peut-être dû au copier/coller qui était incomplet.

[RobertG]

Ce n'est qu'une copie partielle, il y a un elseif et un else qui suivent.

[RobertG]

Bonjour,

Pour ce qui est de l'erreur à l'enregistrement du fichier de langue sous PHP 8, elle ne survient que si le paramètre "Complet" est à "non". Je présume donc que ce paramètre renvoie une valeur vide que PHP 8 n'accepte plus, alors que PHP 7.4 ne signale pas d'anomalie, expliquant l'erreur 0

The arguments array must contain 2 items, 1 given

Trouvé : dans le fichier View/Translation/HtmlView.php ligne 81, $complete revient vide au lieu d'être à "0"

$complete   = (int) ComponentHelper::getParams('com_localise')->get('complete', 0);

en forçant la valeur à "0" dans le "else" ligne 115, l'enregistrement fonctionne sans erreur.

Edit : ce n'est pas ça, après avoir fonctionné sans erreur, j'ai de nouveau l'erreur 0

Edit 2 : l'erreur ne survient pas pour tous les fichiers, mais systématiquement pour le fichier com_localise.ini !

[RobertG]

Bonjour,

A force de recherches, je me suis aperçu que la cause de l'erreur lors de l'enregistrement de la traduction de com_localise.ini était la présence de virgules dans certaines valeurs de chaînes, mais curieusement pas dans toutes.
Après correction de deux valeurs par suppression d'une virgule qu'elles contenaient, l'enregistrement se fait. Je vérifie alors avec notepad++ le nombre de virgules présentes dans le fichier complet et j'en trouve 49 autres dans ces valeurs de chaînes, 49 qui ne déclenchent aucune erreur !

Le problème est que c'est la présence de la virgule dans la référence qui est en cause ? Qu'est-ce qui fait que ceci déclenche l'erreur dans la routine du noyau chargée de découper les chaînes en se basant sur la virgule, mais pas sur toutes ? Exemple :

COM_LOCALISE_NOTICE_GITHUB_FILE_ADDED="A new file <strong>%1$s</strong> present in the Github %2$s branch, has been added to the local %3$s/language/en-GB folder."

Donc si je supprime la virgule après "branch", l'erreur disparaît
Mais encore plus curieux : si j'ajoute une autre virgule juste après "</strong>" en conservant ou en supprimant celle après "branch", dans les deux cas, je n'ai plus d'erreur non plus !

[RobertG]

A la recherche maintenant de la raison pour laquelle les listes de filtres client et develop (fichier com_localise/layouts/joomla/searchtools/default.php), en utilisant var_dump() en local j'ai ceci :

D:\wamp64\www\Joomla_4.0.0-rc3-dev\administrator\components\com_localise\layouts\ joomla\searchtools\default.php:75:string '<select id="client" name="client" onchange="this.form.submit()" class="custom-select"> <option value="" selected="selected">- S&eacute;lection Client -</option> <option value="site">Site</option> <option value="administrator">Administrateur</option> </select> ' (length=264)
D:\wamp64\www\Joomla_4.0.0-rc3-dev\administrator\components\com_localise\layouts\ joomla\searchtools\default.php:75:string '<select id="develop" name="develop" class="form-select" onchange="this.form.submit()"> <option value="" selected="selected">- Select Content State -</option> <option value="complete">Complete</option> <option value="incomplete">Incomplete</option> </select> ' (length=261)

Sur le site distant :

string(219) " " string(223) " "

La variable $tagField->input quant à elle renvoie bien la liste des langues.

Si j'utilise J!Dump pour la variable client, j'obtiens ceci en ligne :

[string] (no name) = "


<input
type="text"
name="client"
id="client"
value=""
class="form-control" list="client_datalist" onchange="this.form.submit()" >



<datalist id="client_datalist">
</datalist>
"

et en local :

[string] (no name) = "<select id="client" name="client" onchange="this.form.submit()" class="custom-select">
<option value="" selected="selected">- S&eacute;lection Client -</option>
<option value="site">Site</option>
<option value="administrator">Administrateur</option>
</select>
"

Pourquoi cette différence ???

[RobertG]

Bonjour,

J'ai eu beau chercher, je n'ai toujours pas trouvé pourquoi les listes client et develop sont vides en ligne, alors que la liste des langues y est remplie, mais que tout fonctionne en local.

[RobertG]

Bonjour,

A force de JDump, j'ai pu constater que lors de l'ouverture de la page des langues ou des traductions, en local on passe par des lignes différentes, supplémentaires en local.
Sur le serveur distant, on passe directement de la lecture du fichier \administrator\components\com_localise\forms\filte r_languages.xml à la fonction

protected function loadField($element, $group = null, $value = null)

du fichier libraries/src/Form/Form.php avec le type "client" et le contenu du champ correspondant dans le fichier XML.
En local, après lecture du fichier XML en question, on passe par la

protected function findField($name, $group = null)

avec comme "$name" le terme "ordercol", puis plusieurs autres fois avant de repasser à la fonction précédente avec le type "text" qui correspond aux filtres de recherche, et enfin le type "client".

La question est donc de trouver pourquoi en ligne toute cette étape intermédiaire est sautée, expliquant la différence de valeur de variable $tagField->input comme cité plus haut, et l'absence de remplissage de certaines listes.

JM, si tu passes par ici !

PS : sur le serveur distant, le code ne passe jamais par les fonctions bind et bindLevel du fichier libraries/src/Form/Form.php (alors qu'il y passe bien en local) mais je n'arrive toujours pas trouver pourquoi.
Je remonte à

 // Trigger the form preparation event.
Factory::getApplication()->triggerEvent('onContentPrepareForm', array($form, $data));

de la fonction

protected function preprocessForm(Form $form, $data, $group = 'content')

du fichier libraries/src/MVC/Model/FormBehaviorTrait.php
Une balise dumpMessage('preprocess end'); placée après cete ligne de code ne s'affiche pas sur le site distant, ce qui voudrait dire que cette ligne échoue ?

[RobertG]

Faute de comprendre dans quel fichier était activé ce triggerEvent, j'ai neutralisé la ligne pour voir. Le code passe alors bien dans les fonctions bind et bindLevel, mais au final, le résultat ne change pas, l'erreur se produit ailleurs.

[RobertG]

Bonjour,

Faute de trouver la différence entre les deux sites, j'ai cloné le site distant en local, la seule différence étant que le site distant est en https alors que le local sur Wampserver est en http. J'ai ensuite récupéré les infos avec JDump lors de l'affichage de la page des langues dans Localise. Voici la comparaison, en haut le site distant, en bas le site local :

La différence est qu'en local, le code utilise un fichier différent : com_localise/Field/ClientField.php, sauf qu'il est orthographié "clientField" dans ce dossier, expliquant, je pense, que Windows le reconnait malgré la différence de casse, mais pas Linux.
La modification du nom fonctionne dans la page des langues ; celle du fichier developClient aussi dans la page des traductions, mais pas celle de translationsclientField.php !

Une idée ?

PS : en fait, il faut que ces fichiers soient nommés ClientField.php, DevelopField.php et TranslationsclientField pour que ces listes ! Pourquoi la fonction "TranslationsClientField" est-elle bien reconnue comme étant dans le fichier TranslationsclientField.php puisque la casse est différente ? Et le problème est-il le même pour les autres fichiers de ce dossier "com_localise/Field" ? En tout cas, la série de filtres de la page "langues" est aussi totalement vide avec la casse actuelle. Faut-il tous les renommer en passant en majuscule leur lettre initiale ?

[RobertG]

Bon, après avoir renommé tous ces fichiers, Localise fonctionne.

Mais dans la page des traductions (liste des fichiers), lorsque je filtre sur "site", j'ai deux fois, en local et en ligne

Warning: Trying to access array offset on value of type bool in D:\wamp64\www\fsjtranslate\administrator\component s\com_localise\Model\TranslationModel.php on line 317
Warning: Trying to access array offset on value of type bool in D:\wamp64\www\fsjtranslate\administrator\component s\com_localise\Model\TranslationModel.php on line 321

Si je comprends bien, cela voudrait dire qu'il y aurait deux fichiers côté site qui ne commenceraient pas par "#" ou ";" mais par une ligne vide. (pour rappel, ces tests sont faits sous PHP 8.0.7)

Ensuite, il faut valider les filtres et rafraîchir, ou cliquer une nouvelle fois sur l'icône "loupe" de recherche pour qu'ils s'appliquent.