Champs Extras 3

Ce plugin permet de créer et/ou de gérer des champs supplémentaires dans les objets éditoriaux de SPIP. Il permet donc de prendre en compte et d’afficher de nouveaux éléments dans n’importe quel objet éditorial de SPIP.

Screencast

Vous n’aimez pas lire ? Écoutez pendant 20mn !

Cette capture présente Champs Extras 3 avec son interface graphique [1]. Elle est présente sur medias.spip.net où vous pourrez voir la vidéo en plus grand format.

Introduction

Ce plugin est plus qu’une adaptation pour SPIP 3 du plugin «Champs Extras 2». Les nouveaux champs sont toujours stockés dans de nouvelles colonnes SQL sur les objets éditoriaux correspondants, mais l’interface et le fonctionnement technique sous-jacent a été en grande partie modifié pour deux raisons essentielles :

  • SPIP 3 offrant une méthodologie pour déclarer des objets éditoriaux, ce plugin s’appuie donc dessus pour connaître la liste des objets sur lesquels il peut intervenir et créer de nouveaux champs. Ainsi, il est possible à l’aide de EXTRA3 d’ajouter des champs à tous les objets éditoriaux (et éditables) déclarés par SPIP3 ou par des plugins. (Avec EXTRA2, il était nécessaire que le plugin à l’origine de l’objet éditorial le déclare comme extensible).
  • Le plugin «Saisies» dispose d’un générateur de formulaire, à l’origine créée pour le plugin «Formidable, le générateur de formulaires» et d’un nombre de saisies possibles grandement supérieur à ce que proposait la version 2. Mutualiser ce code entre plusieurs plugins permet une meilleure maintenance, une interface plus complète et une aussi grande extensibilité.

L’ensemble est donc à la fois plus fonctionnel, plus extensible, le tout en utilisant bien moins de code.

Séparation de l’API et de l’interface graphique

Ce plugin est séparé en deux éléments indépendants :

  • le premier, «Champs Extras» (lire «Champs Extras 3 - API et créations») donne accès aux fonctions de création, de gestion et d’affichage des champs, mais pour d’autres plugins. Il nécessite le plugin «Saisies». Un exemple (Titre Court sur les rubriques) dans le dossier extensions montre comment créer un plugin offrant des champs prédéfinis.
  • le second, «Champs Extras (Interface)» profite des points d’entrées et des fonctions du plugin «API» pour proposer une interface graphique de gestion et de création de ces champs supplémentaires. Ce plugin nécessite quand à lui évidemment «Champs Extras (API)» et «Saisies», mais également «Le plugin YAML» et «Vérifier».

Présentation de l’interface

Lorsque le plugin d’interface est activé, le menu de configuration permet d’aller sur la page de configuration des Champs Extras (?exec=champs_extras).

Cette page présente :

  • la liste des objets sur lesquels on peut insérer des champs extras, indiquant pour chaque objet le nombre de champs extras présents,
  • puis, si c’est le cas, un cadre se trouve dessous indiquant pour certains objets que certaines colonnes SQL ne sont gérées ni par SPIP ni par un plugin, et que Champs Extra peut éventuellement les gérer.
Liste des objets éditoriaux exploitables
Liste des objets éditoriaux exploitables

On le remarque sur l’image, ici seul l’objet Articles a 1 Champs Extra. De plus, dans le second cadre, on voit que le champ «openid» peut être géré. Ce champ provient du plugin «OpenId» qui avait du être installé mais n’est actuellement pas actif sur le site. Comme il n’avait pas été désinstallé (mais seulement désactivé), le champ est resté dans la table SQL des auteurs.

Créer un nouveau champ via l’interface

Seuls les webmestres du site ont accès à ce panneau de configuration.

Pour ajouter un élément dans un des objets, il faut cliquer sur le nom de l’objet souhaité.
Nous allons créer un champ dans la table des articles, nous cliquons donc sur leur nom.

