Bonjour,
L’une des dernières stables (3.3.22 je pense) a ajouté la suppression automatique de plusieurs caractères dans le nom des commandes, dont le /.
Ce qui a entraîné un changement de comportement de mon plugin jMQTT, tous les noms de commandes étant définis à partir du topic MQTT.
Exemple:
Le message ayant pour topic ebusd/broadcast/vdatetime et payload {"time":{"value":"23:06:28"},"date":{"value":"06.05.2019"}} créait la commande ayant pour nom broadcast/vdatetime{time}{value} (le 1er niveau de topic ebusd étant commun à l’équipement est supprimé par le plugin).
Depuis la 3.3.22, cela donne broadcastvdatetime{time}{value}.
Ce qui n’est pas dramatique ; mais qu’est ce qui a motivé ce changement ? Je suppose que c’est irréversible ?
Je me pose la question de remplacer le / par un autre caractère (e.g. |, >, : qui restent acceptés) mais je voudrais choisir un caractère qui soit pérenne. Un conseil ?
Merci d’avance pour les réponses.
Bonjour
Effectivement il y a plus de caractère interdit c’est du a un bug lors du passage de #id# au nom de la commande dans un json ou forcément dans ce cas il n’y avait pas de banalisation des caractères interdit et donc cela me donné un json invalide
Bonjour,
Pourrais tu me pointer le code ou la manière de reproduire le problème que tu cites?
J’aimerais vérifier qu’avec le nouveau caractère de séparation que j’ai choisi il n’y a pas de problème.
Regarde dans core/PHP/utils.php a la fin du fichier il y a la fonction de nettoyage de caractère
J’avais bien vu cette fonction de nettoyage.
Mais j’aimerais reproduire le passage de #id# au nom de la commande dans un json pour vérifier que le json reste bien valide avec le caractère que je vais choisir. Comment faire ou dans quelle fonction ça se passe?
C’est au core de garantir ça… Après tu fais json_encode d’un tableau avec ton texte et si devant ton caractère tu as un / ou \ ben c’est pas bon
Parfait merci, çà marche la vérif via json_encode.