Ahh le b_b est revenu, tu n'étais pas là du coup j'ai fait un trunk de ton plugin,
j'espère que ça te convient.
No souci pour le #HTML5,
c'était mon intention de départ mais j'avais zappé
j'ai mis [(#HTML5) placeholder… ] en place
++
Le 25/01/16 20:51, Bruno Bergot a écrit :
Hop,
Le 18/01/2016 18:07, toutati@free.fr a écrit :
Les erreurs sont déjà reportés dans les champs, donc supprimer la ligne des erreurs globales devrait suffire
Ahh le b_b est revenu, tu n'étais pas là du coup j'ai fait un trunk de
ton plugin,
j'espère que ça te convient.
No souci pour le #HTML5,
c'était mon intention de départ mais j'avais zappé
j'ai mis [(#HTML5) placeholder… ] en place
Super, merci
Que penses-tu de ma remarque à propos du message d'erreur global ?
Le 25/01/16 20:51, Bruno Bergot a écrit :
J'ai un doute sur le fait de retirer le message d'erreur global.
Est-ce que la modification ne dégrade pas l'accessibilité ?
Pour info, le formulaire du plugin est calqué sur le
formulaire_ecrire_auteur de la dist qui affiche bien ce message :
Ahh le b_b est revenu, tu n'étais pas là du coup j'ai fait un trunk de
ton plugin,
j'espère que ça te convient.
No souci pour le #HTML5,
c'était mon intention de départ mais j'avais zappé
j'ai mis [(#HTML5) placeholder… ] en place
Super, merci
Que penses-tu de ma remarque à propos du message d'erreur global ?
Oups, j'avais oublié ce point.
trouvée la solution appliquée ici Connexion · GitLab
cf r94789
et pour l'ancre, le # de action était doublé, ce qui donnait un retour à l'id comme ceci ##formulaire_contact12
au lieu de #formulaire_contact12
r94790
++
touti
Le 25/01/16 20:51, Bruno Bergot a écrit :
J'ai un doute sur le fait de retirer le message d'erreur global.
Est-ce que la modification ne dégrade pas l'accessibilité ?
Pour info, le formulaire du plugin est calqué sur le
formulaire_ecrire_auteur de la dist qui affiche bien ce message :
Que penses-tu de ma remarque à propos du message d'erreur global ?
Oups, j'avais oublié ce point.
trouvée la solution appliquée ici Connexion · GitLab
Vu, merci. Du coup, je pense qu'on peut de nouveau utiliser une syntaxe simple de test dans le formulaire au lieu des boucles condition (ça me semble plus léger à lire).
cf r94789
et pour l'ancre, le # de action était doublé, ce qui donnait un retour à
l'id comme ceci ##formulaire_contact12
au lieu de #formulaire_contact12
r94790
Je viens de tester en 3.0 (avec des urls propres html), et cela casse le formulaire, cf l'erreur suivante :
Tu rencontres le pb de la double ancre en 3.0 ou 3.1 ?
Autre point, les balises traduire sont en trop dans le paquet.xml, ce plugn n'est pas encore traduit, et c'est salvatore qui s'occupe de l'ajout de ces balises dès qu'il commence à traduire un plugin :
Pour résumer, il semble que tu as créé un trunk pour assurer la compatibilité avec la nouvelle structure HTML des formulaires de SPIP 3.1. Est-ce bien ça ?
Si oui, deux options :
- on peut changer la compat du trunk, limiter à partir de SPIP 3.1 et supprimer le plugin.xml
- peut-être serait-il plus simple de brancher ce micro plugin sur saisies, ce qui aurait l'avantage d'assurer la compat 3.0 et 3.1 sans avoir besoin de créer un trunk
Que penses-tu de ma remarque à propos du message d'erreur global ?
Oups, j'avais oublié ce point.
trouvée la solution appliquée ici Connexion · GitLab
Vu, merci. Du coup, je pense qu'on peut de nouveau utiliser une syntaxe simple de test dans le formulaire au lieu des boucles condition (ça me semble plus léger à lire).
Ok, je vais changer ça !
cf r94789
et pour l'ancre, le # de action était doublé, ce qui donnait un retour à
l'id comme ceci ##formulaire_contact12
au lieu de #formulaire_contact12
r94790
Je viens de tester en 3.0 (avec des urls propres html), et cela casse le formulaire, cf l'erreur suivante :
Tu rencontres le pb de la double ancre en 3.0 ou 3.1 ?
En 3.1
Autre point, les balises traduire sont en trop dans le paquet.xml, ce plugn n'est pas encore traduit, et c'est salvatore qui s'occupe de l'ajout de ces balises dès qu'il commence à traduire un plugin :
Pour résumer, il semble que tu as créé un trunk pour assurer la compatibilité avec la nouvelle structure HTML des formulaires de SPIP 3.1. Est-ce bien ça ?
Oui j'ai respecté l'usage qui est de créer un trunk quand on veut participer à un développement
sans casser l'existant (cqfd tralala … tsoin tsoin) et/ou quand l'initiateur ou l'initiatrice du plugin n'est pas joignable
et que l'on ne souhaite pas empiéter sur un plugin qui sert déjà.
Si oui, deux options :
- on peut changer la compat du trunk, limiter à partir de SPIP 3.1 et supprimer le plugin.xml
- peut-être serait-il plus simple de brancher ce micro plugin sur saisies, ce qui aurait l'avantage d'assurer la compat 3.0 et 3.1 sans avoir besoin de créer un trunk
… quitte à fusionner ensuite branches et trunk comme tu le proposes, aucun souci,
je te laisse brancher sur saisies alors ?
++
touti
- peut-être serait-il plus simple de brancher ce micro plugin sur
saisies, ce qui aurait l'avantage d'assurer la compat 3.0 et 3.1 sans
avoir besoin de créer un trunk
- peut-être serait-il plus simple de brancher ce micro plugin sur
saisies, ce qui aurait l'avantage d'assurer la compat 3.0 et 3.1 sans
avoir besoin de créer un trunk
… quitte à fusionner ensuite branches et trunk comme tu le proposes,
aucun souci,
je te laisse brancher sur saisies alors ?
Voilà qui est fait :
J'ai gardé la branche v0 pour SPIP 2.1, et la branche v1 pour SPIP 3.0 et 3.1 (qui nécessite saisies).
