[SPIP Zone] fonction verifier_corriger_date_saisie présente deux fois ?

Hello,

je viens de me rendre compte que la fonction verifier_corriger_date_saisie() est présente deux fois :
1- dans Bonux : https://zone.spip.org/trac/spip-zone/browser/plugins/spip-bonux-3/inc/date_gestion.php
2- dans Organiseur : https://zone.spip.org/trac/spip-zone/browser/core/branches/spip-3.1/plugins/organiseur/inc/date_gestion.php

C'est pas une fois de trop ?
Peetdu
ps : ce que je ne comprend pas, c'est pourquoi il n'y a pas un Warning (voir fatal error) ?

Hello,

Je pense qu’il n’y a pas de warning car SPIP charge le « premier » fichier trouvé par include_spip(). Donc, à « aucun » moment on a les deux fichiers et donc un scope entre les deux fonctions définies.

Ybbet

OK. Merci pour l'info.

Sinon, ne mériterait-elle pas de figurer dans le core ?
C'est bien pratique tout de même.

P

Le 04/01/2017 à 14:26, Ybbet Spip a écrit :

Hello,

Je pense qu'il n'y a pas de warning car SPIP charge le "premier" fichier
trouvé par include_spip(). Donc, à "aucun" moment on a les deux fichiers
et donc un scope entre les deux fonctions définies.

Ybbet

Le 4 janvier 2017 à 14:19, Peetdu <peetdu@gmail.com
<mailto:peetdu@gmail.com>> a écrit :

    Hello,

    je viens de me rendre compte que la fonction
    verifier_corriger_date_saisie() est présente deux fois :
    1- dans Bonux :
    Connexion · GitLab
    <Connexion · GitLab;
    2- dans Organiseur :
    Connexion · GitLab
    <Connexion · GitLab;

    C'est pas une fois de trop ?
    Peetdu
    ps : ce que je ne comprend pas, c'est pourquoi il n'y a pas un
    Warning (voir fatal error) ?

    ----
    spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
    http://listes.rezo.net/mailman/listinfo/spip-zone
    <http://listes.rezo.net/mailman/listinfo/spip-zone&gt;

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Hello,

Si c'est dans organiseur, c'est dans la distrib de SPIP. :slight_smile:
Et pour le moment, comme on n'a pas encore mis en place les distrib personnalisées, on peut dire que c'est dans le core. :smiley:

----------
Ybbet

Le 4 janv. 2017 à 21:31, Peetdu <peetdu@gmail.com> a écrit :

OK. Merci pour l'info.

Sinon, ne mériterait-elle pas de figurer dans le core ?
C'est bien pratique tout de même.

P

Le 04/01/2017 à 14:26, Ybbet Spip a écrit :
Hello,

Je pense qu'il n'y a pas de warning car SPIP charge le "premier" fichier
trouvé par include_spip(). Donc, à "aucun" moment on a les deux fichiers
et donc un scope entre les deux fonctions définies.

Ybbet

Le 4 janvier 2017 à 14:19, Peetdu <peetdu@gmail.com
<mailto:peetdu@gmail.com>> a écrit :

   Hello,

   je viens de me rendre compte que la fonction
   verifier_corriger_date_saisie() est présente deux fois :
   1- dans Bonux :
   Connexion · GitLab
   <Connexion · GitLab;
   2- dans Organiseur :
   Connexion · GitLab
   <Connexion · GitLab;

   C'est pas une fois de trop ?
   Peetdu
   ps : ce que je ne comprend pas, c'est pourquoi il n'y a pas un
   Warning (voir fatal error) ?

   ----
   spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
   http://listes.rezo.net/mailman/listinfo/spip-zone
   <http://listes.rezo.net/mailman/listinfo/spip-zone&gt;

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Le 04/01/2017 à 14:19, Peetdu a écrit :

Hello,

je viens de me rendre compte que la fonction verifier_corriger_date_saisie() est présente deux fois :

Bonjour,
sachant qu il n est pas totalement impossible que je m y prenne comme un gros manche, mais pour ma part, et depuis longtemps et jusqu a 3.1.0 si j'utilise un champ de saisie date (directement ou avec l interface champs extra) il est impossible de valider la saisie du formulaire, le format de date etant toujours considéré comme incorrect par la fonction _verif
C est un vieux sujet, c'est bizarre que cela ne soit pas corrigé depuis le temps, aussi me demande si c'est pas moi qui beugue...

amicalement
triton

Le 05/01/2017 à 09:59, triton a écrit :

Bonjour,
sachant qu il n est pas totalement impossible que je m y prenne comme un
gros manche, mais pour ma part, et depuis longtemps et jusqu a 3.1.0 si
j'utilise un champ de saisie date (directement ou avec l interface
champs extra) il est impossible de valider la saisie du formulaire, le
format de date etant toujours considéré comme incorrect par la fonction
_verif
C est un vieux sujet, c'est bizarre que cela ne soit pas corrigé depuis
le temps, aussi me demande si c'est pas moi qui beugue...

Pour ce point précis lorsque le JS d'un champ date est utilisé, il faut modifier le champ posté dans la fonction verifier() du formulaire CVT pour l'adapter à ce qu'attend le champ date en question dans la base de données.

Pour ce faire la solution actuelle est de "normaliser" le champ reçu en utilisant le plugin Verifier, qui a une méthode pour cela.

Lorsqu'on crée un Champ Extras de date, il fait automatiquement cela (pour peu que le plugin Vérifier soit présent). De même avec la Fabrique, qui génère le code également pour les saisies de dates.

Ça peut ressembler à :

function formulaires_xxx_verifier_dist($id_xxx){

  $erreurs = array();

  // [...]

  $verifier = charger_fonction('verifier', 'inc');

  foreach (array('date_parution', 'date_modif_manuelle', 'date_debut') AS $champ) {
    $normaliser = null;
    if ($erreur = $verifier(_request($champ), 'date', array('normaliser'=>'datetime'), $normaliser)) {
      $erreurs[$champ] = $erreur;
    // si une valeur de normalisation a ete transmis, la prendre.
    } elseif (!is_null($normaliser)) {
      set_request($champ, $normaliser);
    // si pas de normalisation ET pas de date soumise, il ne faut pas tenter d'enregistrer ''
    } elseif (!is_null(_request($champ))) {
      set_request($champ, '0000-00-00 00:00:00');
    } else {
      set_request($champ, null);
    }
  }

  // Si c'est un objet éditorial connu, on peut utiliser la fonction générique de vérification

  $erreurs += formulaires_editer_objet_verifier('xxx', $id_xxx, array('titre'));

  return $erreurs;

}

MM.

Pour ce point précis lorsque le JS d'un champ date est utilisé, il faut modifier le champ posté dans la fonction verifier() du formulaire CVT pour l'adapter à ce qu'attend le champ date en question dans la base de données.

Pour ce faire la solution actuelle est de "normaliser" le champ reçu en utilisant le plugin Verifier, qui a une méthode pour cela.

Lorsqu'on crée un Champ Extras de date, il fait automatiquement cela (pour peu que le plugin Vérifier soit présent). De même avec la Fabrique, qui génère le code également pour les saisies de dates.

Ça peut ressembler à :

function formulaires_xxx_verifier_dist($id_xxx){

Bonjour,
OK pour la fonction dans _verifier, c'est comme ça que je faisais jusqu à présent, mais je pensais que c'était plutot un patch, mais bon, si on fait ses formulaires cvt soi même, c'est très accessible d ajouter cette fonction de normalisation.
Par contre, pour moi, jusqu à présent, c'était impossible d utiliser un champ date avec extra et Cextra (c est surtout ça qui m étonnait) , mais je viens de vérifier sur un spip tout neuf 3.1.3 avec derniere version des plugins saisie et verifier, et ca marche nickel !
Donc, c est bien moi qui ait un effet de bord inattendu sur 1 ou 2 de mes sites qui empêche le bon fonctionnement de la saisie "date" via extra
Merci pour l explication
amicalement
triton