[Résolu] Problème champs date avec Champs extra

Bonjour,
Sur un Spip 4.3.3 avec Champs Extra 4.2.0 et C-E-Interface 4.2.0, …
J’ai créé quelques champs extra sur les articles d’une branche spécifique et en particulier 4 champs Date: date_jour_1, date_jour_2, date_jour_3, date_jour_4.
Tout semble ok en terme d’affichage et d’utilisation, c’est bien restreint à la branche souhaitée. Quand j’édite un article avec ces champs, quel que soit le nombre de date que je saisisse (car toutes les dates ne sont pas obligatoires) j’ai au moment de sauver l’erreur:

Une erreur technique a empêché l’enregistrement correct du champ *'date_jour_1'*,*'date_jour_2'*,*'date_jour_3'*,*'date_jour_4'*.

Même si je remplis les 4 dates j’ai l’erreur. A partir de là je ne peux plus sortir de l’édition de cet article je reviens toujours sur cet écran avec cette erreur. Par contre je peux sortir en allant sur Accueil puis en retournant sur l’article ou je constate que ce que j’ai saisi est bien sauvegardé avec les dates que je n’ai pas remplies sont au 30/11/1999. Donc ça fonctionne mais j’ai cette erreur qui me coince dans l’édition de l’article.
Je me demandais si ça n’était pas lié au souci des dates « nulles » dans mySQL ou à la définition SQL proposée « datetime DEFAULT ‹ 0000-00-00 00:00:00 › NOT NULL » étant donné que je veux autoriser la possibilité d’une saisie nulle … mais les modifs que j’ai tentées ne sont pas couronnées de succès.
Dans spip.log:

2024-10-10 14:56:25 185.119.202.184 (pid 1070553) :Pri:CRITIQUE: Erreur enregistrement en base article/56 champs :array (
  'date_jour_1' => 
  array (
    'post' => '0000-00-00',
    'save' => '0000-00-00 00:00:00',
  ),
  'date_jour_2' => 
  array (
    'post' => '1999-11-30',
    'save' => '1999-11-30 00:00:00',
  ),
  'date_jour_3' => 
  array (
    'post' => '1999-11-30',
    'save' => '1999-11-30 00:00:00',
  ),
  'date_jour_4' => 
  array (
    'post' => '1999-11-30',
    'save' => '1999-11-30 00:00:00',
  ),
)
2024-10-10 14:56:25 185.119.202.184 (pid 1070553) :Pri:ERREUR: echec editeur article: Une erreur technique a empêché l’enregistrement correct du champ <i>'date_jour_1'</i>,<i>'date_jour_2'</i>,<i>'date_jour_3'</i>,<i>'date_jour_4'</i>.

Une idée de ce qui pourrait causer ce genre de pbm ?
Pierre

tu aurais un export yaml/php de tes champs extras. Les champs dates c’est tjr un peu la plaie avec saisies, on n’a jamais trouvé un truc satisfaisant pour bien régler cela.

Je peux envoyer ça ou ?
Pierre.

Bah ici par ex…en mettant le contenu entre backstick.

Ou si confidentiel tu peux mecrire a monprenom@monprenom.net

Rien de très confidentiel:

spip_articles:
  -
    options: { nom: date_jour_1, label: 'Date jour 1', heure_pas: '30', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'datetime DEFAULT ''0000-00-00 00:00:00'' NULL' }
    verifier: [{ type: date, options: { normaliser: date, vider_date_nulle: oui } }]
    identifiant: '@6707e0689469f'
    saisie: date
  -
    options: { nom: date_jour_2, label: 'Date jour 2', heure_pas: '30', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'datetime DEFAULT ''0000-00-00 00:00:00'' NOT NULL' }
    verifier: [{ type: date, options: { normaliser: date_ou_datetime, vider_date_nulle: oui } }]
    identifiant: '@6707e2ac85417'
    saisie: date
  -
    options: { nom: date_jour_3, label: 'Date jour 3', heure_pas: '30', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'datetime DEFAULT ''0000-00-00 00:00:00'' NOT NULL' }
    verifier: [{ type: date, options: { normaliser: date_ou_datetime, vider_date_nulle: oui } }]
    identifiant: '@6707e2ae976b7'
    saisie: date
  -
    options: { nom: date_jour_4, label: 'Date jour 4', heure_pas: '30', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'datetime DEFAULT ''0000-00-00 00:00:00'' NOT NULL' }
    verifier: [{ type: date, options: { normaliser: date_ou_datetime, vider_date_nulle: oui } }]
    identifiant: '@6707e2afb1786'
    saisie: date
  -
    options: { nom: duree_formation, label: 'Durée formation', id_groupe: '6', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'text DEFAULT '''' NOT NULL' }
    verifier: {  }
    identifiant: '@6707e36c4140c'
    saisie: mot
  -
    options: { nom: categorie_formation, label: 'Catégorie formation', id_groupe: '5', restrictions: { secteurs: '', branches: '29', compositions: '', voir: { auteur: '' }, modifier: { auteur: webmestre } }, sql: 'text DEFAULT '''' NOT NULL' }
    verifier: {  }
    identifiant: '@6707e5f4b68d0'
    saisie: mot

Mouais, c’est encore un problème sur le fait qu’on a la meme saisie pour la date ou par la date + l’heure.

On a résolu le cas de la config par défaut si la personne mettait l’heure, mais pas l’inverse si la personne met pas l’heure.

Bref, essaie d’installer cette version du plugin vérifier, et tiens nous au courant https://git.spip.net/spip-contrib-extensions/verifier/-/archive/normaliser_date_ou_datetime_depuis_sql/verifier-normaliser_date_ou_datetime_depuis_sql.zip

Bonjour,
Merci pour votre retour !

J’ai mis en place et l’erreur a changée:

Une erreur technique a empêché l’enregistrement correct du champ 'date_jour_1'.

C’est à dire que maintenant je n’ai plus l’erreur que sur le premier champ, pas sur les suivants. Au début j’ai pensé que c’était parce que le premier était le seul rempli, mais si je choisi une date dans le second champ, je n’ai toujours l’erreur que sur le premier ! Idem si je ne mets aucune date dans le premier champ et quelque chose dans le second, l’erreur reste sur le premier.

Pierre.

oui alors je parie que le premier champ a été créé il y a plus longtemps que les autres. On peut voir qu’il utilise une normalsaition de type " date" et pas « date_ou_datetime » malgrés le fait qu’il attende en mysql du datetime.

Le plus simple serait donc que tu modifie la normaliation dans l’interface de config du champ (sous l’onglet « Validation »
image

Bonjour,
Ok c’est résolu. J’avais créé tous les champs en même temps mais j’avais aussi bidouillé ce réglage pour voir, le premier champ était le seul que j’avais modifié d’où l’erreur qui restait dessus.
Bref c’est résolu, merci beaucoup !
Pierre.

Parfait ! Je viens de sortir une v3.3.0 du plugin verifier, histoire que d’autres ne se retrouvent pas dans la meme situation…

1 « J'aime »