Différence de comportement entre serveurs comparables

[RobertG]

Bonjour,

Ne sachant trop où ouvrir cette discussion, je le fais ici.

Je constate des anomalies dont les causes m'échappent. J'en ai parlé avec Localise, peut-être aussi avec JDump.

Pour JDump, quel que soit le site sur serveur distant, l'affichage de da page explicative génère une erreur d'affichage 404. Sur Wampsever 64, avec la même version de MariaDB, aucune erreur. Idem avec uWamp (autres paramètres).

Idem pour Localise : tous les sites distants bloquent le remplissage de deux listes de filtres nécessaires à l'affichage des fichiers à traduire (les données reçues sont vides). En local, avec la même configuration, les données n'arrivent pas vides et donc s'insèrent bien dans les listes déroulantes

J'ai beau chercher, je ne comprends pas ce qui peut expliquer cette différence !

Quelqu'un aurait-il une idée ?

[RobertG]

Je m'enfonce !

Pour J!dump, sur le serveur distant, j'ai cette erreur 404

Affichage introuvable [nom, type, préfixe] : about, html, Administrator

Et en local, si je fais un var_dump sur les trois variables au niveau où se produit l'erreur en ligne, mais où l'affichage se fait correctement, les infos sont :

D:\wamp64\www\Joomla_4.0.0-rc3-dev\libraries\src\MVC\Controller\BaseController.ph p:889:string 'about/html/Administrator' (length=24)

Les valeurs sont bien les mêmes, mais là encore sur l'un la vue peut être créée, sur l'autre pas...

Mais pourquoi ???

[daneel]

Bonjour,

Je ne doute pas que les configurations de joomla, du fichier htaccess et la liste des extensions sont identiques.
Les droits sur les fichiers, les chemins vers log, tmp sont parfaitement configurés donc je te propose de vérifier les points suivants :

1. A titre de comparaison, tu utilise quelle version de php ?

2. Tu as bien les mêmes modules php installés localement et sur serveur distant (gd, sqlite3, mbstring, curl...) ?

3. Autre source d'erreur possible, on peut avoir des différences sur serveur distant car l'hébergeur sécurise un peu plus sa configuration notamment avec un pare-feu applicatif.
C'est le cas par exemple avec modsecurity que l'on retrouve assez souvent et peut poser de problème à certaines extensions joomla.
C'est assez rare mais quand on assure le support ou le développement, cela fait parti des problèmes que l'on peut rencontrer.

et tu peux vérifier en désactivant modsecurity (ou autre) temporairement depuis le gestionnaire de l'hebergeur (quand c'est possible)


Il ne faut pas négliger les logs serveur si cela peut me permettre d'avoir plus d'informations.

[RobertG]

Merci Yann,

Je ne suis pas rentré dans les réglages, mais sur deux serveurs distants chez PlanetHoster et un chez Nuxit, et une flopée de sites, quelle que soit la version de PHP de 7.3 ou 7.4 jusqu'à 8.0.7, le problème est le même : J!Dump n'affiche pas sa page d'informations, avec le message cité ci-dessus, malgré les mêmes infos transmises pour l'affichage de la vue, et Localise ne peut pas récupérer les infos de deux listes déroulantes alors que pour une troisième les données ne sont pas vides, ce qui fonctionne parfaitement sur mon serveur local sans aucun paramétrage.

Que ce soit pour J!Dump ou localise, ce sont des bugs dont je parle depuis pas mal de temps.

Sur un serveur où c'était possible, j'ai désactivé modsecurity et testé sur un site créé il y a quelques heures : non seulement les choses ne s'arrangent pas, mais pire, la tentative d'ouverture de la page de J!Dump est inactive, je reviens après rafraîchissement sur la page où j'étais au moment du clic.

[daneel]

ok,

Désolé, je ne peux pas aller plus loin car je n'utilise pas j!dump, je suis resté
à une configuration avec xdebug, clockwork et vscodium comme ide.

Pour moi, le projet J!Dump est un peu à l'abandon (2012? 2018?)
et c'est compliqué d'utiliser sur des versions récentes de Joomla (J4RC & nightbuild) et de php.

