[spip-dev] spip-notifications

Dev
1

Hello !

C'est à propos des plugins "notifications" et "spip-notifications". Un méa-culpa d'abord car d'avoir géré nos plugins artégo hors spip-zone a amené à la confusion concerant ces 2 plugins. Je sais que c'est un sujet de discorde, mais j'aimerais mettre ça de côté siouplaît. Avec spip 2 on souhaite se rapprocher de la communauté et repartir à neuf si possible. Cf. la mise dans le dépôt svn de spip-lettres (pour spip 2), spip-formulaires (pour spip 1.9.2, je lancerais une autre discussion à ce sujet) spip-notifications, spip-surcharges, spip-meteo (et gis_2 via IRC avec AngelOfDeath51)

Notifications et spip-notifications ne font pas exactement la mm chose : spip-notifications permet d'envoyer des mails html/texte/mixte (personnalisables via des squelettes) via une api (sans doute très similaire au plugin phpmailer qui est un fork de spip-notif) ; notifications envoie des mails à la suite de messages postés sur les forums, je ne pense pas avoir vu de gestion du html. Ils portent donc un nom similaire mais ne font pas la même chose, dites-moi si je me trompe ? Je suis donc partant pour :
- soit fusionner les 2, si la personnalisation des mails via des squelettes vous intéresse + envoi html via smtp...
- soit changer de nom si l'envoi de notifications html ne vous intéresse pas

A vous

Pierre aka maiis

2

- soit fusionner les 2, si la personnalisation des mails via des squelettes
vous intéresse + envoi html via smtp...

l'envoi de notifications avec des "patrons" (pour reprendre le jargon
de spip-listes) est intéressant, oui.

L'envoi SMTP par contre devrait faire l'objet d'un plugin séparé !

- soit changer de nom si l'envoi de notifications html ne vous intéresse pas

dans l'immédiat, et sauf si tu as envie de faire a fusion tout de
suite, je suis plutôt pour le changement de nom

-- Fil

3

Pierre BASSON wrote:

Un méa-culpa d'abord car d'avoir géré nos plugins artégo hors spip-zone

Héhé.

- soit fusionner les 2, si la personnalisation des mails via des squelettes vous intéresse + envoi html via smtp...
- soit changer de nom si l'envoi de notifications html ne vous intéresse pas

Je pense qu'il suffit de renommer ton plugin : spip-meleuse, spip-facteur ou autre. C'est un vrai besoin qu'on a découvert pour plusieurs plugins.

Pour moi c'est bien ca que fait ton plug, gerer une pile de mail a envoyer, cette pile peut etre remplie par différents plugins.

Les notifications c autre chose, ca peut prendre la forme d'un affichage dans l'espace privé, c'est aps forcement un mail.

Bon retour en tous les cas.

BoOz

4

Dans le core de spip la fonction envoyer_mail() pourrait être du genre :
function inc_envoyer_mail_dist($email, $modele, $from = "", $headers = "")
$modele étant le nom de la notification à envoyer

Il ne faut pas casser la compatibilité avec l'existant ...

Comment enrichir l'api d'envoyer_mail sans casser un peu ? ^^
Sans vouloir vous faire hurler, je pensais à une modification des fonctions du core de spip.

Un exemple :

$envoyer_mail = charger_fonction('envoyer_mail','inc');
$envoyer_mail($GLOBALS['meta']['email_webmaster'], "erreur forum ($type)", "erreur sur le forum ($type) :\n\n");

Deviendrait :

$envoyer_mail = charger_fonction('envoyer_mail','inc');
$envoyer_mail($GLOBALS['meta']['email_webmaster'], "erreur_forum", $args=array('type'=>$type));

On aurait un fichier/tableau du core centralisant tous les corps des mails à envoyer :
$tableau_des_mails['erreur_forum'] = "erreur sur le forum (".$args['type'].") :\n\n";

Ca ne me semble pas une manoeuvre si périlleuse si ?

