Le plugin YAML v2 - commentaires

Le plugin YAML v2

Le plus simple serait utiliser l'option show_error de la fonction pour vérifier si il n'y a pas une erreur dans le YAML.

$configuration = yaml_decode_file($fichier, array('show_error' => true));

Le plugin YAML v2

Voici (ça me permet de synchroniser une table entre mes bases locale et distante)

-
id_activite : '54'
id_matiere : '2'
ref : exoT8-9
date_modif : '201804061600'
type : exo
id_chapitre : '69'
titre : 'Réaction nucléaire'
difficulte : null
pdf_enonce : exoT8-9-E-201804061600.pdf
height_enonce : '165'
pdf_corrige : exoT8-9-C-58856.pdf
height_corrige : '255'
statut : prop
maj : '2023-08-31 15:16:25'
id_rubrique : '15'
id_secteur : null
correction : null
rang_activite : '0'
-
id_activite : '55'
id_matiere : '2'
ref : exoT8-31
date_modif : '201908281510'
type : exo
id_chapitre : '69'
titre : 'cuisson d''un \oe uf dur'
difficulte : null
pdf_enonce : exoT8-31-E-201908281510.pdf
height_enonce : '125'
pdf_corrige : exoT8-31-C-61695.pdf
height_corrige : '120'
statut : prop
maj : '2023-08-31 15:16:33'
id_rubrique : '15'
id_secteur : null
correction : null
rang_activite : '0'
-

Le plugin YAML v2

Tu peux simplement copier-coller le contenu en l'encadre de balises code.

Le plugin YAML v2

le fichier n'est pas passé ?? oui le .txt n'est pas accepté. je tente de changer juste son extension, à transformer en txt après ?

Le plugin YAML v2

oui voici, merci pour l'aide !

Le plugin YAML v2

tu aurais le fichier yaml, car chez moi ca marche :p

Le plugin YAML v2

Bonjour,
j'utilise ce plugin sans problème avec la fonction yaml_decode_file sur un spip4.2 avec php 8.0
Si je passe à une version 8.2 ou supérieure, la fonction n'arrive plus à décoder un fichier yaml.
Mon hébergeur ne maintient la version 8.0 que jusqu'en décembre.
Ce problème est-il connu ?
Cordialement

Le plugin YAML v2

Testé sous Windows avec PHP 8.2 et PECL libyaml installée via https://www.apachelounge.com/viewtopic.php?t=6359 en version 2.2.3 (cf https://github.com/php/pecl-file_formats-yaml/issues/71#issuecomment-1463997670)

Ça marche !

Le plugin YAML v2

La version 3.0.3 corrige cette erreur.
Merci pour le signalement.

Le plugin YAML v2

Bonjour,
Sur un SPIP 4.1 une mise à jour de Yaml v3.0.2 était indiquée. Je l'ai lancée mais je me retrouve avec une page blanche de l'admin avec le message :
Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.1.0".
Ma version de PHP est PHP Version 8.0.28 mais je n'ai pas fait gaffe en lisant la mention
"Une mise à jour {{corrective}} est disponible (3.0.2). "

J'ai récupéré une version 3.0.1, de Yaml vidé tout le cache du site et cela refonctionne.

Autre problème hier sur un autre site : lors de l'installation de Reinette il faut aussi installer Yaml mais apparemment cela ne se fait pas correctement et Rainette retourne une erreur sans s'installer.

Merci

dd.

Le plugin YAML v2

bonjour ,
j'ai passé mon site en spip 4 et ai remis YAml (donc V3.00) et en partie privée , il n'y a pas l'accès classique pour faire ses sauvegardes de config.
merci !

Le plugin YAML v2

Pour info Eric tu avais créé le tag sans mettre à jour le paquet, puis marcimat était intervenu pour mettre à jour le paquet mais sans avancer le tag v2.0.15 qui pointait donc sur la version 2.0.14. J'ai déplacé le tag vers la bonne version...
Mais il semble que plugins.spip.net ne veut toujours pas présenter la v2.0.15 ! C'est peut être un peu le meme pb qu'avec cachelab. Par exemple se pourrait il que les scripts de plugins.spip.net ne gèrent pas le déplacement de tags ?

Le plugin YAML v2

Merci JLuc
Alors pour le PHP, je suis chez free..

Mais je viens de me rendre compte que c'est un autre plugin qui pose le problème (Insérer Modèles ) car j'ai un autre site chez le même fournisseur qui fonctionne très bien et dans les mêmes conditions Spip 3.2 et PHP 5.6 mais le fameux plugin

Bonne journée

Le plugin YAML v2

La version 2.0.14 est adaptée à spip 3.2 cf https://plugins.spip.net/yaml.html?compatible_spip=3.2

Par contre php 5.6 c'est fini depuis janvier 2017 et c'est enterré depuis décembre 2018. Il faudrait gravement mettre à jour.

Le plugin YAML v2

Bonjour,
J'ai un site en php 5.6.34 et spip 3.2
J'ai un problème avec la version 2.0.14 qui est passée obsolète pour la version 3.2.0. ce matin ? mais il n'y a pas de mise à jour sur le site plugins Spip

Merci de votre aide

Le plugin YAML v2

Exact et c'est complètement incompréhensible. Je vais créer un tag 2.0.15 de suite avec la bonne borne.

Le plugin YAML v2

J'ai cru devenir fou en allant voir git... car la borne est bien en 3.0

Mais en fait c'est dans le zip de la 2.0.14 qu'on trouve la borne 3.2 (voir https://git.spip.net/spip-contrib-extensions/yaml/src/tag/v2.0.14/paquet.xml)

Le plugin YAML v2

Bonjour,

Non cela n'a pas été fait. La version n'a pas changé d'intervalle de compatibilité. Qu'est-ce qui te fait dire ça ?

Le plugin YAML v2

Bonjour,
J'ai encore un site en php 5.3.3 donc spip 3.1
J'ai un problème avec la version 2.0.14 qui est passé pour la borne inférieure de Spip de 3.0.0 à 3.2.0.

Y'a t'il une raison technique pour rendre la version 2.0.14 incompatible SPIP 3.1 alors que la 2.0.13 l'était ?

merci

Le plugin YAML v2

Merci pour le conseil et la très pratique page de test.
Cela m'a permit de mettre le main sur le fautif, un obscur fichier yaml dans un plugin tiers dont le rendu était différent entre les 3 libs en effet.

En gros, il manquait deux espaces devant - pour déclarer correctement un sous tableau. :/

Plus je pratique le YAML, plus j'aime le JSON.

Merci encore.

Le plugin YAML v2

Bonjour,

Je ne reproduis pas du tout en passant à la librairie spyc. Peux-tu aller dans la démo

page=demo/yaml

et faire des essais avec les différentes possibilités en navigation à gauche. En particulier, tu peux fixer la librairie à spyc ou autre pour faire des tests.

Le plugin YAML v2

Un petit retour concernant l'utilisation du plugin
SPIP 3.2.3 SVN [24210] + YAML 2.0.10

define('_LIB_YAML', 'spyc')

L'espace privé est complètement cassé (message d'erreur puis page blanche) au point de devoir purger le cache ET renommer le dossiers plugins/ pour reprendre la main.

Fatal error: Uncaught Error: Function name must be a string in /home/ouam/htdocs/spip/plugins-dist/textwheel/engine/textwheel.php:288 Stack trace: #0 /home/ouam/htdocs/spip/plugins-dist/textwheel/engine/textwheel.php(65): TextWheel->apply('---', 'text('



Le plugin YAML v2
tu cliques sur « Mettre à jour » et hop…


Oups. Une erreur inattendue a empêché de soumettre le formulaire. Vous pouvez essayer à nouveau.

etc.


Le plugin YAML v2
c'est à dire ? que se passe-t-il exactement ?


Le plugin YAML v2
Avec SPIP 3.1.2 et YAML 2.0.9 impossible de faire la mise à jour vers la 2.0.10 via SVP.


Le plugin YAML v2
Pour résumer les mises à jour :
 l'exportation produit des fichiers conformes YAML tous équivalents et sans espace en début de ligne. Néanmoins cela ne veut pas dire qu'ils sont tous lisibles par toutes les librairies.
 par contre je ne reproduis pas ton souci sur l'édition des formulaires.


Le plugin YAML v2
Avec https://zone.spip.org/trac/spip-zone/changeset/110648 et la libYaml :
 import d'un formulaire généré par V1 ou V2 (lib par défaut) : le formulaire importé est vide de champs.
 l'édition des champs d'un formulaire existant ne marche pas non plus : Warning : array_walk_recursive() expects parameter 1 to be array, null given in plugins\auto\saisies\v2.15.0\formulaires\construire_formulaire.php on line 113, Warning : array_splice() expects parameter 1 to be array, null given in plugins\auto\saisies\v2.15.0\inc\saisies_manipuler.php on line 103, Warning : Cannot modify header information - headers already sent by (output started atplugins\auto\saisies\v2.15.0\inc\saisies_manipuler.php:103) in ecrire\inc\actions.php on line 147 (les version des plugins indiquées dans les chemins sont farfelues : après installation par SVP en mode SVN, j'ai continué à mettre à jour les plugins par SVN)


Le plugin YAML v2
Avec https://zone.spip.org/trac/spip-zone/changeset/110648 et la lib par défaut, ça marche (aussi bien l'import d'un yaml fait en V1 ou V2, que l'édition du formulaire.).


Le plugin YAML v2
Hello,
Avec plaisir.
 Est-ce que tu veux que je le fasse ?
 ;-)
 ieconfig n'a pas besoin de plugins : il y a toute la config du core qui est gérée par ce dernier, donc, tu peux tester avec un SPIP sans plugin autre que ieconfig et ses dépendances
 c'est bien pour ça que j'ai fait un nouveau thread ;-) Dans ce thread, c'est une installation vierge, sans define, juste ce qui se produit par défaut à l'installation
 la lib par défaut en V2 rajoute 2 espaces en début de chaque ligne des yaml générés (mais je viens de voir que tu as corrigé ça en https://zone.spip.org/trac/spip-zone/changeset/110648)
Je vais essayer de garder un œil sur IRC ;-)


Le plugin YAML v2
Yo,
Merci pour les réponses.
 ben en mettant la borne mini à strictement supérieure à 3.2.* alors tu n'aurais pas eu la proposition dans SVP car le zip aurait été incompatible avec une 3.2. Mais on aurait toujours le zip et on pourrait tester cette version en 3.3.0-dev
 ok
 je n'utilise jamais ieconfig. Quels plugins peuvent me permettre de faire ces tests ?
 ben là je suis dubitatif car dans un autre message tu m'avais dit que tu avais installé libYAML ?
 ben là aussi je suis dubitatif car si tu utilises la librairie par défaut de v2 c'est la même que la v1. Or on a pas le problème en v1 ?
Bon j'essaye de regarder un peu cela demain après-midi et si tu es sur IRC je te ferais signe.


Le plugin YAML v2
Hello,
Je vais essayer de répondre à toutes tes questions.
 je ne vois pas ce que changer compatibilite=« [3.0.0 ;3.2.*] » aurait pu modifié du comportement de SVP (Ajouter un plugin, rechercher yaml, constater qu'il n'y a qu'un seul plugin yaml proposé, l'instaler, c'est la version 2.0.2)
 oui
 jeu de test : export avec ieconfig de n'importe quelle config, tentative d'import infructueuse
 librairie par défaut à l'installation de Yamlv2, rien dans config/mes_options.php
 les fichiers ont été supprimés car, après avoir compris le problème, j'ai installé manuellement la v1 de Yaml et constaté qu'elle bugait avec les .yaml des sauvegardes de ieconfig faites avec la V2
En conclusion, ayant constaté que pour un néophyte (en l'occurrence un stagiaire découvrant SPIP), il se retrouvait dans une situation problématique, je me suis dit que le problème allait concernait rapidement tous ceux qui mettaient à jour leurs plugins par SVP (pour mémoire, formidable et ieconfig sont impactés), j'ai préféré éteindre le départ d'incendie.
Mais je comprends que ça puisse te mettre en colère. Et j'en suis désolé.


Le plugin YAML v2
Hello,
Ton approche du problème m'interdit toute possibilité de correction.
 déjà tu aurais du modifier la borne mini de YAML v2 et pas supprimer le zip d'autorité car maintenant je ne peux plus tester le problème SVP si il y en a un.
 je suppose que tu parles de formulaires/ieconfig_import.php dans le plugin IEConfig ?
 quel est ton jeu de test pour que je puisse reproduire (ou pas) ton souci ?
 quelle librairie YAML utilises-tu ? c'est essentiel car comme je l'ai expliqué dans l'article, elles ne supportent pas toutes le même ensemble de features YAML.
 Pour la production des YAML je te redis une deuxième fois que comme expliqué les librairies ne sont pas équivalentes ni en import ni en export. Et comme tu as du produire ton YAML avec YAML tu dois avoir des --- au début que la librairie Symfony ne sait pas lire. Mais ça il faudrait que tu me donnes des détails sur le fichier et la librairie que je n'ai pas.
En conclusion, si on veut avancer il faut faire tout le contraire de ce post. Je suis désolé d'être faché mais passer des heures sur ce plugin pour en arriver là est frustrant. Donc je veux bien corriger mais il faudrait que je sache quoi !


Le plugin YAML v2
Je t'ai fourni dans une autre réponse le lien vers le formulaire .yaml à importer avec la V1 de YAML installée.
Ça te permettra de tester avec le même formulaire.
Merci


Le plugin YAML v2
Bonjour,
La V2 est maintenant installée par défaut via SVP pour SPIP 3.2.

Et elle fait planter le plugin ieconfig au moment de la restauration d'une sauvegarde.
Un boolean à la place d'un array en ligne 56 de formulaires/ieconfig_import.php
Par ailleurs, les config exportées avec la V2 font planter complètement l'importation si on remet Yaml en v1
Bref, ça pose de gros problèmes.
Je rebranche le zip sur la V1 en attendant en espérant qu'il n'y a pas trop de monde touché par ça...


Le plugin YAML v2

Tu expliques que c'est pour être « indépendant » que le plugin « embarque » une portion de code maintenue ailleurs...

Je crois que mon expression n'était pas assez précise parce que je voulais dire exactement ce que tu écris dans ta réponse. Si Textwheel nécessitait YAML il serait plus difficile à utiliser en dehors de SPIP.

Tu dupliques du code (symfony/yaml) dans un plugin SPIP packagé via smart_paquets, parce qu'aujourd'hui, c'est comme ça que ça marche...

Là c'est un peu réducteur car l'encapsulation de la librairie n'est pas toujours une redite exacte de l'API proposée par ladite librairie. Elle peut avoir une existence propre et donc un intérêt.
Après, l'inclusion de symfony/yaml v4 et Spyc est faite via composer. C'est pas ultime car tu ne mettras pas à jour le site de production avec mais ça permet au moins de mettre facilement à jour le plugin. J'ai galéré un maximum pour retrouver la version et la trace de la librairie sfyaml quand j'ai commencé mes investigations. Un petit pas...
Après pour finir avec Textwheel je pense qu'il faut migrer les YAML en JSON, ce qui se fait en quelques secondes et permet de s'affranchir complètement de toute librairie et n'utiliser le YAML que pour des configurations ou des exports plus « grand public ».


Le plugin YAML v2

Ouais bof, je ne suis pas convaincu de mon erreur...

Tu expliques que c'est pour être « indépendant » que le plugin « embarque » une portion de code maintenue ailleurs, alors que c'est parce que SPIP ne gère pas les dépendances avec un système commun avec cet ailleurs que cette portion de code a été dupliquée.
Par ailleurs, et j'ai pu me méprendre, j'ai toujours cru que la volonté d'indépendance de TextWheel par rapport à SPIP résidait dans le fait que la méthode avait vocation à être utilisée ailleurs que dans SPIP. Donc, sans nécessiter une partie de son code et par voie de conséquence d'un SPIP tout entier.

pourquoi TextWheel redéfinit une fonction qui existe déjà un autre plugin ?

Je demanderais directement aux auteurs de ces plugins, si j'étais toi.

Quoiqu'il en soit, ne nous chamaillons pas, il me semble qu'on aspire peu ou prou à la même chose, c'est juste la méthode qui diffère :
 Tu dupliques du code (symfony/yaml) dans un plugin SPIP packagé via smart_paquets, parce qu'aujourd'hui, c'est comme ça que ça marche.
 Je propose qu'on change de méthode, démo à l'appui, pour que SPIP puisse s'appuyer quand c'est nécessaire sur du code conçu et maintenu ailleurs sans qu'il soit dupliqué dans un plugin SPIP, par le biais d'un système de gestion de dépendances commun à l'ensemble de la communauté PHP.
Et je propose ce changement parce qu'il me semble être une meilleure solution à la plupart des problèmes que tu soulèves, considérant que c'est précisément le packaging « proprio » de SPIP qui engendre ces problèmes.


Le plugin YAML v2
Ouais bof, je ne suis pas convaincu de mon erreur...
Dans ce cas pourquoi TextWheel redéfinit une fonction qui existe déjà un autre plugin ? En plus, on se pose la question de quelle librairie est appelée quand YAML est activé. Non je n'en vois pas l'intérêt surtout que l'évolution de la librairie n'est jamais prise en compte.
Cette question revient sur le tapis à chaque fois que l'on propose un nouveau plugin. J'ai toujours du mal à comprendre cette logique de pseudo stabilité des plugins-dist qui ne répond à aucune stratégie claire de mon point vue. Ma vision du noyau est plutôt celui d'un framework que celui d'un coeur fonctionnel (toute proportion gardée). A cet égard manipuler des fichiers (XML, JSON, YAML...) c'est du noyau comme les raccourcis SPIP ou les itérateurs. Après les plugins externes c'est pour des ajouts fonctionnels. On a l'impression de vouloir définir la dist de SPIP comme un SPIP vision historique immuable (je caricature un peu).
Enfin, la question que je soulève est simple : on a un plugin dans la dist qui utilise une fonction qui est proposée dans un autre plugin qui n'est pas dans la dist : est-ce logique et si non que pouvons nous faire ?


Le plugin YAML v2
Erreur ! :) TextWheel embarque un bout de lib d'un autre projet parce que SPIP ne permet pas d'intégrer des librairies autonomes de manière standard. D'autre part, c'est un plugin SPIP qui n'est pas autonome (et ne peut le devenir en l'état) puisqu'il dépend encore de fonctions du noyau de SPIP, me semble-t-il. C'était en tout cas vrai quand j'ai isolé la partie ./engine à l'époque.
Embarquer un nouveau plugin SPIP dans la « dist », je ne sais pas si c'est une bonne ou une mauvaise idée. Tout dépend de comment et à quelle vitesse la communauté spipienne adopte Composer (ou pas) pour le développement de SPIP, de ses plugins, voire de librairies standard ...
Si ça ne tenait qu'à moi, j'éviterais les surcharges par des fonctions publiques des appels à l'API de la librairie symfony/yaml, et j'introduirais l'autoloading PSR-4 dans SPIP. Mais ça, je n'ai pas à le décider tout seul. ;-)


Le plugin YAML v2
Hello,
Oui je me rappelle très bien de l'objectif de TextWheel d'être « indépendant » de SPIP. C'est d'ailleurs pour cela qu'il embarque une version mini de la vieille librairie YAML de symfony v1.
Et c'est bien mon propos. Pourrait-on aujourd'hui envisager d'utiliser le plugin YAML dans la dist de SPIP avec un TextWheel qui se branche dessus surtout qu'avec l'utilisation de libYAML on améliore les performances d'environ un facteur 10 ?


Le plugin YAML v2
À propos de textwheel et pour info, j'ai ré-écrit textwheel sous forme de library standard il y a 2/3 ans, ça peut s'intégrer dans n'importe quel framework/cms qui utilise Composer.
L'idée suivante aurait été de faire un plugin SPIP, dans le cas où SPIP utiliserait Composer, qui requiert cette librairie d'une part afin que textwheel vive sa propre vie (et d'assurer l'interopérabilité souhaitée par ses auteurs au début http://zzz.rezo.net/Presentation-de-Textwheel.html) et les règles SPIP d'autre part, en supposant que les règles soient distribuées sous forme de composant (par composer, donc)
Le plugin textwheel pour spip ne serait qu'un wrapper.


Le plugin YAML v2
Re,
J'ai regardé les deux fichiers de dump que tu as annexé. Et j'ai quelques remarques qui vont bien dans le sens de mon précédent message.
Les fichiers sont bien « identiques », ce qui diffère c'est la présentation du YAML du au mode inline qui est déclenché différemment pour l'une et l'autre librairie. Par défaut, le mode inline est déclenché après deux niveaux d'imbrication pour l'une et l'autre des librairies. Or, on remarque que pour le défaut (sfyaml) le mode inline est enclenché un niveau avant. Et chose étrange l'indentation est activée dès la racine : il y a peut-être une rapport d'ailleurs.
Après sfyaml ne lit pas les '---' et '...'. Je ne comprends pas pourquoi mais c'est ainsi.
Pourrais-tu me dire comment générer le formulaire pour obtenir le fichier YAML que tu as annexé afin que je fasse des tests de mon coté ?


Le plugin YAML v2
Jeu de test à importer avec la V1 du plugin : http://dl.free.fr/gXHv1eavg
L'importation avec la V2 ne fonctionne pas.
Et l'exportation avec la V2 produit un fichier différent (2 espaces en plus au début de chaque ligne).


Le plugin YAML v2
Au temps pour moi : le yaml généré par défaut diffère de celui généré par la v1 : il a 2 espaces en plus au début de chaque ligne (ce qui fait que les éléments racines sont décalés de 2 espaces).
Ceci http://dl.free.fr/gXHv1eavg s'importe correctement avec la V1 du plugin.

Et ne s'importe pas avec la V2, que ce soit avec la lib par défaut ou avec libyaml.


Le plugin YAML v2
Dans le premier paragraphe de ma question : voir fichiers ici : http://dl.free.fr/h3Y8EY0Ss


Le plugin YAML v2
Ok, de même il faudrait me fournir tes fichiers de tests. Par contre, je pense qu'il y a aussi un problème sur la v1 à partir du moment où la librairie sfyaml ne sait pas lire son propre encodage YAML.
Après que le fichier créé ne soit pas le même exactement n'est pas un problème si son décodage produit toujours la même structure PHP. En particulier, le mode inline peut différer.


Le plugin YAML v2
Hello,
Merci de tester avec des jeux différents des miens. Peux-tu me fournir tes jeux de tests pour que je les essaye chez moi ?
Le mieux aussi est d'utiliser les fichiers YAML hors contexte d'un plugin pour vérifier si seul le plugin YAML est en cause.


Le plugin YAML v2
J'ai aussi testé l'export d'un formulaire formidable et je n'obtient pas du tout les mêmes fichiers avec libyaml et par défaut (voir fichiers ici : http://dl.free.fr/h3Y8EY0Ss)
Et aucune des 2 méthodes (défaut et libyaml) n'est capable d'importer l'un ou l'autre des 2 .yaml exportés.
Je suis revenu en v1 du plugin.
 L'export produit un fichier .yaml identique
 L'import plante, mais avec un message plus explicite : Unable to parse string : Unable to parse line 1 ( id_formulaire : '2'). (je vais donc poster ça dans le forum du plugin formidable)


Le plugin YAML v2
Merci beaucoup pour cette évolution !
J'ai testé sous Windows en installant la lib en m'inspirant de https://stackoverflow.com/questions/27122701/installing-php-yaml-extension-with-xampp-on-windows (les dossiers n'étaient plus exactement les mêmes, mais l'idée était bien là).
Le php_info me dit :

LibYAML Support	enabled

Module Version	2.0.2

LibYAML Version	0.1.4

Mes_options avec :
define('_LIB_YAML','libyaml');
Saisies + formidable à jour, modification d'un champ de formulaire de type ligne de texte.

J'ai plusieurs erreurs :
 Warning : array_walk_recursive() expects parameter 1 to be array, null given in \plugins\saisies\formulaires\construire_formulaire.php on line 113
 Warning : array_splice() expects parameter 1 to be array, null given in saisies\inc\saisies_manipuler.php on line 103
Est-ce que tu reproduis sous Linux ?