[spip-dev] La gestion des emails de SPIP

Dev
1

Bonjour tout le monde !

Voici une petite proposition d’amélioration, car je trouve qu’il y a un soucis avec la gestion des mails dans SPIP.

Cela fait maintenant 2 sites sur lequel je travail qui ont une zone membre assez importante. Et systématiquement, il faut personnaliser l’affichage des emails (la com, l’image de marque, tout ça).

Et je trouve que c’est particulièrement laborieux, difficile de s’y retrouver entre :

  • Le mails d’inscriptions qui est dans modeles/.
  • Les mails qui sont dans notifications/.
  • Les notifications avancées qui ont aussi un squelettes mail_inscriptions dans notifications (mais en fait c’est pour prévenir les admins des inscriptions).
  • Les notifications qui ont un fichier php ET un fichier html.
  • Les multiples chaînes de langues qui composent certains mails (il suffit d’ouvrir prive/modeles/mail_inscription).

J’ai l’impression qu’il y a une certaine anarchie dans tout cela.

Il y a aussi une certain difficulté de personnalisation. Aujourd’hui l’envoie de mail doit ce faire avec le style du site, son logo, etc.
Hors pour le moment, c’est compliqué, je personnalise le mail d’inscription, mais pour une raison obscure, le html ne fonctionne pas, impossible de mettre un bouton. Pourquoi ?

Bref, j’ai l’impression qu’il y a besoin de remettre de l’ordre dans tout cela.

Pour commencer, est-ce qu’on ne pourrait pas passer Facteur dans le core de SPIP ?

Ensuite, on pourrai centraliser les emails dans un dossier unique ? Notifications semble être le plus plus proche d’une norme.

Cependant, quand on cherche “notification” sur spip.net, on ne trouve rien:

Alors que cela semble être un système assez complexe et complet qui mériterai une belle documentation.

Au niveau des tests, il serait super intéressant de pouvoir prévisualiser l’affichage des mails (s’ils sont tous regroupés au même endroit, cela facilitera ce genre de développement).

Qu’est-ce que vous en pensez ?

2

Je pense aussi que c'est le gros bazar depuis toujours là-dedans (tout comme plein d'autres choses pas réellement normalisées). Le fait qu'il y ait des contenus emails dans le dossier modeles/ est une aberration typique, effectivement (même : #WTF ?)

En revanche je ne pense pas que Facteur doive intégrer le core. Après des années qu'on ait commencé l'élagage, faut-il encore rappeler en 2016 que le but est d'avoir le moins de choses possibles dans le core, et le plus en plugin ?

En revanche, pourquoi pas réfléchir à le proposer pour l'intégrer dans la distribution par défaut… à voir si c'est vraiment utile ou pas (mais peut-être que c'est ça que tu voulais dire). Je n'ai pas trop d'avis là-dessus pour l'instant.

Enfin, documenter et normaliser (ou l'inverse…) l'API "notifications", ça me parait important. API qui n'en est justement pas une tant que ce n'est pas réellement normalisé. Au grand minimum toujours avoir les choses dans le même dossier… c'est vraiment le minimum !

3

Hello,

En revanche, pourquoi pas réfléchir à le proposer pour l’intégrer dans la distribution par défaut… à voir si c’est vraiment utile ou pas (mais peut-être que c’est ça que tu voulais dire). Je n’ai pas trop d’avis là-dessus pour l’instant.

Oui, le mettre dans plugin-dist. C’est effectivement ce que je voulais dire.
Pour moi, plugin-dist, cela fait partie du core de SPIP.

Niveau utilité, je pense que cela apporte des fonctions utilent dans certain environnement et aucune régression: si on ne configure rien, c’est le comportement par défaut de SPIP qui est conservé.
Dès que je dois faire quelques choses en rapport avec les mails, je fini d’office par installer facteur.

Enfin, documenter et normaliser (ou l’inverse…) l’API « notifications », ça me parait important. API qui n’en est justement pas une tant que ce n’est pas réellement normalisé. Au grand minimum toujours avoir les choses dans le même dossier… c’est vraiment le minimum !

Si facteur intègre plugin-dist, on pourrai aussi y centraliser tout ce qui concerne l’envoie de mail de SPIP: les squelettes dans “notifications” et supprimer les fonctions de mail du core (envoyer mail et notification par exemple).
Un SPIP sans facteur deviendra donc un SPIP qui n’envoie pas de mail du tout.

Il y a aussi des confusions dans les noms de fonction:

notification
notification_envoyer_mail
envoyer_mail

Au début, j’ai pensé qu’il fallait uniquement utiliser notification uniquement, mais j’ai vu notification_envoyer_mail utilisé directement dans le core.

4

Hey non, ça ne peut pas marcher comme ça.

Il reste quelques petites merdouilles par-ci par-là mais théoriquement le Core DOIT fonctionner tout seul. Tout ce qui est en plugins-dist ce sont des fonctionnalités ajoutées en plus, que l'on décide de fournir dans la distribution par défaut (essentiellement parce que ça reproduit le fonctionnement de ce que SPIP fournit depuis ses débuts).

Or le core (= tout ce qui n'est pas dans plugins-dist), il envoie bien des mails, et c'est vraiment obligatoire pour certaines fonctionnalités qui font bien partie du noyau, telle que la création ouverte de nouveaux comptes par exemple. Si dans ecrire/ ou prive/ ou autre tu as des choses qui ont l'obligation de pouvoir envoyer des mails, alors le fait d'envoyer des emails doit être dans le core, en tant qu'API de base, même si ce sont des mails tous simples. Le plugin Facteur c'est en plus, c'est là pour "augmenter" la fonctionnalité, avec la librairie PHPMailer.

5

ah ?

6

Non, ça ne va pas marcher puisque j'ai dit très clairement qu'il restait des merdouilles.

Mais c'est bien le but recherché, et la plupart des choses sont séparées comme il faut. Il reste quelques références à des choses devenues plugins dans certains fichiers du core (squelettes de l'admin ou des trucs comme ça je ne sais plus). Il faudrait sûrement les listes exhaustivement quelque part, ça pourrait être bien.