Cela nous amène sur une autre page (du même fonctionnement donc que le plugin Formidable), qui présente :

  • les Champs Extras présents sur l’objet (que l’on peut déplacer, modifier, dupliquer ou supprimer),
  • puis la liste des types de champs que l’on peut ajouter.
Présentation du formulaire d'édition d'un objet
Présentation du formulaire d’édition d’un objet

Il suffit de cliquer un des types de champs pour ajouter cet élément dans la liste des champs présents. Cet élément se placera automatiquement en fin de liste. Nous ajoutons ici des cases à cocher.

On peut le voir sur l’image suivante, un message indique alors que le formulaire est modifié par rapport à son état normal. On a trois possibilités offertes :

  • Continuer nos modifications, autant qu’on en souhaite,
  • Annuler toutes nos modifications en «Réinitialisant le formulaire»
  • Valider nos modifications en «Enregistrant le formulaire» en bas de page.
Des champs de type Cases ajoutés aux articles
Des champs de type Cases ajoutés aux articles

Nous allons déplacer les cases ajoutées en premier, pour cela, on survole les «cases à cocher», clique en gardant enfoncé notre bouton l’icône de déplacement (la première, des flèches bleues), et on monte la souris vers le haut, au dessus du premier champ. Un cadre jaune apparaît à l’endroit ou se placera le champ déplacé. On peut alors relâcher le bouton de la souris. Si la manœuvre vous paraît périlleuse, n’ayez crainte : cette façon de faire n’est qu’un raccourcis. On peut également définir l’emplacement du champs extra en le modifiant.

C’est d’ailleurs modifier le Champ Extras des cases que nous allons faire maintenant. Pour cela, on clique la seconde icône. Un formulaire détaillé apparaît alors :

Édition de cases à cocher
Édition de cases à cocher

On peut observer que les options sont nombreuses et divisées en onglets pour plus de clarté. Décrivons sommairement ce que sont ces onglets :

  • Description : concerne essentiellement les textes qui seront affichés ainsi que le nom technique du champ (le nom de la colonne SQL)
  • Utilisation : concerne des options sur le type de code HTML généré
  • Affichage : permet de compléter les descriptions du champ, par exemple par un message d’avertissement
  • Validation : indique le type de vérification à effectuer sur le contenu saisi
  • Restriction : permet de limiter l’affichage des champs à certaines personnes ou parties du site.
  • Technique : représente la liste des options liées à SPIP, à la base de données. Il permet également de modifier de type de saisie (pour passer de cases à radio par exemple).

À noter que les éléments affichés dans chaque onglet peuvent différer d’un type de saisie à une autre. Un champ «Ligne de texte» n’affiche pas les mêmes possibilités de configuration qu’un champ «Cases à cocher».

On comprend vite ainsi que lorsqu’on crée un nouveau champs extra, la première chose à faire est de changer les informations présentes dans l’onglet «Description» et en particulier son nom technique, le «nom du champ». Effectivement, cela nous évitera d’appeler le champ #CHECKBOX_1 dans un squelette, qui ne reflète pas une information sémantique, mais technique. On peut par exemple modifier le champ en le nommant «hobbies» (ce qui permettra d’utiliser #HOBBIES), et modifier son libellé et valeurs. Cela donnerait ensuite, après validation du formulaire de configuration de la case à cocher, la prévisualisation suivante :

Cases à cocher modifiées
Cases à cocher modifiées

Pour valider nos changements, il faut alors enregistrer le formulaire de champs extras. Ceci fait, on peut ensuite se rendre sur un article, nous être satisfait de voir nos deux champs présents, à la fois sur le formulaire d’édition et sur la vue du texte. Voici dans le formulaire des articles ce que cela donne :

Deux champs en plus sur les articles
Deux champs en plus sur les articles

Utiliser les champs dans les squelettes

Valeur d’un champ

Les champs extras sont comme les autres champs d’une table SQL, interrogeables en utilisant #NOM_DU_CHAMP.

Pour afficher donc le résultat d’un champ il suffit d’utiliser son nom. Le champ est d’autre part éditable avec la classe CSS #EDIT{nom_du_champ} si vous avez le plugin Crayons :

<p class='#EDIT{documentation}'>#DOCUMENTATION</p>

Valeur d’un champ multiple (cases à cocher, boutons radios,...))

Pour afficher la liste des valeurs de cases à cocher saisies par l’utilisateur, vous pouvez utiliser la balise #LISTER_VALEURS{nom_du_champ} :

#LISTER_VALEURS{hobbies} : Musique, Danse, ...
#LISTER_VALEURS{hobbies, ' / '} : Musique / Danse / ...
#LISTER_VALEURS**{hobbies} : tableau des résultat à exploiter par exemple avec une boucle POUR

Les valeurs affichées sont les valeurs lisibles par les humains, et non pas les valeurs informatiques brutes.

Pour afficher la liste des possibilités qu’il y avait de saisies, vous pouvez utiliser de la même manière #LISTER_CHOIX{nom_du_champ}

#LISTER_CHOIX{hobbies} : Musique, Danse, ...
#LISTER_CHOIX{hobbies, ' / '} : Musique / Danse / ...
#LISTER_CHOIX**{hobbies} : tableau des résultat à exploiter par exemple avec une boucle POUR

Informations d’une saisies

Enfin, vous pouvez récupérer n’importe quelle information sur la saisie en utilisant la balise #CHAMP_EXTRA{nom_du_champ}. Elle récupère tout le tableau d’information connue sur le champ extra. Cependant, elle est surtout utile pour afficher un des éléments #CHAMP_EXTRA{nom_du_champ, element} tel que le label :

#CHAMP_EXTRA{documentation,label}
#CHAMP_EXTRA{hobbies,label}
#CHAMP_EXTRA{hobbies,explication}

Créer de nouveaux types de saisies

Si les saisies présentes ne sont pas suffisantes pour votre utilisation, vous pouvez en créer de nouvelles dans votre répertoire squelettes ou votre plugin en créant :

  • saisies/ma_saisie.html,
  • saisies/ma_saisie.yaml et
  • saisies-vues/ma_saisie.html

Reportez vous à la documentation du plugin «Saisies» ou aux fichiers de saisies du même plugin pour vous en inspirer.

Nesting Level et XDebug

Si vous rencontrez cette erreur : Fatal error : Maximum function nesting level of ’100’ reached c’est que xdebug est actif. Il faut augmenter sa profondeur d’exécution. Par exemple en mettant dans votre config/mes_options.php l’instruction suivante (pensez à ouvrir <?php sur la première ligne et caractère du fichier si ce n’est pas fait, et pas la peine de le fermer)

<?php
ini_set('xdebug.max_nesting_level', 200);

Footnotes

[1Cette interface a évolué depuis la prise de cette vidéo ; cependant le fonctionnement est relativement identique

updated on 25 August 2020

Discussion

246 discussions

  • 2

    Salut,
    Je bugue sur l’affichage conditionnel et je me demande si ce que je tente est possible.

    J’ai vu que pour un champ oui/non, on peut utiliser

    [(#NOM_DU_CHAMP|oui) ce que l'on veut afficher ] 

    à partir du moment où “oui” a une valeur définie et pas non.

    J’ai fait un #NOM_DU_CHAMP en menu déroulant et je voudrais afficher que si l’option que je souhaite a été choisie.

    Par exemple champ couleur :
    -  vert
    -  bleu
    -  rouge

    Peut-on avoir une affichage conditionnel du type

    [(#NOM_DU_CHAMP|vert) ce que l'on veut afficher ] 

    ?
    Ou quelque chose qui aurait le même effet.

    Merci !

    • Il faut combiner le filtre |oui avec le filtre |== qui permet de vérifier l’égalité entre des valeurs :

      [(#CHAMP|=={vert}|oui) ce que l'on veut afficher ]
    • Merci tcharlss,
      je cherchais pas du tout au bon endroit... En fait, je savais pas trop ce que je cherchais ;) Mais, la doc va bien me servir !
      Merci encore !

    Reply to this message

  • Bonjour,

    Je reporte ici un bug que je pensais lié au plugin Pays mais qui d’après un autre contributeur a un rapport avec champs extras :
    https://contrib.spip.net/Liste-des-pays-avec-codes-ISO-3166-1#comment504613-502472

    Avec ce plugin à jour j’ajoute la liste des pays aux champs extra des auteurs mais cela retourne une erreur (par exemple sur la page d’un auteur) :

    Erreur SQL 1054
    Unknown column 'pays_1' in 'field list' 
    plugins/auto/cextras/v3.12.4/cextras_fonctions.php        champs_extras_voir_saisies(){ sql_fetsel(); }        356

    Le champ n’est pas ajouté en base.

    Merci !

    Reply to this message

  • Salut,
    Tout d’abord, merci pour ce superbe plugin !
    J’ai fais un formulaire du type #FORMULAIRE_EDITER_ARTICLE_PUBLIC.
    L’ajout des champs avec CHAMP_EXTRA se mettent automatiquement sur le formulaire, bref, presque trop facile ;)
    En ajoutant “Mots clés” au formulaire, je pensais que cela mettait un mot clé à l’article.
    Cela s’ajoute comme un champ supplémentaire “mot-clé”, mais ne met pas de mot-clé à l’article. C’est normal comme comportement ?
    Une piste pour mettre un mot-clé à l’article avec le formulaire public si la solution vient de champs extra ? Je sèche.
    Très bonne journée !

    Reply to this message

  • Bonsoir est il possible d’ajouter un nouveau champ
    Dans le formulaire forum svp si oui comment faire
    Merci

    Reply to this message

  • 1

    Bonjour,
    Après de nombreux tests, je me rend compte que la présence d’un champ extra Date perturbe le critère age d’une boucle article, Notamment age=0 qui n’affichera plus les articles du jours et restera vide, quelque soit la date affectée au champ extra Date de mon article. Le bug reste même après désactivation du plug-in, champs extras.

    • En poussant encore, je me rend compte que c’est le renommage des champs qui cause ce problème. Pourtant avec la bonne nomenclature alpha-numérique minuscule + tiret

    Reply to this message

  • Bonjour
    Je cherche à faire pour des rubriques qui ont un champs extra de type date dateextra, une boucle qui affiche les sous-rubriques d’une rubrique dont la dateextra est future. Comme le critère age mais pour une date de champs extras.
    J’ai bien tenté quelques pistes comme

    <BOUCLE_randomfilmchild(RUBRIQUES){id_parent}{ dateextra_age >=1}>

    Reply to this message

  • 3

    Bonjour,
    soit un spip SPIP 3.2.6-dev SVN [24210] + écran de sécurité 1.3.12
    me demander pas d’où sort cette version, j’en sais strictement rien
    avec les plugins a jour.

    j’utilise sur le fichier squelettes/prive/objets/liste/auteurs.html

    #LISTER_VALEURS{date_1}

    avec le code suivant :

    	<BOUCLE_liste_aut(AUTEURS){tout}{id_auteur?}{id_mot?}{where?}{statut?}{recherche?}{tri #ENV{par,multi nom},#GET{defaut_tri}}{pagination #ENV{nb,10} aut}{!compteur_articles_filtres #ENV{filtre_statut_articles,poubelle}}>
    		[(#LANG|changer_typo)]
    		<tr class="[(#COMPTEUR_BOUCLE|alterner{row_odd,row_even})][ (#EXPOSE|unique)][ (#NOM**|initiale|=={#ENV{i}}|et{#ENV{i}}|?{on}|unique)]">
    			<td class='statut'>[(#STATUT|puce_statut{auteur})]</td>
    			<td class="messagerie">[<a href="(#ID_AUTEUR|auteur_lien_messagerie{#EN_LIGNE,#STATUT,#IMESSAGE})">[(#CHEMIN{images/m_envoi.gif}|balise_img{<:info_envoyer_message_prive:>})]</a>]</td>
    			<td class='nom[ (#NOM|non)vide]'[(#LOGO_AUTEUR|non)colspan='1']><a href="[(#ID_AUTEUR|generer_url_entite{auteur})]"[ title="(#BIO*|couper{200}|attribut_html)"]>[(#RANG). ][(#NOM|trim|sinon{#BIO*|couper{80}|trim}|sinon{<:info_numero_abbreviation:>#ID_AUTEUR})]</a>[ <small>((#STATUT|=={0minirezo}|et{#WEBMESTRE|=={oui}}|?{<:statut_webmestre:>}))</small>][ <small>((#STATUT|=={0minirezo}|et{#AUTORISER{'','','',#ID_AUTEUR}|non}|?{<:statut_admin_restreint:>}))</small>]</td>
    			<td class='email'>[(#SESSION{statut}|=={0minirezo}|oui)[<a href='mailto:(#EMAIL)'>[(#EMAIL|couper{30})]</a>]]</td>
     
    			<td class='telephone'>#LISTER_VALEURS{input_phone}
    			<td class='inscription'>#LISTER_VALEURS{date_1}</td>
    		</tr>
    	</BOUCLE_liste_aut>

    du coup l’affichage est sous la forme : 2018-01-02 00:00:00

    c’est peu être normal, mais j’aurais aimé l’avoir sous la forme : 2/01/2018
    je suis allez lire https://www.spip.net/fr_article901.html mais cela a l’air de concerné #DATE et pas #LISTER_VALEURS

    que puis je faire ?, merci

    ou bien dois je passé par un champ texte pour avoir la date au format voulu ?

    • Mais pourquoi tu utilises #LISTER_VALEURS ? c’est fait pour les champs tabulaires… tu peux utiliser directement #DATE_1 puis aussi des fonctions de dates dessus [(#DATE_1|affdate)] ... donc bon.

    • Mais pourquoi tu utilises #LISTER_VALEURS ?

      Simplement parce-que j’avais rien compris au fonctionnement ;)

      Merci pour l’info

    • arf , j’ai un autre soucis si je renseigne pas la date, j’affiche quand même 30/11/1999
      suis sur qu’il y a une astuce pour empêcher cela , mais je voie pas trop

      ou alors utiliser la fonction | ?sioui, sinon
      https://www.spip.net/fr_article4186.html
      , peut être

      une idée, merci

    Reply to this message

  • 11

    J’ai repéré un bug que je pense avoir réussi à patcher.
    Scénario :
    Sur l’objet article j’ajoute un champ extra DATE/HEURE (Définition SQL : datetime DEFAULT ’0000-00-00 00:00:00’ NOT NULL) avec un affichage conditionnel. Lorsque je poste un article et que le champ est masqué (car il ne remplit pas les conditions), le champ concerné retourne une erreur.
    J’ai modifié le fichier cextras_pipelines.php à la ligne 175 (pipeline pre_edition) et ça a l’air de faire le taf :

    if (!is_null($extra)){
        $flux['data'][$nom] = corriger_caracteres($extra);
    }
    • Je viens de regarder vite fait, et je pense comprendre ce qu’il se passe effectivement.

      Lors du masquage des champs (avec afficher_si je suppose ?), les inputs relatifs à champs_extras (cextra_{nom}) ne sont pas masqués en même temps (c’est ma supposition), et sont donc postés par le formulaire.

      J’aurais tendance à dire que c’est à ce niveau là qu’il faudrait améliorer la situation, sans être certain que ça soit techniquement faisable ni facile.

      Ajouter if (!is_null($champ)) va provoquer des erreurs avec les champs de type checkbox (ou radio même), qui ne postent rien lorsqu’ils ne sont pas cochés, et c’est bien justement tout l’intérêt d’avoir ce champ hidden supplémentaire cextra_{nom} pour pouvoir invalider leur contenu lorsqu’ils viennent d’être décochés.

    • Si je comprend bien ton problème, Marcimat, je pense que j’ai la solution. En effet, depuis la refonte des afficher_si il est possible de déclarer des pseudo saisies auxiliaires a des saisies existantes pour les afficher_si, grâce au pipeline afficher_si_js_saisies_form.

      Exemple d’emploi https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/agenda/trunk/agenda_pipelines.php#L353

      je serais sur irc cet après midi, hésite pas à poser des questions si besoins

    • Cela étant dit, je n’ai pas d’erreur sur la date avec mon test local. Mon champ ’date’ est déclaré avec une normalisation ; est-ce le cas de votre côté ?
      Depuis l’interface, c’est en bas de l’onglet “Validation”
      En PHP ça serait quelque chose comme ça (j’ai simplement exporté mon test) :

      	$champs['spip_articles']['date_1'] = array(
      			'saisie' => 'date',
      			'options' => array(
      				'nom' => 'date_1',
      				'label' => 'Date',
      				'heure_pas' => '30',
      				'afficher_si' => '@input_1@=="oui"',
      				'sql' => 'datetime DEFAULT \'0000-00-00 00:00:00\' NOT NULL',
      				'rechercher_ponderation' => '2',
      			),
      			'verifier' => array(
      				'type' => 'date',
      				'options' => array(
      					'normaliser' => 'datetime',
      				),
      			),
      		);
    • Désolé mais je ne maîtrise pas les foncions PHP de SPIP et de ses plugins donc je ne comprends pas tout :p Surtout que notre politique est de ne faire aucun PHP dans nos sites SPIP.

      Oui le champ date est déclaré comme sur la capture pour la normalisation. Si le champ est affiché mais non renseigné, le formulaire passe bien. Par contre, si il est masqué, j’ai l’erreur suivante :

    • Hum,

      je me demande si cela ne vient pas plutot d’un souci au niveau mysql qui refuse sur certaine version les champs date 0000-00-00 etc.

      Il y a une possibilité de configurer à nouveau mysql pour ca (mais je ne sais pas comment faire exactement).

      https://core.spip.net/issues/4364

    • J’ai déjà exploré cette solution. Il faut modifier le fichier my.ini

      A la ligne :
      sql-mode = "STRICT_ALL_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, NO_ZERO_IN_DATE, NO_AUTO_CREATE_USER"
      Il faut virer NO_ZERO_DATE et NO_ZERO_IN_DATE il me semble. Mais, après différents ce n’est pas la solution :/

    • J’ai voulu dire “Après différents tests”. En effet, quand on poste le formulaire avec le champ date non masqué (donc sans erreurs de soumission du formulaire), la valeur par défaut 0000-00-00 est bien stockée en base.

    • Alors pour mysql récent, afin qu’il soit tolérant aux dates 0, tu peux mettre dans config/connect.php, avant l’appel à spip_connect_db :

      defined('_MYSQL_SET_SQL_MODE') || define('_MYSQL_SET_SQL_MODE',true);

      Ça corrigera l’erreur d’enregistrement de la date, mais pas le problème de fond.

    • Nous avons déjà define('_MYSQL_SET_SQL_MODE',true); dans ce fichier. ça ne change rien malheureusement.

    • Je suis étonné que ça ne change rien (pour sql set mode).

      Cependant, nous avons pris le temps de regarder avec Maieul sur le fond ; il y avait 2 problèmes, l’un dans Saisies, l’autre dans Champs Extras Core. Mettre à jour les 2 devrait améliorer la situation.

      -  Saisies 3.28.15 https://zone.spip.net/trac/spip-zone/changeset/118456
      -  Cextras 3.12.4 https://zone.spip.net/trac/spip-zone/changeset/118457

      Merci pour le signalement et le suivi.
      MM.

    • Merci à vous pour vos contributions et votre réactivité. Je viens de tester les MAJ et c’est parfait :)

    Reply to this message

  • 7

    Bonjour,

    Après le passage de mon site de http vers https, je ne peux plus enregistrer les changements de mes événements où j’ai ajouté des champs-extras.... ???

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

    Et lorsque je essaye à nouveau, j’ai une page blanche ??

    Une idée ?

    Merci

    • Bonjour,

      Quelle version de php et de SPIP ?
      Les plugins sont à jour ?
      En activant les erreurs php pas de piste ?

    • Bonjour,
      Merci de répondre si vite ! :-)

      SPIP 3.2.5 [24404] + écran de sécurité 1.3.12

      Les plugins sont à jour.

      Pour l’affichage des erreurs php, j’ai bien rajouté dans /config/mes_options.php

      error_reporting(E_ALL^E_NOTICE);
      ini_set ("display_errors", "On");

      Mais aucune alerte ne s’affiche ! :-/

    • et dans firebug, pas d’erreur JS ?

    • Je remarque ceci :

      Erreur lors du chargement de cet URI : Protocol error (unknownError): Could not load the source for blob:https://www.frsel.be/ffc24ca3-babf-4a92-9169-1c74783b8751.
      [Exception... “Failed to open input source ’blob:https://www.frsel.be/ffc24ca3-babf-4a92-9169-1c74783b8751’” nsresult: “0x805303f4 ()” location: “JS frame :: resource://devtools/shared/DevToolsUtils.js :: mainThreadFetch/< :: line 666” data: yes]
      Stack: mainThreadFetch/<@resource://devtools/shared/DevToolsUtils.js:666:15
      mainThreadFetch@resource://devtools/shared/DevToolsUtils.js:531:10
      _getSourceText@resource://devtools/server/actors/source.js:299:27
      Line: 666, column: 0

    • Je me rends compte que j’ai le même problème dans les articles où j’ai aussi un champ extra ??.. :-(

    • et en vidant tmp et local par hasard ?

    • Bon, voilà, je n’y ai rien compris....
      Je suis allé voir si il y avait des mises à jour récente pour les plugins...
      J’ai vu que saisies avait sorti une mise à jour aujourd’hui.
      J’ai donc installé la mise à jour...

      Là, c’était l’horreur...
      Plusieurs plugins ne voulaient plus s’activer.

      J’ai donc chercher... J’ai remarqué qu’il fallait la version 3.5 de spip_bonux... Or, c’est la version 3.4.6 qui est sur le plugin.spip.net...

      J’ai donc virer ma version 3.4.6 de spip bonux, je l’ai réinstallée, j’ai réinstallé saisies.... Et là, miracle, tout redevenais normal. J’ai donc pu réinstallé tous les autres plugins y compris champ extra et champ extra interface... Et tout est redevenu normal.

      Sinon, oui, j’avais vidé le cache et le dossier tmp avant toute cette misère...
      Enfin, tout refonctionne... mais je n’y ai rien compris.

      Merci encore pour ta réactivité !

    Reply to this message

  • Jmtconseils

    J’utilise Champs Extras lié à Inscription3
    Dans le cas d’utilisation de case unique et en prenant le choix : Valeur par défaut sur On, je n’ai pas dans mon formulaire lié à Inscription3 la case cochée. Factuellement il manque le code checked=“checked” dans le codage de l’input.

    Alors que si j’utilise depuis Formidable une case unique avec le même paramétrage, le codage de l’input est bon.

    D’où viendrait le problème de construction du codage HTML de l’input de la case à cocher ?

    Merci par avance.

    Reply to this message

Ajouter un commentaire

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom