spip-contrib-extensions/saisies
Par Maïeul Rouquette, le 19 novembre 2025 à 22h31min :
fix: problème d’initialisation du datepicker de spip sur les saisies date lors de la modification d’un article avec champ extra
Ref: Problème sur les champs DATE créer avec CHAMPS EXTRA
Le problème qui se pose : lorsqu’on édite un article avec un champ extra
dont le type de saisie est date, SPIP force l’activation du datepicker dessus, ce qui crée conflit
d’interface + empeche de bien soumettre la bonne valeur en base (pour
cause de valeur incorrecte envoyée en HTTP).
On ne voyait pas le problème lors des tests de saisies v6 parce qu’on
bossait uniquement en formidable.
Plus en détail:
- Lorsque côté privé on va sur la page d’édition d’un article, les
script du datepicker de SPIP sont chargés (pour modifier la date de
l’article) - On édite l’article : comme SPIP charge le formulaire en AJAX (mais
pourquoi ? j’ai toujours trouvé cela peut pratique pour debuguer et
sans plus value au quotidien) et que le dateur vérifie ce qui se passe
au chargement ajax → PAF - jquery applique betement la ligne formulaires/dateur/inc-dateur.html · 2.x · spip / prive · GitLab et comme notre saisie
datea une classe.date(déterminé par le type de l’input) PAF on se retouve avec un datepicker dessus
3 solutions possibles tant que SPIP utilise encore son
dateur/.datePicker
- a. Celle-ci : on applique avec anticipation
.datePickerà l’input de
la saisie.date - b. on modifier le script de spip pour ne pas appliquer si on a la classe
.nodatePicker→ mais ce serait à faire dans une version mineure de
SPIP pour que cela serve, donc peu semver - c. on supprime la classe qui est redondate avec le
typede l’input
mais d’un point de vue CSS designer c’est sans doute pas top.
Modifié
CHANGELOG.md
saisies/date.html