Quel interet de passer par un squelette pour l'objet du mail ?

C'est vrai que ça reste anecdotique mais du retour d'expérience de spip-boutique par exemple, où on a beaucoup de mail à personnaliser, ça permet de créer des noisettes contenant le nom du client, favorisant la réception du mail niveau spam. Ca permet de donner la main au développeur sur tout ce qui concerne les notifications. Il y a toujours quelqu'un pour qui les intitulés ne sont pas satisfaisants, pas seulement le texte...

recuperer_fond('notifications/inscription_site_spip_html'); // pour la version html
recuperer_fond('notifications/inscription_site_spip_texte'); // pour la version texte
oui il est bien de pouvoir faire cela, mais il faut aussi pouvoir envoyer un simple email texte, ou un email html sans squelette pour le format texte qui sera généra automatiquement à partir du html dans ce cas.

Exemple avec spip-notifications :
$titre = recuperer_fond('notifications/notification_test_titre', array());
$message_html = recuperer_fond('notifications/notification_test_html', array());
$message_texte = recuperer_fond('notifications/notification_test_texte', array());
$test = new Notification($destinataire, $titre, $message_html, $message_texte);
Si la version html est vide le message est envoyé en version texte seulement. C'est beaucoup plus pratique de formater un mail via un squelette qu'en php.

puis envoyer via smtp ou pas, en appliquant des filtres ou pas
des filtres sur quoi ?

Pour embarquer les images référencées dans les notifications, transformer les styles placés dans head en styles en ligne, ou convertir de utf-8 vers iso-8859. En gros des filtres qui permettent d'assurer la bonne livraison des notifications.

Pierre

5

Bon matin !

Suite aux échanges à propos de spip-notifications et autres plugins d'envoi smtp, je voudrais vous proposer spip-facteur qui s'occuperait de la livraison des notifications ^^

J'aimerais repartir de spip-notifications pour ce plugin :
- il contient déjà phpMailer en dernière version
- ça fait 2 ans qu'on l'utilise en prod
- il y a une interface d'admin pour sa configuration et quelques filtres utiles déjà prêts

En lui appportant les changements suivants :
- son nom => spip-facteur
- la manière dont on l'appelle : via un envoyer_mail surchargé à la manière de ce que kent1 a fait

J'en ai besoin pour publier spip-lettres, donc je suis partant pour coder ça aujourd'hui et faire la doc dans la foulée (sur plugins.spip ou spip-contrib ? sachant que je la dupliquerais sur artego.fr aussi).

A +

Pierre

6

Sur spip-contrib, l'article principal avec la doc et les forums. Sur plugins.spip.net tu peux copier le index.xml du plugin, ca sert de plaquette.

Et sur le site de ta boite, ben tu fais ce que tu veux, tant que ca ne s'assimile pas à du détournement commercial vulgaire depuis nos plateforme SPIP.

BoOz

7

Le 13.03.2009 12:32, Fil a écrit :

L'envoi SMTP par contre devrait faire l'objet d'un plugin séparé !

J'y pense, j'y pense.
Un peu à la manière du plugin Google Map API qui, il me semble, ne permet QUE de configurer les infos nécessaires à l'utilisation de Google, je pense faire un plugin qui se limite à fournir une config pour le SMTP (serveur, port, etc) et la librairie PHPMailer qui va bien avec.

C'est déjà partiellement fait dans deux ou trois plugins (encore Booz et Cédric qui trichent l'un sur l'autre), mais il faut mettre ça au propre et pour SPIP 2.

À partir de là, les autres plugins pourront utiliser ces informations et librairies pour en faire ce qu'ils veulent.

Ça ne devrait pas trop tarder car je vais en avoir besoin pour le plugin de Contact afin d'envoyer beaucoup plus facilement des pièces jointes.

--
RastaPopoulos
P.S. : j'enlève l'envoi croisé, ça n'a rien à faire sur spip-dev.

8

