spip-contrib-extensions/mailsubscribers
-
Par placido, le 10 décembre 2020 à 22h30min :
v2.15.2 : texte explicatif pour newsletter_subscribe.
Afficher un texte explicatif au début du formulaire newsletter_subscribe.
Option à activer depuis la page de configuration (ne change donc rien à l'existant).
Deux nouvelles chaines de langues, à personnaliser au besoin.
J'ai comme un doute sur les les items de langue ajoutés cf :
"Rejoignez la newsletter pour suivre la publication de nouveaux contenus"
Rejoindre une newsletter ? C'est une bande de potes ? ^^
"Ainsi, conservez une visibilité sur nos dernières publications avec possibilité de vous désinscrire à tout moment. Pas d\'envois abusifs, ni de partage de coordonnées à des tiers, promis."
La formulation me semble "aguicheuse", et la "visibilité" commerciale, de plus, rien ne permet de présumer qu'un⋅e wembestre ne partagera pas les données d'un site.
Quasi certain que ces items seront le plus souvent personnalisés, c'est donc dommage de balancer ça aux gens qui travaillent sur trad.spip.
D'autres avis ?
PS : c'est toujours sympa de passer par une PR, ça permet de discuter avant
+1 si on doit pouvoir ajouter un texte c'est uniquement optionnel, par défaut vide, et l'explication du champ doit juste être pour dire quoi configurer dedans. Mais aucun exemple entier comme ça de texte qui seront forcément totalement différent sur chaque site, suivant chaque contexte, pour ce besoin je vois pas de phrase qui serait générique (et par défaut c'est rien comme avant de toute façon).
J'ai comme un doute sur les les items de langue ajoutés cf :
"Rejoignez la newsletter pour suivre la publication de nouveaux contenus"
Rejoindre une newsletter ? C'est une bande de potes ? ^^
"Ainsi, conservez une visibilité sur nos dernières publications avec
possibilité de vous désinscrire à tout moment. Pas d\'envois abusifs, ni
de partage de coordonnées à des tiers, promis."
La formulation me semble "aguicheuse", et la "visibilité" commerciale,
de plus, rien ne permet de présumer qu'un⋅e wembestre ne partagera pas
les données d'un site.
Non, en effet. Mais, mais ça reste une posture tout à fait vraisemblable
et qui suppose un respect RGPD. A chacun de personnaliser à son souhait.
Quasi certain que ces items seront le plus souvent personnalisés, c'est
donc dommage de balancer ça aux gens qui travaillent sur trad.spip.
On peut revoir la formulation pour un truc plus neutre, certes.
L'intérêt du commit, c'est surtout d'éviter de surcharger le formulaire
manuellement pour inserer une notice explicative à chaque fois.
D'autres avis ?
PS : c'est toujours sympa de passer par une PR, ça permet de discuter
avant
C'est pour cette raison que je n'ai pas poussé de tag.
J'attends vos avis de formulation plus à propos, donc.
+1 si on doit pouvoir ajouter un texte c'est uniquement optionnel, par défaut vide, et l'explication du champ doit juste être pour dire quoi configurer dedans. Mais aucun exemple entier comme ça de texte qui seront forcément totalement différent sur chaque site, suivant chaque contexte, pour ce besoin je vois pas de phrase qui serait générique (et par défaut c'est rien comme avant de toute façon).
Ah ouais, conditionner l'affichage de l'explication à une longueur de la
chaîne non nulle, c'est pas bête (et ça économise l'option de configuration)
Le question sous jacente, c'est est-ce qu'une chaine vide ne va pas
faire dérailler salvatore et cie ?
je suis pas trop chaud pour cette modif qui a été introduite.
Il y a 2 possibilités :
• soit un permet dans la configuration du plugin d’afficher une explication dans le formulaire, en permettant alors de saisir le texte a afficher depuis le formulaire de configuration
• soit on a aucune configuration, et ce pourrait etre juste un texte que l'on passe en appelant le formulaire, en option (il y a un tableau option en second argument qui permet deja de personaliser des choses)
MAIS tout cela me parait bancal, car cela présume de ce que va faire le formulaire, qui peut être utilisé pour souscrire à une ou plusieurs listes, et chaque liste et site peuvent avoir des usages très différents.
Chaque liste peut par ailleurs fournir une description de ce à quoi elle sert, et il me semble que ce serait le bon endroit pour mettre un texte aguicheur donnant envie de s’abonner (car c’est bien de cela qu’il sagit au final)
ENFIN j’aimerai fortement éviter que ce formulaire de souscription ne devienne un arbre de noël à options, comme on trouve dans certains plugins.
Je pars du principe que de toute façon on couvrira jamais 100% des besoins, et je préfère avoir quelque chose de simple et propre qui couvre 80%, a charge pour ceux qui veulent plus de faire un peu de personnalisation, qu’une usine à gaz qui fasse 90%
Eventuellement on peut envisager de faire, à côté, sous un autre nom, ou dans un plugin de complément, un formulaire d’inscription newsletter multiconfigurable qui fasse tout ou presque.
Mais je rappelle qu’il y a déjà une option de formidable qui permet de faire les inscriptions à une liste, et qui peut donc être utilisé pour faire de la personalisation de formulaire d’inscription.
Bref, cette modif me parait pas très adaptée ni souhaitable, et en effet comme le rappelle b_b, une PR c’est pas mal pour discuter d’une proposition
Bref, cette modif me parait pas très adaptée ni souhaitable, et en effet comme le rappelle b_b, une PR c’est pas mal pour discuter d’une proposition
Arf, le commit qui prend en compte les remarques est déjà parti sur
master. (de plus mon client git me sort des messages d'erreurs pour la
création de branches distantes sur git.spip.net ?!), désolé.
Bon si vous trouvez que la proposition n'est toujours pas bonne, je
ferai un autre revert.
Je pense que tu devrais tout revert et copier tes propositions dans une branche, pour faire une PR et la discuter. Mais pas commiter dans le master comme ça. Depuis qu'on est passé en git, même les auteurices principales des plugins font ça dans leurs propres plugins, quand c'est pas de la correction de bug, cf dans formidable, prix, saisies, gis, et plein d'autres. On fait une branche (interne au plugin, on a tous les droits), et on en parle dans une PR.
git checkout master
git branch dev/ajout_trucmuche
git checkout dev/ajout_trucmuche
=> modifs
git pull origin dev/ajout_trucmuche
=> gitea, créer une PR à partir de la branche