A moins que tu est une version actualisée que je ne connais pas, je crois me souvenir que Marc avait apporté des modifications pour php 7.
à voir si son fork de J!Dump fonctionne peut--être ( c'est celui que tu utilise ? ) : https://github.com/garstud/jdump
Au mieux, tu peux toujours lui poser la question

[RobertG]

J!Dump fonctionne sous PHP 8 et Joomla! 4, dans une version originale modifiée pars schnuti https://github.com/schnuti/files (version beta1)
Si je me souviens bien, j'ai eu à modifier un setVar par set.
Depuis le tout début de son utilisation, j'ai ce problème d'affichage de la page du composant que n'est qu'une page html de description et de vérification de l'activation de son plugin, avec un bouton pour afficher le popup de résultats (qui est maintenant un onglet). Cette absence d'affichage complique l'accès au paramétrage, accessible seulement depuis celui d'un autre composant, mais n'empêche pas le fonctionnement, ce qui est déjà un point positif.
Ce que je trouve vraiment étonnant c'est que cette vue peut être générée sans problème en local mais pas en ligne, alors que je n'ai pas rencontré d'autre problème sur d'autres parties de Joomla! ni des extensions que j'ai pu tester.

Et comme je le montre sur l'autre discussion à propos de Localise, en local je récupère bien des données destinées à remplir des listes, mais en ligne une seule liste en reçoit (les deux autres reçoivent une variable ne contenant pas les valeurs à insérer). Là encore, en dehors de paramétrages fins qui pourraient jouer, mais pourquoi sur deux listes et pas la troisième ?
https://forum.joomla.fr/forum/d%C3%A...-pour-joomla-4

PS : en fait, puisque sur les mêmes versions de PHP et de MariaDB d'un côté ça fonctionne, de l'autre pas, je me pose la question de quelque chose dans le code qui en serait la cause. Pour J!Dump, c'est au niveau de la fonction du noyau createview que l'erreur se produit en ligne. Mais les infos transmises à la fonction sont les mêmes qu'en local : about, html, Administrator. Mon problème est de trouver ce que cette fonction récupère qui, comme pour Localise, renverrait de quoi faire que createview donne une valeur 0 signe de non-création de la vue et déclenchant ensuite le message d'erreur 404.

[RobertG]

En regardant dans la console pour JDump en ligne, je vous cette note dans les entêtes de la page du composant (qui doit donc afficher le fichier html explicatif mais renvoie une erreur 404 :

Upgrade-Insecure-Requests

1

A tout hasard, j'ai fait une recherche d'un éventuel appel à une adresse en "http://" mais je n'en ai trouvé aucun.

[RobertG]

Bonjour,

J'avais en fait essayé la version de garstud et je viens de le refaire. Elle plante le site avec une erreur 500 car il existe maintenant dans les fichiers du noyau de la 4 une fonction dump

/Compile Error: Cannot redeclare dump() (previously declared in libraries/vendor/symfony/var-dumper/Resources/functions/dump.php:18)

C'est pour cette raison, et faute d'avoir réussi à corriger moi-même que je suis passé à la version de schnuti pour J!4.

[RobertG]

Bien, j'ai repris le J!dump de Marc et fait pas mal de modifications pour essayer d'utiliser au mieux les "use" et changer certains appels comme JFactory en Factory.
La page explicative s'affiche sur le serveur distant, contrairement à la version de schnuti. Le bouton "popup" ouvre bien un popup.
Pour éviter un conflit avec la fonction dump maintenant intégrée, la fonction "dump" du plugin a été renommée en "dumpVar" comme dans le plugin de schnuti.

Mais les premiers essais d'affichage de valeurs avec dumpVar (ou simplement de message avec dumpMessage) plantent avec l'info

Call to undefined function dumpVar()

Le plugin est activé, je n'arrive pas à trouver pourquoi la fonction n'est pas trouvée bien que présente dans le plugin.

[RobertG]

J'ai installé le plugin de la version de schnuti : si les deux sont activés, j'ai une erreur 500 me disant que la fonction dumpVar() est déjà définie, ce qui veut bien dire que Joomla! les reconnaît. Mais avec l'un ou l'autre, lorsqu'un seul est activé, j'ai toujours cette erreur de fonction non définie.

Se pourrait-il que ce soit la position du plugin ? Quoi que je fasse dans la liste "ordre d'affichage", il revient à celle initiale, en milieu de liste...
Si j'insère mon instruction dans mon plugin LazyDbBackup qui est chargé avant celui de Jdump, j'ai bien cette erreur. Si je l'insère dans la page d'affichage des catégories d'articles, je n'ai pas d'erreur, il semblerait donc que ce soit cette position de chargement qui soit en cause.
Il faut donc que je trouve comment changer cette position autrement que dans le plugin, pour le placer au tout début !

Edit : en passant par la liste des plugins j'ai eu plus de réussite que dans la gestion du plugin, l'erreur a disparu. Reste à trouver pourquoi aucun message n'est trouvé...

[RobertG]

Pour le moment, faute d'avoir trouvé la raison pour laquelle les "nodes" ne sont pas créés dans le composant version garstud, je suis reparti sur l'erreur d'affichage de la version de schnuti.

Pour exactement les mêmes paramètres, cette fonction de "libraries/src/MVC/Controller/BaseController.php" retourne bien en local la création de la vue pour la page de résultats (tree) ET pour la page principale (about), mais seulement pour la page de résultats sur le serveur distant :

 protected function createView($name, $prefix = '', $type = '', $config = array())
{
$config['paths'] = $this->paths['view'];
return $this->factory->createView($name, $prefix, $type, $config);
}

C'est donc $this->factory->createView qui ne fonctionne pas de manière identique sur les deux serveurs...

[daneel]

Bonjour,

si tu souhaite avoir plus de personnes intéressées pour participer,
Je te conseille de partager sur github en fork de la version originale
( celle de mathias : https://github.com/mathiasverraes/jdump )

Sans cet échange, je n'aurai pas deviné cette version d'adaptation pour Joomla 4.
Merci !

[RobertG]

Bonjour,

J'ai déjà échangé avec schnuti sur son fork de J!Dump sur Github. Comme il n'a pas reproduit, il a négligé ce problème. J'ai relancé récemment, sans avoir de réponse.

https://github.com/schnuti/files

J'ai réussi à remonter au point 0 de l'erreur de cette version.
Dans le fichier "libraries/src/MVC/Factory/MVCFactory.php", la fonction protected function getClassName(string $suffix, string $prefix) ne trouve pas la classe sur le serveur distant alors qu'elle la trouve en local ! La classe cherchée est :

Joomla\Component\Jdump\Administrator\View\About\Ht mlView

Le fichier ne me semble pas incorrect, en voici le début :

namespace Joomla\Component\Jdump\Administrator\View\About;

defined( '_JEXEC' ) or die( 'Restricted access' );

use Joomla\CMS\MVC\View\HtmlView as BaseHtmlView;
use Joomla\CMS\Plugin\PluginHelper;
use Joomla\CMS\Toolbar\Toolbar;
use Joomla\CMS\Toolbar\ToolbarHelper;
use Joomla\Component\Jdump\Administrator\Helper\JdumpHelper;

class HtmlView extends BaseHtmlView
{

Qu'est ce qui peut faire que cette classe soit trouvée sur un serveur local et pas sur un serveur distant, sachant que pour la définition "namespace Joomla\Component\Jdump\Administrator\View\Tree" qui affiche le résultat, la classe est bien trouvée sur le serveur distant ?

[RobertG]

Bonjour,

Au cas où il y aurait un conflit de nom (j'en doute), j'ai essayé de renommer class HtmlView en class DumpHtmlView, mais Joomla! continue à chercher la classe "HtmlView" et pas "DumpHtmlView".
Je ne comprends pas comment forcer Joomla! à chercher la bonne classe !

Oh punaise ! Je m'en étais douté, mais probablement mal testé. Le serveur distant fait la distinction au niveau de la casse. Le fichier s'appelait "HTMLView.php", le renommer en "HtmlView.php" a fait disparaître le message d'erreur 404 et la page s'affiche.
Je ne sais pas si ça pourrait être un problème comparable pour Localise, mais ça me semble peu probable.

Il faut maintenant que je comprenne pourquoi le bouton censé ouvrir les résultats dans un popup le fait dans la page d'administration, et côté site dans un autre onglet..

Trouvé : en changeant le mode d'insertion du bouton (en prenant exemple sur la version de garstud), j'ai bien maintenant un popup qui s'ouvre !

Reste la question de Localise.

[RobertG]

Pour ce qui est de Localise, pour le moment, impossible de comprendre pourquoi en ligne, ces listes n'obtiennent pas les valeurs attendues alors qu'elles les ont en local.