Je viens de tomber sur un petit souci en utilisant SPIP, champs extra et saisies.
Le contexte :
je rajoute trois champs à l’objet rubrique : categorie, prefixe et couleur chacun avec une saisie différente (spécifique catégorie, input et couleur)
je ne modifie rien manuellement dans les squelettes ou formulaires des rubriques.
Quand j’édite une rubrique existante, j’obtiens le formulaire d’édition de la rubrique complétée correctement avec les champs extra.
Visuellement tout va bien.
Mais en y regardant de plus près, je me suis aperçu que l’attribut id de mes inputs de saisie est toujours le même : id=“champ_new” ce qui n’est pas normal.
Si on regarde dans les saisies, on voit que cela n’est possible que s’il existe une variable d’environnement ‘id’ qui a pour valeur ‘new’.
Je suis passé en debug sur le formulaire et particulièrement la fonction formulaires_editer_rubrique_charger_dist() qui fait appel directement à la fonction générique formulaires_editer_objet_charger().
J’ai passé des lignes de code pour arriver à la ligne 240 de la fonction balise_FORMULAIRE__contexte() du fichier balise/formulaire_.php.
On y voit donc :
if (!isset($valeurs['id'])) {
$valeurs['id'] = 'new';
}
C’est clairement là que la variable ‘id’ est positionnée.
Ce que je ne comprends pas c’est que ça devrait se passer pour tout objet qui fait appel aux fonctions d’API génériques.
Je suis étonné de découvrir ce problème aujourd’hui.
Je ne vois pas trop la solution car je suppose qu’on ne positionne pas cette variable ‘id’ pour rien même si je ne vois pas son intérêt car normalement ‘id_xxx’ de l’objet est déjà positionné.
Peut-être une compatibilité avec un ancien fonctionnement ?
C’est sur que de toute façon il aurait fallu éviter d’utiliser id dans Saisies pour désigner l’attribut id et lui préférer attribut_id par exemple car cette variable est assez commune dans SPIP mais c’est plus facile à dire aujourd’hui.
Quelqu’un a-t-il une idée car j’ai l’impression qu’on est dans une impasse là sauf en faisant un saut quantique incompatible ?
Des ids similaires, ça se serait vu quand même car l'id de l'input est lié au for du label, ça ne passerait pas du tout un test d'accessibilité de base.
Je confirme que le problème est déclenché par la déclaration d’un champ extra pour lequel la saisie demande explicitement le env.
C’est donc un cas rare mais c’est un problème réel.
Attention,
Comme dit Éric, il faut bien demander à récupérer "env" (pas testé mais je crois que ça fait la différence)
Oui, la différence est là visiblement.
Par ailleurs, dans ton test, class="editer editer_input_1 saisie_input" & for="champ_input_1" me laissent penser que tu es dans ta première rubrique n'est-ce pas ?
Pas du tout, c'était un test rapide depuis l'interface graphique (Iextras, mais c'est pareil avec une déclaration en PHP), avec un champ extra qui s'appelait juste "input_1", comme je disais.
L'id sur les inputs ne varie pas selon la valeur de l'id de l'objet (ce n'est pas lié).
Et heureusement, encore un fois, sinon ça casserait aussi du ciblage en css ou en js par les id, justement.
ce que tu dis m’étonnais beaucoup, j’ai retesté des champs extra sur une
rubrique et je n’ai pas du tout de id=« champ_new » sur mes input
J’ai toujours ce genre de markup pour les champs extra (celui ci
s’appelle input_1 pour le test) :
Salutations.
Attention,
Comme dit Éric, il faut bien demander à récupérer « env » (pas testé mais je crois que ça fait la différence)
Par ailleurs, dans ton test, class=« editer editer_input_1 saisie_input » & for=« champ_input_1 » me laissent penser que tu es dans ta première rubrique n’est-ce pas ? La valeur « new » est attribuée uniquement à la création d’une nouvelle rubrique (je me souviens l’avoir vu et avoir réutilisé le même truc pour certains de mes formulaires CVT)