Introduction
Créer un formulaire est une tâche toujours un peu répétitive : les champs ont souvent les mêmes propriétés, le même accompagnement (message d’erreur, explication ...) et la même structure HTML. Ce plugin est un outil d’aide au développement, ayant pour but de faciliter et d’accélérer l’écriture des formulaires.
Pour cela, Saisies propose plusieurs mécanismes (balises, API PHP) pour générer et manipuler plus facilement les champs des formulaires. De cette manière, les squelettes de formulaires sont :
- plus lisibles : il n’y a que le strict nécessaire dedans, pas de répétition ;
- intégrés au fonctionnement CVT de SPIP, notamment pour la gestion des erreurs sur les champs ;
- automatiquement compatibles avec les recommandations HTML/CSS de SPIP.
Dans la présente documentation, nous présentons la manière de construire un formulaire avec Saisies de la méthode la plus robuste à la méthode la moins robuste.
Les méthodes moins robustes sont présentées pour deux raisons :
- ce sont les méthodes les plus anciennes. On trouve encore beaucoup de code les utilisant ;
- il est parfois nécessaire de passer par là, pour des réglages fins.
Pour utiliser l’API complète PHP, vous devez installer ou nécessiter le plugin YAML dans votre plugin. Ce n’est pas le cas quand on utilise juste la simple balise, ce pourquoi c’est à vous de le nécessiter.
Dans la présente documentation, lorsqu’un code est entre chevrons (comme <ceci>
), vous devez le remplacer par une valeur correspondant à votre projet.
Cette documentation est valable à partir de la version 4.11.0 ou du plugin.
Méthode 1 : déclarer un formulaire CVT complet en PHP
Principe
Saisies augmente l’API CVT de SPIP avec une fonction formulaires_<nomduformulaire>_saisies()
afin de déclarer l’ensemble des champs d’un formulaire et leur vérification dans une unique syntaxe. Cette fonction permet également de déclarer différents réglages de formulaire, tel que :
- le label du bouton de validation final ;
- l’utilisation en multiétapes.
Grâce à ce mécanisme, pour les cas les plus courants, les fonctions formulaires_<nomduformulaire>_charger()
et formulaires_<nomduformulaire>_verifier()
deviennent facultatives. Saisies s’occupera de tout suivant votre déclaration. Seule la fonction formulaires_<nomduformulaire>_traiter()
reste toujours de votre ressort.
De même, par défaut, vous n’avez plus à vous occuper du squelette. Il doit toujours être présent, avec le même nom que votre fichier PHP dans le dossier formulaires/
, mais vous devez le laisser totalement vide. Saisies s’occupera de générer le HTML complet, en suivant les recommandations de structuration de SPIP.
Enfin, dans le cas particulier où vous créez un formulaire de configuration, vous n’aurez même pas à déclarer les valeurs par défaut ni le traitement. Voir l’article « Formulaire de configuration avec le plugin Saisies ».
Mise en œuvre
Il vous faut donc créer un fichier formulaires/<nomduformulaire>.html
vide, ainsi qu’un fichier formulaires/<nomduformulaire>.php
contenant deux fonctions :
- formulaires_<nomduformulaire>_traiter()
, qui indique ce que votre formulaire doit effectuer comme traitement ; cela n’est pas du ressort du plugin Saisies ;
- formulaires_<nomduformulaire>_saisies()
, pour déclarer les saisies proprement dites.
Cette dernière fonction reçoit comme arguments les mêmes arguments que la fonction _charger()
du formulaire CVT, et elle doit retourner un tableau PHP contenant la liste de toutes vos saisies suivant un formalisme attendu.
formulaires_<nomduformulaire>_saisies(…) {
$saisies = […];
return $saisies;
}
Déclaration de l’ensemble des saisies
Chaque ligne globale du tableau renvoyé décrit une saisie.
L’ordre des éléments sera l’ordre des saisies.
$saisies = [
[…], // une saisie
[…], // une saisie
[…], // une saisie
];
Déclaration d’une saisie individuelle
Chaque saisie est elle-même décrite dans un tableau, qui prend par exemple la forme suivante :
[
'saisie' => 'input',
'options' => [
'nom' => 'nom',
'label' => 'Votre nom',
'defaut' => 'Valeur par défaut'
],
];
On consultera « Référence des saisies » pour avoir l’ensemble des saisies et des options disponibles en standard.
D’autres plugins ajoutent leurs propres saisies, et vous pouvez aussi créer vos propres saisies.
Déclaration des saisies enfants
Les saisies qui acceptent des enfants (comme les fieldsets) les placent dans une clé saisies
dont la valeur est un tableau ayant la même structure que le tableau global :
$un_fieldset = [
'saisie' => 'fieldset',
'options' => [
'nom' => 'mon_groupe',
'label' => 'Mon groupe de champ'
],
'saisies' => [
[…], // une autre saisie
[…], // une autre saisie
[…], // etc
]
];
Appliquer des vérifications
Pour des vérifications simples et uniques vous pouvez en déclarer des vérifications à appliquer sur chacune de vos saisies, avec le plugin API de Vérification (qui n’est pas activé automatiquement avec le plugin saisies
).
Il faut alors ajouter une clé verifier
selon ce formalisme :
[
'saisie' => 'input',
'options' => [
'nom' => 'slug',
'label' => 'slug',
'obligatoire' => 'oui',
],
'verifier' => [
[
'type' => 'taille',
'options' => ['min' => 10]
],
[
'type' => 'slug',
],
],
];
Permet de vérifier que nous avons affaire à un slug d’une taille minimum de 10 caractères.
Consulter « Références des vérifications » pour la liste des types de vérification livrés avec le plugin et de leurs options.
[
'saisie' => 'input',
'options' => [
'nom' => 'nom',
'label' => 'nom',
'obligatoire' => 'oui',
],
'verifier' => [
'type' => 'entier',
'options' => [
'min' => 100,
'max' => 500
],
],
];
Support du multilinguisme
Saisies supporte le multilinguisme. Ainsi, dans l’exemple ci-dessous, la chaine de langue <:cle:valeur:>
sera automatiquement interprétée.
[
'saisie' => 'input',
'options' => [
'nom' => 'nom',
'label' => '<:cle:valeur:>',
'size' => 50
],
];
Options globales
Il est possible de déclarer des options d’affichage globales à l’ensemble du formulaire. Elles sont alors placées dans une clé options
à la racine du tableau des saisies.
$saisies = [
'options' => [
// Changer l'intitulé du bouton final de validation
'texte_submit' => 'Valider c’est gagné',
…
'<option>' => '<valeur>' //Une autre option
],
[…], // une saisie
[…], // une saisie
[…], // une saisie
);
Option | Usage | Valeur possible | Valeur par défaut |
---|---|---|---|
Options pour le bouton de validation | |||
texte_submit |
Texte du bouton de validation | Texte, passe par _T_ou_typo() |
<:bouton_enregistrer:> |
afficher_si_submit |
Condition pour afficher le bouton de validation | Voir « Affichage conditionnel des saisies : syntaxe des tests » | null |
Options pour la gestion des étapes multiples | |||
etapes_activer |
Activer la gestion multi-étapes, chaque fieldset de premier niveau devient une étape |
True|False |
False |
etapes_presentation |
Mode de présentation des étapes en haut du formulaire | 'defaut'|'courante' , il est possible de créer son propre mode en créant un squelette formulaires/inc-saisies-cvt-etapes-<presentation>.html |
defaut |
etapes_suivant |
Texte du bouton pour aller à l’étape suivante | Texte, passe par _T_ou_typo() |
<:bouton_suivant:> |
etapes_precedent |
Texte du bouton pour revenir à l’étape précédente | Texte, passe par _T_ou_typo() |
<:precedent|ucfirst:> |
etapes_precedent_suivant_titrer |
Permet d’ajouter le titre des étapes dans les boutons « précédent » et « suivant » | True|False |
False |
etapes_ignorer_recapitulatif |
Permet de ne pas insérer de récapitulatif avant la validation finale | True|False |
False |
Options techniques | |||
verifier_valeurs_acceptables |
Permet de s’assurer que les valeurs reçues figurent bien parmi les valeurs proposées lors de la saisie du formulaire | True|False |
False |
afficher_si_avec_post |
Permet que les saisies masquées par affichage conditionnel soient tout de même postées | True|False |
False |
inserer_debut |
Contenu arbitraire à insérer au début du formulaire, par exemple pour appeler un script Javascript | Chaîne de caractères | null |
inserer_fin |
Contenu arbitraire à insérer à la fin du formulaire, par exemple pour appeler un script Javascript | Chaîne de caractère | null |
Si un texte passe par _T_ou_typo()
, cela peut être :
- un texte directement écrit dans la langue du site ;
- un appel à une chaîne de langue sous la forme
<:fichier_de_langue:chaine:>
; - un texte utilisant la balise
<multi>
pour gérer l’internationalisation.
Pipeline
Lors du chargement des saisies déclarées via une fonction formulaires_<nom_du_formulaire>_saisies()
, les saisies sont passés à un pipeline formulaire_saisies
. Le tableau $flux
passé à ce pipeline à la structure suivante :
- $flux['args']['form']
: le nom du formulaire ;
- $flux['args']['args']
: les différents arguments passés ;
- $flux['data']
: les saisies.
Il est donc possible à un plugin de modifier dynamiquement les saisies d’un formulaire en utilisant les différentes fonctions de l’API de saisies.
Méthode 1a : déclarer un formulaire CVT en PHP, mais effectuer soi-même des vérifications
Parfois il est nécessaire d’avoir des vérifications supplémentaires sur les saisies. Pour ce faire, vous devez déclarer votre propre fonction formulaires_<nomduformulaire>_verifier()
.
Dans ce cas, vous ne perdrez pas le bénéfice d’une déclaration des vérifications de base dans votre tableau de saisies : celles-ci sont alors automatiquement effectuées après vos propres vérifications.
Toutefois, il est parfois nécessaire de faire en sorte que les vérifications « par déclaration » se fassent avant vos propres vérifications. Dans ce cas, la méthode la plus propre est de déclarer ses vérifications non pas sous forme d’une fonction formulaires_<nomduformulaire>_verifier()
, mais par la création d’une fonction formulaires_<nomduformulaire>_verifier_post_saisie()
, ou sa variante verifier_etapes_post_saisies()
dans le cadre du multiétape.
À noter qu’il existe deux pipelines pour ajouter des vérifications à un formulaire existant : formulaire_verifier_post_saisies
et formulaire_verifier_etapes_post_saisies
.
Méthode 1b avec #GENERER_SAISIES
: contrôler la structure globale du formulaire, mais utiliser le formalisme de saisies
Dans quelques cas rares, la structure globale du formulaire livrée avec Saisies ne convient pas. Pour autant, vous souhaitez.
- profiter du formalisme de déclaration des saisies
- profiter de la vérification automatique de ces saisies (sauf si vous utilisez la méthode 1a).
Dans ce cas :
- vous mettez dans votre fichier
formulaires/<nomduformulaire>.html
la structure globale du formulaire correspondant à votre besoin ; - là où vous souhaitez insérer vos saisies, vous utilisez la balise
#GENERER_SAISIES
.
Cette balise permet de générer toutes les saisies d’un formulaire, en une seule fois. Pour cela on lui passe en paramètre le tableau de description.
Exemple d’utilisation :
<div class="formulaire_spip formulaire_#ENV{form}"[(#ENV{_etape}|oui)formulaire_multietapes]">
<form .... [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"]>
....
<div >
#GENERER_SAISIES{#ENV{_saisies}}
</div>
....
</form>
</div>
On notera l’emploi d’un _
en préfixe de la variable d’environnement. Cela permet que les guillemets présents dans les options ne soient pas transformés en entités HTML [1].
#ENV{_saisies}
est rempli automatiquement avec la valeur de retour de la fonction formulaires_<nomduformulaire>_saisies()
[2].
On n’oubliera pas les attributs suivants :
- les différentes classes sur le <div>
englobant
- l’attribut [ data-resume_etapes_futures="(#ENV{_resume_etapes_futures}|json_encode|attribut_html)"]
sur le <form>
, qui permet de gérer correctement les affichages conditionnels des étapes dans un formulaire multi-étape.
Par ailleurs, on utilisera
[(#ENV{_etape}|oui)
<INCLURE{fond=formulaires/inc-saisies-cvt-etapes-#ENV{_saisies/options/etapes_presentation,defaut}, etapes=#ENV{_saisies_par_etapes}, env} />
]
</div>
pour insérer le chemin d'étapes, et
<cadre class="spip">
<INCLURE{fond=formulaires/inc-saisies-cvt-boutons,env} />
pour les boutons de validation.
Méthode 2 : la balise #SAISIE
Parfois on veut pouvoir contrôler encore plus finement la présentation des saisies. Pour ce faire, on peut insérer dans formulaires/<nomduformulaire>.html
des appels à la balise #SAISIE
.
Cette méthode n’est pas toujours adaptée, car elle présente des limitations :
- elle ne permet pas de profiter des vérifications automatiques ;
- elle ne permet pas de profiter du mécanisme d’affichage conditionnel.
#SAISIE
permet de générer une seule saisie en lui donnant directement les paramètres désirés. Chaque saisie va générer une ligne dans un formulaire, c’est-à-dire un élément <div>
.
La balise #SAISIE
a deux arguments obligatoires : le type de saisie, et son nom HTML (attribut « name »). Toutes les autres options sont facultatives et servent à configurer le champ ; de ce fait, elles sont de la forme option=valeur
.
La forme complète est donc la suivante :
#SAISIE{type, name, option=valeur, option2=valeur2, etc=etc}
Voici quelques exemples d’utilisation.
Génère un simple champ texte, indiqué comme étant obligatoire :
#SAISIE{input, email, label=Votre courriel, obligatoire=oui}
Génère un choix multiple parmi les utilisateurs du SPIP :
#SAISIE{auteurs, destinataires,
label=Destinataires du message,
explication=Choisissez une ou plusieurs personnes à qui sera envoyé le message.,
multiple=oui}
Comme vous le voyez, des champs qui peuvent être complexes, et fastidieux à écrire de manière complète, s’écrivent ici en quelques lignes.
#SAISIE
supporte le multilinguisme. Dans ce cas, attention de bien utiliser la syntaxe complète avec les crochets :
-
#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui}
ne fonctionne pas ; -
[(#SAISIE{input, annee, label=<:monplugin:annee:>,obligatoire=oui})]
fonctionne.
Appendice 1 : chargement des CSS et scripts Javascript sur le site public
Si votre formulaire est destiné à être public, le plugin se charge d’ajouter automatiquement les appels aux fichiers CSS et scripts Javascript associés aux saisies utilisées sur le site public, lorsque le formulaire est effectivement utilisé.forme
Toutefois, si vous avez beaucoup de formulaires utilisant Saisies sur le site public, il peut être judicieux de charger systématiquement les fichiers sur toutes les pages, afin de profiter de la compréhension et du cache navigateur. Dans la configuration du plugin (« Squelettes »->« Configuration du plugin Saisies »), une option permet d’activer cela.
Appendice 2 : enregistrer des tableaux
La norme HTML permet de gérer des réponses de formulaire sous la forme de tableau.
Dans la déclaration de la saisie, on peut utiliser la syntaxe HTML classique avec crochets :
[
'saisie' => 'input',
'options' => [
'nom' => 'annee[debut]',
'label' => 'Votre nom',
'size' => 50
],
];
Mais il est recommandé d’utiliser le formalisme SPIP suivant : <tableau>/<clé>
.
[
'saisie' => 'input',
'options' => [
'nom' => 'annee/debut',
'label' => 'Label',
'size' => 50
],
];
Le code suivant permettra de récupérer la valeur en PHP :
$annee = _request('annee');
$debut = $annee['debut'];
Appendice 3 : la balise #VOIR_SAISIES
Cette balise permet d’afficher toutes les valeurs saisies après validation d’un formulaire. On lui passe en paramètre deux arguments :
- le tableau de description des saisies (au même format que pour #GENERER_SAISIES)
- un tableau des valeurs saisies
Exemple d’utilisation, dans le squelette d’un formulaire :
[(#EDITABLE|non)
#VOIR_SAISIES{#ENV{mes_saisies}, #ENV}
]
Appendice 4 : problème avec Xdebug
Si vous développez en utilisant le logiciel Xdebug, il existe un problème connu : par défaut celui-ci affiche une erreur à partir d’un certain niveau d’imbrication de fonctions PHP (« nesting level » dirait Shakespeare).
Le niveau d’imbrication autorisé par défaut est relativement bas, mais on peut le paramétrer. Vous devez donc ajouter cela dans votre configuration PHP/Xdebug :
[xdebug]
xdebug.max_nesting_level = 200 ou 500 ou plus…
Et hop, ça remarche.
Discussions par date d’activité
179 discussions
Bonjour
Petite demande d’amélioration : quand on utilise la saisie « couleur », une fois la couleur choisie, j’ce serait bien, à mon avis, que le code hexa de la couleur soit affiché.
Merci.
Répondre à ce message
Bonjour à tous,
Je viens de faire la mise à jour du plugin et j’ai une message omni présente :
« Aucun squelette formulaires/inc-saisies-cvt-boutons-cda n’est disponible... plugins/auto/formidable/v5.2.3/formulaires/inc-formidable-boutons.html »
Je suis passé de 4.5.1 à 4.6.0 et ne comprends pas ? Ce fichier n’est pas présent dans le plugin formidable ?
Merci de votre aide !
Hum, j’ai la même version et aucun problème. Par contre ton message m’intrique
formulaires/inc-saisies-cvt-boutons-cda
ca n’est appelé nul part dans formidable, ce qui existe c’estformulaires/inc-saisies-cvt-boutons
. On dirait que ta version de formidable est incorrecte / mal récupéré. Tente peut être de désactiver le plugin, puis le supprimer (ATTENTION : pas de desinstallation) puis le remettre en place.Bonsoir !
Merci pour a réponse, mais cette mannip n’a pas focntionné. J’ai sauvertagrdé, desintallé et réinstaller les plugin avec la verion récente, bug se reproduit. J’ai refais ce processus en réintégrant la version précédente et tout fonctionne.
MAIS oui, il y a un soucis avec le #NOM_DU_SITE dans lequel j’ai mis un
<br>
et je vois que j’ai petitb triangle jaune dans l’onglet de page web et un drole de titre… Cela sera lié ?Lorsque je vire la ballise l’onglet retrouve une apparence presque normale, le nom du site apparait entre crochet…
hUm, je teste. Mais attention c’est
<br />
pas</br>
mouais, non je ne reproduis pas, meme avec ca.
Est-ce que vous pourriez m’envoyer en mp une identifant admin pour le site (monprenomsanstrema@monprenomsanstrema.net)
C’est fait… lien envoyé ;-) Pfff merci pour le
…
rien recu :(
Et donc comme expliqué par email : fausse alerte, ton site surcharge brutalement le code de formidable et de saisies, ce qui explique la rupture à la mise à jour.
Répondre à ce message
Bonjour,
Je souhaite utiliser formidable et le formulaire de participation pour que les membres de notre association puissent s’inscrire en famille.
Il sont connectés au moment de l’inscription, hors sur le formulaire le mail est obligatoire, donc il doivent ressaisir leur adresse mail.
J’ai ouvert un ticket sur formidable, mais la réponse a été que l’on ne peut pas charger un formulaire en l’appelant dans un article et un de ceux qui m’ont répondus ma écrit ceci : "On pourrait envisager d’ajouter pour la saisie « email » une option pour préremplir avec l’email de la session courante -> ouvre un ticket sur le plugin saisies. A mon avis c’est le plus perenne"
Alors question, es-ce possible et si oui comment ?
Sachant que je suis un webmestre lambda et que je me suis jamais lancé dans la programmation Spip.
Merci par avance de toutes les infos que vous pourrez me donner,
André
Oui c’est possible, faut juste que je trouve le temps de faire cela (sans doute pas avant longtemps, d’autant que ce n’est clairement pas ma priorité).
Pour que l’information ne soit pas perdues, peut tu :
1. Te créer un compte sur git.spip.net en suivant le lien « s’inscrire pour contribuer »
2. Lorsque ton compte sera créé, te rendre sur https://git.spip.net/spip-contrib-extensions/saisies/issues et créer ton ticket ?
Bonjour,
Je pense laisser tomber l’utilisation de formidable, je voulais l’utiliser pour ne pas utiliser réservation et réservations multiples qui me paraissait une usine juste pour enregistrer des réservations sans notion commerciale.
Mais devant les difficultés, les délais, etc.
Je vais utiliser réservation !
Merci de tes réponses.
Au fait j’ai eu un soucis avec le mot de passe sur git et malgré plusieurs demande je n’ai jamais reçu le mail de réinitialisation.
Pb lié à mon compte ? ou plus général ?
André
Bah je vois pas les difficultés en fait. Tu demande juste une petite fonction supplémentaire. Mais enfin tu fais ce que tu veux.
Aucune idée pour git.spip.net. Je transmet le message à la personne qui s’en occupe.
Répondre à ce message
Avec SPIP 4.1.5 et tous les plugins à jour, le champ extra sélecteur d’article ne marche plus (alors que sélecteur article ou rubrique marche bien) (on peut bien sélectionner des articles, mais ils ne sont pas visibles dans la fiche article après enregistrement de l’article) : spip enregistre dans la base articles|25 et non article|25.
Si, via phpmyadmin on supprime le S, alors tout marche bien.
Je ne sais pas trop qui gère ce libellé : saisie ? Bonux ? Iextra ?
Une idée de l’origine de ce s intempestif ?
Merci de votre aide.
Julien
Merci de pas poster la même question en différents endroits, ça multiplie le travail pour te répondre ... et d’autres personnes intéressées par le même sujet n’auront que des petits bouts de l’ensemble des réponses.
En l’occurrence la réponse a été fait là : Bonux pour SPIP3
Répondre à ce message
Je viens de mettre à jour ce plugin vers 4.5.0 sur 2 sites en SPIP 4.1.5 sur 2 serveurs différents
et depuis impossible modifier les sites référencés :
Page blanche sur / ?exec=site_edit
dans distant.log je vois :
IP adresse IPV6 108151 Privé erreur Erreur connexion 0
mais je ne sais pas si c’est lié.
Merci
Bonjour,
Pareil pour moi, voici l’erreur affichée :
Mais pourquoi vous mettez ça là, quel rapport avec Saisies pour le moment ? Le plugins-dist « Sites syndiqués » n’utilise évidemment pas Saisies et l’erreur collée indique très clairement un fichier *du noyau* ecrire/inc/editer.php:226
Bon bé si ya peut-être bien un problème plus profond, dû à un appel aux fonctions charger() de *tous* les formulaires (même ceux qui n’ont pas de saisies déclarées) à un moment où ya des choses pas chargées… c’est à la fois dû à une nouvelle inclusion de Saisies ET à un mauvais code du noyau qui n’inclue pas le bon fichier pour être sûr avant d’utiliser une fonction qui est ailleurs.
Et donc à priori depuis cette PR fusionnée récemment : https://git.spip.net/spip-contrib-extensions/saisies/pulls/215#issuecomment-41545
Et donc v4.5.1/v3.56.4 corrigent cela
Oui merci Maïeul, la nouvelle version élimine le problème pour moi.
Répondre à ce message
La mise à jour du plugin saisie vers sa version 3.56.3 empeche la modification des articles dans spip 3.2.16.
Même problème que le fil précédent https://git.spip.net/spip-contrib-extensions/saisies/pulls/215#issuecomment-41545
merci pour votre rapidité. Ca ne fonctionne pas. Je dois avoir fait une mauvaise manip.
Euh j’ai juste mis le même lien que dans le fil de com précédent où ça explique d’où vient le problème en disant que vous parlez les deux du même problème. Ya aucune manip à faire, c’est juste une explication de la source du problème.
Bonjour,
si on remet l’ancienne version du plugin ça pose pb ?
Non, hormis la perte de quelques bugfix très spécifiques. Mais on va generer dans la journée une version corrigé.
merci bcp !
Et donc v4.5.1/v3.56.4 corrigent cela
Répondre à ce message
Bonjour
je viens d’installer SPIP 4.1.2 avec le plugin Escal 4.5.52, saisies 4.4.1 j’utilise wampserver 3.2.6 avec php 7.4.26, mySQL 5.7.36
et lorsque je vais dans la config du plugin Escal (dans tous les items mise en page, éléments, page d’accueil,...) j’ai le message ci dessous :
Warning : array_merge() : Expected parameter 2 to be an array, null given in C :\Site\wamp64\www[mon site]\plugins\auto{saisies\v4.4.1\inc\saisies_lister_disponibles.php on line 45
Avez vous une idée pour supprimer ce warning ?
Merci
bonne journée
1. Deja normalement les warnings ne devraient pas apparaitre publiquement -> il faut configurer ton hebergement pour éviter cela.
2. Dans tous les cas, active le plugin YAML, ca évitera de les déclencher (et je vais de ce pas signaler cela au contributeur d’Escal).
Bonjour,
Pour info je rencontre le même souci sur un site en 4.1.5.
Le squelette n’est pas ESCAL mais Html5up Phantom.
La version de PHP est la 8.1.0.
Le message apparaît sur les pages de modifications des articles ou des pages (plugin Pages uniques).
L’installation du plugin Yaml a fait disparaître le message.
Pour info, on me signale le même souci sur un site avec Escal et php 8.1.
De mon côté je n’ai aucun souci avec php 7.4.28 ou 7.4.30 sur plusieurs sites.
Comme expliqué, il faut que YAML soit installé pour que la declaration de formulaire en full PHP marche. Du coup il faudrait qu’Escal le marque en « necessite » dans son paquet.xml et ce sera bon.
Comme Escal utilise saisies, je vais le faire mais à mon avis, ce serait plutôt à Saisies de le faire non ?
D’autant qu’avec php 7.4, même sans yaml, je n’ai pas de souci.
Non puisque Saisies peut parfaitement être utilisé sans PHP uniquement en squelette, donc sans YAML, donc ya pas à obliger YAML pour ceux qui n’utilisent pas l’API PHP. Donc c’est à ceux qui utilisent l’API PHP de nécessiter YAML.
Je vois pas ce qu’il y a de bizarre à ce que ça marche avant et pas après : tout l’objet de PHP 8 est justement de passer à un truc mille fois plus strict sur toutes les erreurs, donc ya plein de choses qui étaient juste des notices ou des warnings et qui maintenant génèrent des erreurs bloquantes.
Répondre à ce message
Je crois qu’il y a une coquille là :
C’est < 4.3.0 plutôt
Effectivement. Corrigé. Merci !
Répondre à ce message
Testé en spip 4.1.1 sans problème en forçant la borne.
Répondre à ce message
Bonjour,
Le plugin semble incompatible avec spip 4.0.1 (ce qui bloque du coup la m-à-j de nombreux autres plugins). Existerait-t-il un moyen de contourner cette incompatibilité ? J’ai mis à jour tous mes sites à la v4.0.1 (dernière en date) en croyant que « compatible avec spip 4.0 » signifiait « compatible avec 4.0.* »
Euuh c’est marqué dedans :
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/paquet.xml#L6
Donc bien pour tout 4.0.* infini
Merci, RastaPopoulos
J’ai pu installer mes plugins.
Mais allez savoir pourquoi, lors de mes premières tentatives, mon spip me signalait que le plugin SAISIES n’était pas la bonne version.
Bonjour,
Il m’était aussi indiqué comme incompatible ainsi que quelques autres pourtant compatibles. Pas de menu « mettre à jour », j’ai été obligé de le supprimer puis de le réinstaller via l’archive zip car je ne le retrouvais pas dans « ajouter des plugins ». Bizarre, surement un bug qui traîne sur la partie Core de Spip :(
A suivre...
P.S. : le plugins « Vérifier la compatibilité de vos plugins » indiquait aussi des informations erronées.
Oui il y a un bug lors du passage à SPIP 4 sur SVP (le service qui permet d’installer/mettre à jour les plugins). Il faut supprimer le depot distant et le recreer.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |