Vos commentaires

• # Le 31 janvier à 12:49, par RastaPopoulos En réponse à : Saisies

  Ben c’est juste logique quoi... Saisies ne peut que s’insérer dans le pipeline « formulaire_verifier », qui forcément est appelé après la fonction de base.

  Sinon il faudrait modifier SPIP pour modifier les pipelines : « formulaire_pre_verifier » + « formulaire_post_verifier » et ce pour C, V, et T. Tout comme il y a « pre_edition », « post_edition ».

  Donc tu pourrais plutôt faire ta suggestion en lançant le sujet sur spip-dev, c’est pas idiot du tout !

  Répondre à ce message

• # Le 31 janvier à 12:26, par Yffic En réponse à : Saisies

  Hello

  Le problème de vérification des saisies obligatoires non affichées étant en passe d’être résolu, un autre problème voit le jour ;-(

  La vérification de Saisies est effectuée après celle du plugin appelant. L’inverse ne serait-il pas plus logique ? => Saisies s’occupe de vérifier tout ce qui a été défini lors de la définition de chaque saisie, puis l’utilisateur vérifie ses trucs propres à son fonctionnement. J’ai par exemple un champ input qui s’attend à recevoir un entier, l’idéal serait que, quand j’arrive dans ma fonction de vérification, cette vérification soit déjà effectuée...

  Répondre à ce message

• # Le 18 janvier à 16:59, par crowker En réponse à : Saisies

  Bonjour,

  Mon problème est résolu mais peut-être qu’il pourra intéresser du monde ;-)

  Je me suis confronté à un problème avec l’utilisation de 2 champs date dans un même formulaire : dans un premier temps, j’avais déclaré ces 2 champs avec le type « date » dans mes #SAISIE et si mes icônes de datepicker s’affichaient bien, pas d’ouverture de calendrier lors du clic sur l’icone...
  J’ai trouvé la solution en déclarant mon premier champ en « DATE » et mon second en « INPUT »

  Du coup, le code généré par le Jquery ne se charge qu’une seule fois et les 2 champs fonctionnent avec leur datepicker respectif ;-)

  Voici le code :
  

  1. [(#SAISIE{date, date_debut, debut_periode, label=Date de début de période,class=date})]
  2. [(#SAISIE{input, date_fin, fin_periode, label=Date de fin de période,class=date})]

  Télécharger

  Répondre à ce message

• # Le 3 novembre 2011 à 17:44, par Jean-Baptiste Pressac En réponse à : Saisies

  Bonjour,
  J’utilise Saisies pour faire un formulaire de CFG. Je n’ai pas de problème pour récupérer la valeur d’un champ de type « radio », par exemple, si je crée un champ :

  [(#SAISIE{radio, institut, label=Choix de l'institut de tutelle, defaut=autre,datas=#ARRAY{....}})]

  je peux récupérer la valeur choisie dans un squelette par la balise habituelle de CFG :

  [(#CONFIG{kitcnrs/institut})]

  Par contre, ça se corse avec les champs de type « selecteur_rubrique ». Par exemple, avec un champ :

  [(#SAISIE{selecteur_rubrique, id_rubrique_a_la_une, label=« À la une »})]

  Si j’utilise :

  [(#CONFIG{kitcnrs/id_rubrique_a_la_une)]

  la balise renvoie un tableau. J’ai bien essayé d’utiliser le filtre table_valeur :

  [(#CONFIG{kitcnrs/id_rubrique_a_la_une|table_valeur{0})]

  Mais ça renvoie le type d’objet (article/rubrique) et son identifiant séparés par un pipe. Y aurait-il un moyen pour récupérer la valeur du champ ?

  Merci.

  • # ^ Le 3 novembre 2011 à 18:50, par RastaPopoulos En réponse à : Saisies

    Il y a une fonction |picker_selected{rubrique} (par exemple), associée. Ça permet de récupérer un tableau des identifiants du type d’objet mis en paramètre (ici rubrique). Ensuite si yen a qu’un tu prends le premier. [(#CONFIG{truc}|picker_selected{rubrique}|table_valeur{0})] Un truc dans ce genre. Par contre je ne sais plus où se trouve la fonction donc il faut peut-être inclure quelque chose pour l’avoir. C’est un sélecteur qui vient de bonux (et qui est intégré dans SPIP 3 maintenant), c’est pas dans Saisies.

  • # ^ Le 4 novembre 2011 à 10:29, par Jean-Baptiste Pressac En réponse à : Saisies

    ça marche sans qu’il soit nécessaire de faire une inclusion, merci bien.

  Répondre à ce message

• # Le 2 novembre 2011 à 11:36, par Jean-Baptiste Pressac En réponse à : Saisies

  Bonjour,
  Après un parcours rapide de la documentation, j’ai l’impression que Saisies ne propose pas de champ pour uploader des fichiers et les supprimer. Est ce que cette fonctionnalité est envisageable ? Merci.

  • # ^ Le 2 novembre 2011 à 11:39, par RastaPopoulos En réponse à : Saisies

    Tout est toujours envisageable... si on a du temps pour le développer. :)

    Ça n’existe pas pour l’instant et c’est compliqué pour le faire proprement et générique. C’est dans la « todo list » depuis le tout début du projet.

  • # ^ Le 2 novembre 2011 à 15:36, par Jean-Baptiste Pressac En réponse à : Saisies

    C’est noté, merci.

  Répondre à ce message

• # Le 12 octobre 2011 à 16:24, par David En réponse à : Saisies

  Bonjour,

  J’ai plusieurs problèmes qui apparaissent dans l’admin avec ce plugin :

  -  Le chargement des images téléchargés dans spip tourne indéfiniment, les images se téléchargent bien malgré tout lorsqu’on actualise la page
  -  La page informations personnelle dans auteurs ne s’affiche plus
  -  Le formulaire mot de passe oublié ne s’affiche plus

  J’ai la dernière version de spip (2.1.11)

  • # ^ Le 12 octobre 2011 à 16:56, par RastaPopoulos En réponse à : Saisies

    Ce plugin n’a rien à voir avec tous ces points. D’ailleurs ce plugin ne modifie pas le comportement de SPIP (il ne s’insère dans aucun de ses points d’entrée) et n’ajoute aucune page. C’est un outil pour développeur qui ajoute de nouvelles fonctions.

    Qu’est-ce qui fait dire que c’est ce plugin précisément qui provoque ça ? As-tu désactivé TOUS les plugins pour ne tester que l’activation/désactivation de celui là ?

  • # ^ Le 12 octobre 2011 à 17:17, par David En réponse à : Saisies

    En effet je me suis trompé, c’est le plugin afficher objet qui pose ce problème. Désolé.

  Répondre à ce message

• # Le 22 mars 2011 à 01:21, par Cédric Couvrat En réponse à : Saisies

  Bonjour,
  Je tente d’ajouter un champ date comportant un datepicker avec SAISIE.
  Quand je mets :
  

  1. [(#SAISIE{input, date_echeance,
  2. label=<:kaye:label_date_echeance:>,
  3. class=date})]

  Télécharger

  le champ est fonctionnel mais il n’y a pas le date picker.

  Quand je mets :
  

  1.                 [(#SAISIE{date, date_echeance,
  2.                         label=<:kaye:label_date_echeance:>,
  3.                         class=date})]  

  Télécharger

  il y a bien le date picker mais celui-ci réinitialise la date (0000-00-00)

  dans la table de bdd le champ est de type date (0000-00-00)

  Que dois-je faire pour que ça fonctionne ?

  Merci pour votre aide

  • # ^ Le 22 mars 2011 à 08:22, par RastaPopoulos En réponse à : Saisies

    Chez-moi-ça-marche ©.

    Sans exemple concret (URL ?) je ne vois pas comment aider.

  • # ^ Le 22 mars 2011 à 11:55, par RastaPopoulos En réponse à : Saisies

    Ok donc comment prévu, ni le datepicker, ni le plugin Saisies n’ont rien à voir là-dedans. Ce n’est d’ailleurs même pas lui qui met la date. C’est vous qui dites quoi mettre comme valeur dans votre fonction charger() du CVT. Donc à vous d’aller chercher la bonne valeur et de la formater dans le bon sens (vu que le datepicker est en format français alors qu’en base ça sera en format SQL).

    Donc faut aller chercher votre date, transformer la version SQL en version français jj/mm/aaaa, et la mettre dans le contexte de charger() : $contexte['date_echeance'] = ...; et inversement dans le traiter() il faut retransformer le date FR en date SQL pour l’enregistrer en base.

  • # ^ Le 24 mars 2011 à 10:55, par Cédric Couvrat En réponse à : Saisies

    Merci beaucoup pour ces précisions. Je vais creuser cette piste.
    Si je n’y parviens pas, il me suffirait donc de changer, dans la bdd, le type du champ date_echeance, pour passer de DATE à VARCHAR ?
    Encore merci pour votre aide et bonne continuation dans vos projets.

  • # ^ Le 29 août 2011 à 02:17, par gilcot En réponse à : Saisies

    J’ai été accidentellement confronté au même problème et je précise :
    -  on peut bien mettre une date par défaut (sinon il n’y a rien, ce qui équivaut à 0000-00-00 en bdd) et cette date par défaut peut être au format ISO-8601 ! ainsi, dans ma fonction charger(), un 'date_echeance'=>date('Y-m-d') renvoie positionne bien la date sur aujourd’hui (affiché 29/08/2011) \o/
    -  mais mon vérifier() —qui s’assure que d’une part la date est au format ISO-8601 et qu’elle est valide met systématiquement le champ en erreur (et donc sans ça, la date qui arrive en bdd est incorrecte, ce qui équivaut à 0000-00-00 pour MySql)  ;-( il faut donc, au niveau du traiter(), le retraiter... (chez moi, sans revérification, c’est : $parts_date_echeance=explode('/',_request('date_echeance')); $bonne_date_echeance=parts_date_echeance[2].'-'.parts_date_echeance[1].'-'.parts_date_echeance[0]; ce qui est bien entendu une façon de faire parmi d’autres)

  • # ^ Le 29 août 2011 à 10:07, par RastaPopoulos En réponse à : Saisies

    Oui, la fonction verifier() doit faire son travail de vérification avec la valeur de la saisie en « / ». Il y a d’ailleurs une fonction du plugin Vérifier pour ça. Et ensuite au dernier moment il faut transformer la date pour la mettre au format ISO. On peut utiliser un preg_replace() en une fois, ça va plus vite. Ou bien utiliser les fonctions de date de PHP pour transformer la date en « / » en timestamp qu’on retransforme en date ISO ensuite.

  • # ^ Le 29 août 2011 à 13:49, par gilcot En réponse à : Saisies

    Merci pour la confirmation RastaPopoulos.

    Le preg_replace() pour transformer une date-fr en date-iso serait du genre :
    $date_echeance = preg_replace('$(0?[1-9]|[1-2][0-9]|3[0-1])/(0?[1-9]|1[0-2])/([1-3][0-9]{3,3})$','\\3-\\2-\\1',$date_echeance);
    _ Mais j’évite d’utiliser les regex quand on peut faire simplement sans... Je ne suis pas certain que ce sois plus rapide (que le str_replace() par exemple dans les cas simples), et par contre ils utilisent plus de ressources matérielles (processeur et mémoire)  :-S
    _ Cependant, si on doit utiliser les regex PCRE/Perl, autant en profiter un max (code non teste) :
    $date_echeance = preg_replace('$[\d{1,2}][\W]+[\d{1,2}][\W]+[\d{1.4}]$','\\5-\\3-\\1',$date_echeance);
    Pour la fonction PHP transformant les dates en « / » en timestamp, si tu as une piste je veux bien la noter dans un coin parce-que je ne connais que strtotime() qui hélas n’accepte que les dates en anglais... (et 03/08/2002 par exemple, est le 8 mars en anglais, et le 3 aout en français...)  :-( ou ISO... Dommage car, un coup de $date_echeance = date('Y-m-d',strtotime($date_echeance)); et ça roulerait

    Pour la vérification, le plugin verifier dispose bien d’une fonction verifer_date_dist qui prend les date-fr et s’assure que le nombre de jours est compris entre 1 et 31 et le nombre du mois entre 1 et 12. (Il me semble aussi qu’il y avait une limitation sur l’année, mais elle n’avait de sens —a mon avis— que pour les dates de naissance...)
    N’utilisant pas ce plugin, je décompose la date comme déjà mentionne et la passe a checkdate() (qui fait les mêmes vérifications sans la limitation d’année, et en prime vérifie la concordance entre des fins de mois —du coup on a ure erreur pour le 30 février par exemple) :
    

    $parts_date_echeance = explode('/',_request('date_echeance'));
if ( !checkdate($parts_date_echeance[1],$parts_date_echeance[0],$parts_date_echeance[2]) ) $erreurs['date_echeance'] = _T('date_invalide');

    (c’est bien entendu une méthode parmi d’autres, et elle peut avoir des variantes comme utiliser trois variables chaine au lieu d’une variable tableau :
    

    list($jour_echeance,$mois_echeance,$annee_echeance) = explode('/',_request('date_echeance'));
if ( !checkdate($mois_echeance,$jour_echeance,$annee_echeance) ) $erreurs['date_echeance'] = _T('date_invalide');

  • # ^ Le 29 août 2011 à 14:12, par RastaPopoulos En réponse à : Saisies

    Le plugin Vérifier n’a aucune limitation d’année, et fait bien un checkdate : http://zone.spip.org/trac/spip-zone/browser/_plugins_/verifier/verifier/date.php

    Pour le preg_replace c’était surtout pour la lisibilité, et comme c’est après avoir déjà vérifié que c’était le bon format, t’as pas à tester le format exact, etc, ya juste à changer l’ordre.
    

    1. preg_replace('|([\d]+)/([\d]+)/([\d]+)|', '$3-$2-$1', $date)

    Ceci dit ça fait un certain temps qu’on réfléchit à ce que le plugin Vérifier sache aussi formater des données en sortie, après vérification. Exemple qu’on puisse vérifier la validité d’une date qui peut être dans plusieurs formats, mais par contre qu’en sortie on est toujours du ISO. Ou que pour un nom de famille tout soit mis en majuscule sans accent, si le système en a besoin, etc. Ce genre de transformation post-vérification.

  • # ^ Le 29 août 2011 à 17:54, par gilcot En réponse à : Saisies

    Cool ça ; ça fait un bout de temps que j’avais pas retesté. En plus c’est un peu comme j’avais commencé à écrire ma fonction de vérification (sauf que j’avais listé les six combinaisons possibles —jma, jam, mja, maj, amj, ajm— et que j’étais iso par défaut)
    Par contre, ce n’est pas une mauvaise chose de pouvoir poser des bornes sur les dates (par exemple site pour ados refusant donc plus d’un certain âge, ou site nécessitant un âge minimum, ou une combinaison des deux), à condition que cela reste optionnel...

    Dans le cas présent (testé avant de poster hier), ça servirait à rien de renvoyer une sortie ISO : le champ date l’accepte, mais le reconverti au format FR !  :-( D’un autre côté, bien que l’idée de formatage soit séduisante, on s’éloigne de la simple vérification et on fait du traitement de présentation...
    Je pense que c’est aux DatePicker de permettre de faire une saisie suivant le format local de l’usager (donc jj/mm/aaaa pour une interface en français, mais mm/jj/aaa pour une interface en anglais) mais de renvoyer la valeur dans un format standard (ici ISO), comme le prévoit HTML5 justement pour les nouveaux champs date, datetime, time.
    À suivre...

    Cédric, j’espère que tu ne l’as pas fait : un VARCHAR (un CHAR est mieux vu que la taille est fixe...) ne sera pas forcément plus économique en place occupée et ça ne change rien au problème puisqu’il faudra quand même que tu stocke au format ISO qui est justement indépendant (pratique pour l’internationalisation et la portabilité) et offre un certain nombre d’avantage (les algorithmes de comparaison et le tri sont plus simples, de plus on sait facilement les convertir vers d’autres formats que l’inverse)

  Répondre à ce message

• # Le 25 août 2011 à 11:41, par audwill En réponse à : Saisies

  bonjour,

  sur un site spip2.0.12 + ecran de secu
  la mise à jour du plugin Interfaces de champs extra « Nécessite le plugin SAISIES en version [1.13.0 ;] minimum. »
  Or en mettant à jour le plugin saisies ça plante le site (écran blanc en back et frontoffice). En enlevant le dossier du plugin par ftp le site se réaffiche normalement.
  La version antérieure du plugin saisies 1.8.12 [43285] ne plante pas le site... mais ne permet pas d’installer Interfaces pour champs extra.

  merci de votre aide,

  • # ^ Le 26 août 2011 à 19:11, par Matthieu Marcillaud En réponse à : Saisies

    Bonjour Audwill,

    Un écran blanc est souvent le signe d’une erreur PHP non affichée (ce qui est par défaut le cas de PHP maintenant). Il serait bien, le temps de tester, de faire afficher les erreurs PHP de la sorte, en ajoutant ce code dans ton fichier config/mes_options.php :

    1. // afficher toutes les erreurs
    2. error_reporting(E_ALL);
    3. @ini_set("display_errors", "On");

    Télécharger

    Une fois fait, en remettant le plugin saisies et interfaces, devrait logiquement apparaître l’erreur bloquante que tu pourras nous transmettre ici, ce qui nous aidera à comprendre ce qui se passe.

    Merci bien.

  • # ^ Le 29 août 2011 à 12:07, par audwill En réponse à : Saisies

    Salut,
    et merci pour ta réponse !

    J’ai copié le bout de code dans config/mes_options.php :

    1. <?php
    2. // afficher toutes les erreurs
    3. error_reporting(E_ALL);
    4. @ini_set("display_errors", "On");
    5. ?>

    Télécharger

    et réactivé le plugin saisies mais... j’ai toujours une page blanche sans affichage d’erreur php.

    Je supprime ensuite le dossier du plugin via ftp pour que le site s’affiche à nouveau. et là en backoffice j’ai cette indication :
    Erreur dans les plugins : plugins/auto/saisies/saisies_options.php, plugins/auto/saisies/balise/saisie.php, plugins/auto/saisies/inc/saisies.php, plugins/auto/saisies/saisies_pipelines.php (indication qui disparait quand je vide le cache à nouveau).

    que puis-je faire d’autre pour vous donner plus d’infos ?

  Répondre à ce message

• # Le 12 juin 2011 à 15:50, par Artlogic En réponse à : Saisies

  Yo

  spip.php ?page=saisie.css surcharge une de mes css coté site public. Voir ici le vilain cadre bleu sur la recherche en haut à gauche. J’ai trouvé saisies.css.html à la racine du répertoire du plugin, toutefois cette css ne comporte pas les class du formulaire de recherche. Comment cela fonctionne-t-il ? Comment retrouver ces class et y apporter des surcharges ?

  • # ^ Le 12 juin 2011 à 21:31, par RastaPopoulos En réponse à : Saisies

    Je ne sais absolument pas d’où ça sort. C’est pas dans une des inclusions du fichier ? Pfff, j’ai jamais voulu ça moi (cherchez le coupable).

  • # ^ Le 12 juin 2011 à 21:33, par RastaPopoulos En réponse à : Saisies

    Ouais voilà, ya quelqu’un qui a ajouté les styles PRIVÉS de bonux à cette CSS, pour utiliser le sélecteur d’articles/rubriques. Mais du coup ça style d’autres choses, aussi, c’est pourri.

    Il faudrait ajouter ça seulement si on est dans la partie privée, mais c’est pas super non plus car on peut très bien vouloir ce sélecteur dans la partie publique aussi. Faudra demander à Yffic.

  • # ^ Le 13 juin 2011 à 00:19, par Artlogic En réponse à : Saisies

    Oui, c’est effectivement ennuyeux. J’ai modifié mon css pour que celui de saisies soit surchargé. Nombreux sont les plugins à gonfler les pages avec des css ou des .js sans que l’on en ai systématiquement besoin. Sur un site comme celui là où prêt de 30 plugins sont couramment utilisés, ça fait vite beaucoup de poids pour rien.

  • # ^ Le 13 juin 2011 à 09:31, par RastaPopoulos En réponse à : Saisies

    Ben non ça fait pas beaucoup de poids puisque de toute façon toutes les CSS d’un même media=truc sont concaténées + compressées et donc envoyées en un seul fichier au client, qui ensuite l’aura en cache. Donc c’est pas le problème le plus chiant.

    Là c’est surtout que ça ajoute des styles très « génériques » sans qu’on s’en aperçoivent, et qui en plus sont au départ réservés uniquement à la partie privée, et c’est vraiment n’importe quoi...

  Répondre à ce message

• # Le 11 juin 2011 à 20:50, par polatouche En réponse à : Saisies

  J’ai un formulaire qui fonctionne bien en utilisant #GENERER_SAISIES.
  Il est dans le répertoire formulaires d’un plugin et appelé dans un article par

  1. <formulaire|monformulaire>

  Si j’essaye de mettre certains champs dans un ’fieldset’ le formulaire ne s’affiche plus, sans message d’erreur, ni log.
  Pour tester en étant certain d’éliminer les typos, j’ai installé les fichiers film.html et film.php de cet article : http://www.spip-contrib.net/Un-formulaire-C-V-T-avec-Saisies-par-l-exemple dans le répertoire formulaires du plugin et j’appelle ce formulaire dans un article par

  1. <formulaire|film>

  Même problème, qui disparait si je supprime le fieldset (en laissant les saisies du fieldset).
  C’est déjà arrivé à quelqu’un ? Une idée ?

  • # ^ Le 11 juin 2011 à 22:09, par RastaPopoulos En réponse à : Saisies

    C’est tout le formulaire qui ne s’affiche pas ou juste les saisies contenues dans le fieldset ?

  • # ^ Le 12 juin 2011 à 05:50, par polatouche En réponse à : Saisies

    Tout le formulaire. Et ça semble stopper les calculs de spip :
    Du coté public, ça affiche l’en-tête et le début (titre, auteur,...) mais pas de pied de page ni de colonne extra.
    Coté privé la tentative d’édition de l’article du coté backend me renvoie ce code en tout et pour tout comme page html : ("formulaire ici", à la fin, est le texte de l’article avant le tag formulaire)

    1. <div class="champ contenu_surtitre vide">
    2. <div class='label'>Sur-titre</div>
    3. <div dir='ltr' class='crayon article-surtitre-9 surtitre'></div>
    4. </div>
    5. <div class="champ contenu_titre">
    6. <div class='label'>Titre :</div>
    7. <div dir='ltr' class='crayon article-titre-9 titre'>test formulaire bis</div>
    8. </div>
    9. <div class="champ contenu_soustitre vide">
    10. <div class='label'>Sous-titre</div>
    11. <div dir='ltr' class='crayon article-soustitre-9 soustitre'></div>
    12. </div>
    13. <div class="champ contenu_descriptif vide">
    14. <div class='label'>Descriptif :</div>
    15. <div dir='ltr' class='crayon article-descriptif-9 descriptif'></div>
    16. </div>
    17. <div class="champ contenu_chapo vide">
    18. <div class='label'>Chapeau</div>
    19. <div dir='ltr' class='crayon article-chapo-9 chapo'></div>
    20. </div>
    21. <div class="champ contenu_nom_site vide">
    22. <div class='label'>VOIR EN LIGNE :</div>
    23. <div dir='ltr' class='crayon article-hyperlien-9 nom_site'></div>
    24. </div>
    25. <div class="champ contenu_texte">
    26. <div class='label'>Texte</div>
    27. <div dir='ltr' class='crayon article-texte-9 texte'><p>formulaire ici&nbsp;:</p>
    28. <div>

    Télécharger

    Si ça peut aider, c’est un SPIP 2.1.10 [17657] + images(1.0.1), msie_compat(1.0), porte_plume(1.7.8), safehtml(1.3.7), vertebres(1.0), verifier(0.1.9), cfg(1.16.0), crayons(1.9.4), skeleditor(2.5.3), spip_bonux(2.2.21), z(1.7.9), compositions(1.2.3), saisies(1.9.9), compresseur(1.0.1)

  • # ^ Le 12 juin 2011 à 13:40, par RastaPopoulos En réponse à : Saisies

    Chez-moi-ça-marche. ©

    Si c’est tout le formulaire et même apparemment toute la page entière qui est bloquée, c’est forcément qu’il y a une erreur PHP quelque part qui arrête tout.

    Mais sans code sous les yeux, je vais pas pouvoir aider.

  • # ^ Le 12 juin 2011 à 14:30, par polatouche En réponse à : Saisies

    Hélas, le code est celui de l’article d’exemple...
    Il ne marche pas chez moi.
    Les particularités par rapport à l’exemple :
    -  Les fichiers sont dans le répertoire formulaires d’un plugin.
    -  C’est un site qui fait partie d’une mutualisation.

    Pas d’idée ?

  • # ^ Le 12 juin 2011 à 18:29, par polatouche En réponse à : Saisies

    J’ai reproduit en installant un spip neuf avec un spip_loader.php downloadé aujourd’hui et les plugins bonux vérifier et saisies à jour de svn ://zone.spip.org/spip-zone/_plugins_ :
    

    1. Date    Sun, 12 Jun 2011 16:20:59 GMT
    2. Server  Apache/2.2.16 (Ubuntu)
    3. X-Powered-By    PHP/5.3.3-1ubuntu9.5
    4. Vary    Cookie,Accept-Encoding
    5. Composed-By     SPIP 2.1.10 @ www.spip.net + images(1.0.1), msie_compat(1.0), porte_plume(1.7.8), safehtml(1.3.7), vertebres(1.0), verifier(0.1.9), spip_bonux(2.2.21), saisies(1.9.9), compresseur(1.0.1)

    Télécharger

    Le code de l’exemple ne fonctionne pas. Le même en supprimant les fieldset fonctionne.

  • # ^ Le 12 juin 2011 à 21:37, par RastaPopoulos En réponse à : Saisies

    Ben je te dis que si tout s’arrête c’est qu’il y a une erreur PHP. Si tu fais un site en local, en mode « développement », tu DOIS activer l’affichage des erreurs PHP, sinon tu ne risques pas de pouvoir tester grand chose.

    Le code que tu m’indiques à une parenthèse en trop à la fin... :)

  • # ^ Le 13 juin 2011 à 04:02, par polatouche En réponse à : Saisies

    RÉSOLU

    Merci pour ton aide !
    en ajoutant
    

    1. error_reporting(E_ALL^E_NOTICE);
    2. ini_set('display_errors',1);

    Télécharger

    ça m’a permis de voir que le problème était dû à l’absence du plugin YAML.
    Une fois ce plugin installé tout fonctionne correctement (non, il n’y a pas de parenthèse en trop dans le code d’exemple)

  Répondre à ce message