Le 13 mars 2009 12:46, RastaPopoulos <vincent@ldd.fr> a écrit :

Le 13.03.2009 12:32, Fil a écrit :

L’envoi SMTP par contre devrait faire l’objet d’un plugin séparé !

J’y pense, j’y pense.
Un peu à la manière du plugin Google Map API qui, il me semble, ne permet QUE de configurer les infos nécessaires à l’utilisation de Google, je pense faire un plugin qui se limite à fournir une config pour le SMTP (serveur, port, etc) et la librairie PHPMailer qui va bien avec.

C’est déjà partiellement fait dans deux ou trois plugins (encore Booz et Cédric qui trichent l’un sur l’autre),

Pas du tout, regarde
http://zone.spip.org/trac/spip-zone/browser/plugins/test/mail_smtp

Et c’est marqué Booz&Cedric dedans !

Mais ce qui n’est pas logique c’est que les divers plugins continuent à integrer du smtp dans leur code au lieu de s’en remettre à la fonction envoyer_mail…

Cédric

9

Les fonctions smtp sont intégrées dans phpmailer (qui s’est reveillé il y a qq mois en passant), je ne suis pas contre les séparer de phpmailer mais je ne vois pas ce qu’il y a de gênant si c’est une option configurable (cf. admin spip-notifications). Qu’est-ce qui vous gêne ?

Le 13 mars 09 à 13:08, Cédric Morin a écrit :

Le 13 mars 2009 12:46, RastaPopoulos <vincent@ldd.fr> a écrit :

Le 13.03.2009 12:32, Fil a écrit :

L’envoi SMTP par contre devrait faire l’objet d’un plugin séparé !

J’y pense, j’y pense.
Un peu à la manière du plugin Google Map API qui, il me semble, ne permet QUE de configurer les infos nécessaires à l’utilisation de Google, je pense faire un plugin qui se limite à fournir une config pour le SMTP (serveur, port, etc) et la librairie PHPMailer qui va bien avec.

C’est déjà partiellement fait dans deux ou trois plugins (encore Booz et Cédric qui trichent l’un sur l’autre),

Pas du tout, regarde
http://zone.spip.org/trac/spip-zone/browser/plugins/test/mail_smtp

Et c’est marqué Booz&Cedric dedans !

Mais ce qui n’est pas logique c’est que les divers plugins continuent à integrer du smtp dans leur code au lieu de s’en remettre à la fonction envoyer_mail…

Cédric

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

10

Le 13.03.2009 13:21, Pierre BASSON a écrit :

Les fonctions smtp sont intégrées dans phpmailer (qui s'est reveillé il
y a qq mois en passant), je ne suis pas contre les séparer de phpmailer
mais je ne vois pas ce qu'il y a de gênant si c'est une option
configurable (cf. admin spip-notifications). Qu'est-ce qui vous gêne ?

Euh, il n'a jamais été question de ça.
On parle de mettre en commun ce qui concerne les fonctions avancés de courrier. Donc obligatoirement dans un plugin *séparé* que les autres plugins pourront utiliser à loisir.

- Une config (CFG ou pas) des paramètres SMTP
- Une incorporation des librairies PHPMailer : smtp ET le reste
- Cédric y a rajouté une surcharge de envoyer_mail() pour que ça marche avec l'existant aussi

Ce qui est gênant c'est que tous les plugins qui touchent aux mails continuent d'intégrer eux-même PHPMailer (donc doublonnage énorme et risque de conflit au passage) ainsi que la config SMTP.

--
RastaPopoulos

11

Le 13.03.2009 13:08, Cédric Morin a écrit :

Pas du tout, regarde
Connexion · GitLab

Et c'est marqué Booz&Cedric dedans !

Hihi oui, mais avant il y avait eu le plugin nommé "phpmailer".

Mais ce qui n'est pas logique c'est que les divers plugins continuent à
integrer du smtp dans leur code au lieu de s'en remettre à la fonction
envoyer_mail...

Oui et nom, car le nom du plugin et ce dont tu parles là sont réducteurs.
En effet PHPMailer ne sert pas QUE à faciliter la mise en place de l'envoi SMTP. En l'occurence, j'en ai besoin pour envoyer facilement des pièces jointes, entre autre ; chose qui n'a rien à voir avec le SMTP mais avec comment est formaté le mail non ?

Donc ta surcharge de envoyer_mail() ne suffit pas, ou alors il faut lui rajouter des options supplémentaires à la fin des arguments. Ça permettrait la compatibilité avec l'existant, mais en élargissant les possibilités...

Go go go.

--
RastaPopoulos

12

Le 13 mars 2009 13:21, Pierre BASSON <pierre.basson@artego.fr> a écrit :

Les fonctions smtp sont intégrées dans phpmailer (qui s’est reveillé il y a qq mois en passant), je ne suis pas contre les séparer de phpmailer mais je ne vois pas ce qu’il y a de gênant si c’est une option configurable (cf. admin spip-notifications). Qu’est-ce qui vous gêne ?

Coder, Dupliquer et maintenir X fois la même fonction est une perte de temps et d’energie pour tout le monde.
Le plugin mail_smtp implémente l’envoi des mails par smtp et la configuration qui va avec.
A partir de là, aucun autre plugin ne devrait intégrer phpmailer ou autre librairie smtp, et tous devraient utiliser simplement envoyer_mail qui passera par mail() ou par smtp selon la configuration.

Si l’api d’envoyer_mail n’est pas suffisante, il faut l’enrichir, cela profitere à toutes et tous.

Cédric

13

Coder, Dupliquer et maintenir X fois la même fonction est une perte de temps et d'energie pour tout le monde.
Le plugin mail_smtp implémente l'envoi des mails par smtp et la configuration qui va avec.
A partir de là, aucun autre plugin ne devrait intégrer phpmailer ou autre librairie smtp, et tous devraient utiliser simplement envoyer_mail qui passera par mail() ou par smtp selon la configuration.
Si l'api d'envoyer_mail n'est pas suffisante, il faut l'enrichir, cela profitere à toutes et tous.

Bien d'accord, spip-notifications disparaîtra en fusionnant avec mail_smtp ; ou à partir de tous les plugins du style existants on créera un plugin unique. Avez-vous regardé comment spip-notifications gère les notifications pour les envois au format mixte ? Il y a de la doc par là : http://www.artego.fr/-Envoi-de-notifications-

De mon côté j'ai regardé envoyer_mail() mais elle ne permet pas d'envoyer des mails au format mixte. J'avais mis en place quelques filtres pour faciliter l'envoi de mails html dans spip-notif'.

Dans le core de spip la fonction envoyer_mail() pourrait être du genre :
function inc_envoyer_mail_dist($email, $modele, $from = "", $headers = "")
$modele étant le nom de la notification à envoyer

Le plugin de notif pourrait ainsi surcharger cette fonction et formater la notification en faisant un
recuperer_fond('notifications/inscription_site_spip_titre'); // pour le titre
recuperer_fond('notifications/inscription_site_spip_html'); // pour la version html
recuperer_fond('notifications/inscription_site_spip_texte'); // pour la version texte
puis envoyer via smtp ou pas, en appliquant des filtres ou pas
spip-notifications fonctionne déjà comme ça sauf que le plugin ne surcharge pas une fonction du core de spip

A vous

Pierre

14

Le 13.03.2009 14:52, Pierre BASSON a écrit :

De mon côté j'ai regardé envoyer_mail() mais elle ne permet pas
d'envoyer des mails au format mixte. J'avais mis en place quelques
filtres pour faciliter l'envoi de mails html dans spip-notif'.

Dans le core de spip la fonction envoyer_mail() pourrait être du genre :
function inc_envoyer_mail_dist($email, $modele, $from = "", $headers = "")
$modele étant le nom de la notification à envoyer

Dans l'absolu peut-être, mais concrètement non.
Actuellement la fonction envoyer_mail() est utilisée en moult endroits du noyau de SPIP, et ensuite par plusieurs plugins de la zone.

Donc si on la surcharge pour l'aggrémenter de diverses fonctionnalités super cool, cela ne pourra se faire qu'en garder les MÊMES premiers paramètres et en ne faisant qu'ajouter des options supplémentaires à la fin de la fonction.
Le comportement classique doit rester le même (mise à part le choix ou pas du SMTP suivant la config).

On devrait donc faire :
function inc_envoyer_mail_dist($email, $sujet, $texte, $from = "", $headers = "", $autre_option, $encore_une, $etc){ ...

Cela ferait en sorte que seuls les plugins ayant des besoins plus complexes autour des courriels (et il y en a quand même assez peu) changent/adaptent leur code. Les autres (y compris le noyau) ça changera rien pour eux.

--
RastaPopoulos

15

Le 13 mars 2009 14:52, Pierre BASSON <pierre.basson@artego.fr> a écrit :

Coder, Dupliquer et maintenir X fois la même fonction est une perte de temps et d’energie pour tout le monde.
Le plugin mail_smtp implémente l’envoi des mails par smtp et la configuration qui va avec.
A partir de là, aucun autre plugin ne devrait intégrer phpmailer ou autre librairie smtp, et tous devraient utiliser simplement envoyer_mail qui passera par mail() ou par smtp selon la configuration.
Si l’api d’envoyer_mail n’est pas suffisante, il faut l’enrichir, cela profitere à toutes et tous.

Bien d’accord, spip-notifications disparaîtra en fusionnant avec mail_smtp ; ou à partir de tous les plugins du style existants on créera un plugin unique. Avez-vous regardé comment spip-notifications gère les notifications pour les envois au format mixte ? Il y a de la doc par là : http://www.artego.fr/-Envoi-de-notifications-

De mon côté j’ai regardé envoyer_mail() mais elle ne permet pas d’envoyer des mails au format mixte. J’avais mis en place quelques filtres pour faciliter l’envoi de mails html dans spip-notif’.

Dans le core de spip la fonction envoyer_mail() pourrait être du genre :
function inc_envoyer_mail_dist($email, $modele, $from = «  », $headers = «  »)
$modele étant le nom de la notification à envoyer

Il ne faut pas casser la compatibilité avec l’existant …

Le plugin de notif pourrait ainsi surcharger cette fonction et formater la notification en faisant un
recuperer_fond(‹ notifications/inscription_site_spip_titre ›); // pour le titre

Quel interet de passer par un squelette pour l’objet du mail ?

recuperer_fond(‹ notifications/inscription_site_spip_html ›); // pour la version html
recuperer_fond(‹ notifications/inscription_site_spip_texte ›); // pour la version texte

oui il est bien de pouvoir faire cela, mais il faut aussi pouvoir envoyer un simple email texte, ou un email html sans squelette pour le format texte qui sera généra automatiquement à partir du html dans ce cas.

puis envoyer via smtp ou pas, en appliquant des filtres ou pas

des filtres sur quoi ?

spip-notifications fonctionne déjà comme ça sauf que le plugin ne surcharge pas une fonction du core de spip

A vous

Pierre

16

Pierre BASSON a écrit :

[...]

transformer les styles placés dans head en styles en ligne, ou convertir
de utf-8 vers iso-8859. En gros des filtres qui permettent d'assurer la
bonne livraison des notifications.
[...]

Bonjour

J'espère que l'on pourra surtout convertir vers utf8 (et
éventuellement utf16).

Les iso-machin sont des horreurs, surtout avec les mauvais logiciels
de courrier.

Je pense que vous y avez pensé, et heu.... j'aime bien l'évolution
de Spip, je vous fait confiance :slight_smile:

A bientôt
Grégoire

17

Le 16.03.2009 09:18, Pierre BASSON a écrit :

En lui appportant les changements suivants :
- son nom => spip-facteur
- la manière dont on l'appelle : via un envoyer_mail surchargé à la
manière de ce que kent1 a fait

Bon ok il faut effectivement qu'on se décide *tous ensemble* sur quel dossier on travaille et qu'on ne garde plus que celui-là plutôt que de se disperser.

J'en ai besoin pour publier spip-lettres, donc je suis partant pour
coder ça aujourd'hui et faire la doc dans la foulée (sur plugins.spip ou
spip-contrib ? sachant que je la dupliquerais sur artego.fr aussi).

Moi aussi j'en ai besoin rapidement, donc il faut que je m'y mette aussi. Mais j'ai pas envie de travailler dans mon coin.

Je n'ai pas encore eu le temps de regarder notifications, mais comme tu le connais sur le bout des doigts, tu es à mon avis mieux placer pour faire la première étape de la transition, cad changer l'API pour utiliser une surcharge de envoyer_mail().

Ne fais pas comme Quentin, il a utilisé une manière déprécié en SPIP 2 (le define). Utilise plutôt comme dans mail_smtp, cad une surcharge complète de inc/envoyer_mail.php.

Faut bien laisser la même API pour les premiers arguments afin que tout ce qui existe actuellement n'ai pas à changer

En ce qui me concerne, mon but est de rajouter un argument $documents, qui serait un array() de chemins vers des fichiers à rajouter en pièces jointes.

Pour la configuration de PHPMailer, je ne sais pas comment tu as fait, mais je pense que CFG sera le plus simple pour que ce soit facilement compréhensible et modifiable par tout le monde.

Facteur c'est super comme nom !

--
RastaPopoulos

18

En ce qui me concerne, mon but est de rajouter un argument $documents, qui serait un array() de chemins vers des fichiers à rajouter en pièces jointes.

Je pense rajouter seulement un paramètre à la fonction envoyer_mail($email, $sujet, $texte, $from = "", $headers = "", $args=array()) : $args à la manière des pipelines
Pour info les images intégrées dans le corps html de spip-notifications peuvent être embarquées à la notification, je ne sais pas si ça t'intéresse.

Pour la configuration de PHPMailer, je ne sais pas comment tu as fait, mais je pense que CFG sera le plus simple pour que ce soit facilement compréhensible et modifiable par tout le monde.

La page de configuration existe déjà, c'est un formulaire tout ce qu'il y a de plus simple + une fonction qui permet de tester les envois et qui affiche les éventuels messages d'erreur.

Facteur c'est super comme nom !

Idée de BoOz

A-t'on un consensus ?

Pierre

19

Le 16.03.2009 10:29, Pierre BASSON a écrit :

Je pense rajouter seulement un paramètre à la fonction
envoyer_mail($email, $sujet, $texte, $from = "", $headers = "",
$args=array()) : $args à la manière des pipelines
Pour info les images intégrées dans le corps html de spip-notifications
peuvent être embarquées à la notification, je ne sais pas si ça
t'intéresse.

Très bien, ça permet de prévoir pas mal de fonctionnalités différentes sans que ce soit à rallonge.
Moi c'est pas spécialement pour envoyer des images, ça peut être des CV en n'importe quel format, ou des sons, ou n'importe quoi. C'est pour plusieurs projets différents (dont le site de notre boite pour les CV).

La page de configuration existe déjà, c'est un formulaire tout ce qu'il
y a de plus simple + une fonction qui permet de tester les envois et qui
affiche les éventuels messages d'erreur.

L'avantage de CFG c'est le système simple et compréhensible pour ajouter/récupérer les données de config et sur plusieurs niveaux
Par ex :
lire_config('facteur/smtp/hote')
[(#CONFIG{facteur/methode}|=={smtp}|oui) truc]

Facteur c'est super comme nom !

Idée de BoOz

Il est trop fort ce Booz.

A-t'on un consensus ?

Ça commence.

--
RastaPopoulos