fix: problème d'initialisation du datepicker de spip sur les saisies date...

fix: problème d'initialisation du datepicker de spip sur les saisies date lors de la modification d'un article avec champ extra

Ref: https://discuter.spip.net/t/probleme-sur-les-champs-date-creer-avec-champs-extra/194497/

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 https://git.spip.net/spip/prive/-/blob/2.x/formulaires/dateur/inc-dateur.html?ref_type=heads#L144 et comme notre saisie date a 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 type de l'input mais d'un point de vue CSS designer c'est sans doute pas top.