Salut à tous.
Ayant eu le problème de l'envoi de liste de diffusions basées sur le
contenu de spip, j'étais en train de préparer un mail à spip-dev contenant
quelques idées là-dessus.
Au vu des discussions actuelles, je vous envoie le mail en question en
l'état, si cela peut faire avancer le schmilblick.
Deux remarques rapides ; je suis en gros d'accod sur la méthode générale.
Il va l'inscrire dans une nouvelle table, genre spip_internautes
Il faut utiliser la table spip_auteurs, avec un statut de plus
éventuellement (on a déjà 6forum pour le forum public).
Ou encore en utilisant un squelette qui ne produit pas du HTML mais
du texte (je ne suis pas *particulièrement* fan des mails html, qui
permettent en outre de tracer la lecture).
Ouaips.
- un envoi automatique quotidien / hebdomadaire / mensuel
et
- un envoi manuel "quand ça me chante" pour les sites à périodicité
aléatoire, soit de la composition déjà faite, soit d'un texte libre "je
veux envoyer un flash parce-qu'il y a de l'info coco et l'info ça
n'attends pas".Ceci doit être précédé de l'envoi d'un mail de test à une adresse à
saisir, c'est con mais très utile.
En fait, tu peux envoyer le mail auto à l'adresse de test, avec un lien
permettant d'aller "valider" ce mail : la validation te présente un
formulaire qui te permet d'éditer le mail avant l'envoi (c'est ce qu'on fait
sur la lettre hebdo du Portail des copains).
pour cela que je propose de noter la liste des mails à envoyer dans une
table faite pour ça, genre spip_envoi
- id_envoi bigint(21) auto_increment
- id_liste_diffusion bigint(21) clé étrangère
- id_internaute bigint(21) clé étrangère
- statut varchar(20) a_envoyer / envoye / erreur... et de mettre à jour cette table lorsque l'envoi a été fait. Comme
ça on peut reprendre l'envoi s'il y a eu un problème, et on ne risque
pas (enfin on risque beaucoup moins) d'arroser un innocent de dizaines
de mails.
Je dirais même plus : on supprime l'enregistrement correspondant à un
destinataire AVANT d'essayer d'envoyer. Donc, si jamais ça génère un
plantage, deux cas :
1) ça n'a pas envoyé le mail, tant pis !
2) ça l'a envoyé, tant mieux !
mais on évite le scénario : on réessaie. (incontrôlable).
Ensuite l'envoi proprement dit :
- on boucle sur la table
- un mail php
Oui, et on s'arrête à un nombre maxi sans attendre nécessairement le timeout.
- si c'est bon on met à jour à "envoye"
- sinon on passe en erreur
Non : on considère par principe que c'est bon (cf ci-dessus).
... visuellement accompagné d'une petite progress-bar... ?
Boarf. De toutes façons rien n'oblige à ce que l'envoi soit synchrone avec
la décision d'envoyer. Tu en envoies cinquante, et à la pochaine connexion
tu en envoies encore 50, etc... jusqu'à épuisement de la file.
Puis un petit rapport, "ça s'est bien passé" sauf pour les emails
Non, pas de rapport.
3 - Gestion de la liste des abonnés
Relativement simple création / modification / suppression, avec un
champ de recherche (fait avec un '%like%' mais c'est du back).
Non, on ne va pas recréer un environnement classique de gestion de liste.
D'ailleurs, je trouve que ces interfaces (et j'en ai essayé plein crois-
moi!) sont toutes relativement merdiques.
4 - Publication des archives
On voit ça rarement sur les sites éditoriaux, c'est dommage à mon
sens.Une BOUCLE(LISTES_DIFFUSION){id_liste}{par date/num}
#ID_LISTE
#DATE_CREATION
#DATE_ENVOI
#TEXTE
Mouais... ça pourrait aussi bien être géré dans un spip_articles.
Question : noter qu'un article a déjà été envoyé ? (table en plus ?
ou alors dans spip_articles mais bof si un jour on veut gérer plusieurs
listes) (serait pratique pour l'envoi auto et/ou le squelette texte de
mail, et pour gérer une interface plus complexe plus tard)
Tu confonds "ce qu'on veut afficher" et "comment envoyer des choses".
Mais, pour aller dans cette direction, le suivi des "articles déjà envoyés"
peut reposer sur un spip_meta (du genre "date_dernier_envoi_nouveautes") ;
tout en sachant que pour les articles pré- ou post-datéss ça ne marchera
pas.
-- Fil
Hello,
Il va l'inscrire dans une nouvelle table, genre spip_internautes
Il faut utiliser la table spip_auteurs
+1, sauf que à force il faudrait renommer cette table spip_users pour
être plus générique ...
avec un statut de plus éventuellement (on a déjà 6forum pour le
forum public).
Là, rien à voir avec un statut à priori, mais il me semble de toute
façon qu'à force de rajouter des possibilités de gestion des droits,
il va falloir remettre à plat ces statuts ...
Ou encore en utilisant un squelette qui ne produit pas du HTML mais
du texte
Le mieux est de proposer les deux, à l'utilisateur de préciser ce
qu'il veut recevoir ...
En fait, tu peux envoyer le mail auto à l'adresse de test, avec un
lien permettant d'aller "valider" ce mail : la validation te
présente un formulaire qui te permet d'éditer le mail avant l'envoi
+1
Je dirais même plus : on supprime l'enregistrement correspondant à
un destinataire AVANT d'essayer d'envoyer. Donc, si jamais ça génère
un plantage, deux cas :
1) ça n'a pas envoyé le mail, tant pis !
2) ça l'a envoyé, tant mieux !
mais on évite le scénario : on réessaie. (incontrôlable).
Bonne idée !
Ensuite l'envoi proprement dit :
- on boucle sur la table
- un mail phpOui, et on s'arrête à un nombre maxi sans attendre nécessairement le
timeout.
Prévoir la possibilité de faire faire l'envoi par un script
indépendant qui serait lancé via un (web)cron ...
... visuellement accompagné d'une petite progress-bar... ?
Inutile, le mieux c'est en tâche de fond.
4 - Publication des archives
Et si une newsletter est constituée à partir de mots clefs affectés
aux articles choisis (un mot clef par envoi), c'est plus simple, on
peut indiquer dans l'article dans quelle(s) newsletter il a été
envoyé, et on peut retrouver les archives via les mots clefs ...
-Nicolas
Nicolas Hoizey wrote:
> Prévoir la possibilité de faire faire l'envoi
> par un script indépendant qui
> serait lancé via un (web)cron ...
+2 
ou pouvoir choisir : (web)cron ou SPIP en fonction de la
fréquentation du site (Public ou Privé).
a+
^Fabrice^^
Re,
Pour moi une liste de diffusion est un lieu de débat.. par mail
Ce que tu évoques est plutôt une newsletter sur les nouveautés du site.
Mais je peux me tromper.
Actuellement on peut très bien le faire via la fonctionnalité
"Annonce des nouveautés
SPIP peut envoyer, régulièrement, l'annonce des dernières nouveautés du site."
D'ailleurs de ce point de vue, il me semblerait intéressant que cette fonctionnalité existante permettent aussi au lecteur de recevoir immédiatement une info sur les articles ou brèves ayant fait l'objet de commentaires dans les forums attachés. Peut-être pour une future version.
Mais j'ai peut-être pas tout compris
A +
J.Chatignoux
Deux remarques rapides ; je suis en gros d'accod sur la méthode générale.
> Il va l'inscrire dans une nouvelle table, genre spip_internautes
Il faut utiliser la table spip_auteurs, avec un statut de plus
éventuellement (on a déjà 6forum pour le forum public).
Attention aux newsletter qui utilise la fonction mail, car chez certains hébergement, cette fonction la n'est pas performante et au dela d'un nombre important de users, les mails ne sont plus envoyés.
Il faudrait peut etre prévoir une inscription à une liste de diffusion.
J'utilise pour l'inscription des internautes qui nous pas d'accès à l'espace privé le modules newsletter de nuke qui contient pas mal d'info sur l'internaute (nom, prenom, pseudo, pass, email et un tas d'autres plus ou mois utiles, choix du nombres d'articles présent sur la page d'accueil, le theme du site(si on propose plusieurs themes), le AIM,ICq...) qui a mon avis sont plus de gadjet qu'autres choses.
Je gere ce module depuis spip.
Pour envoyer la newletter , il faut la possibilté d'envoyer sois un texte automatique, (contenant les dernieres nouveauté) soit offrir la possibilité de taper sont propre texte (pour une annonce quelconque).
Enfin ce ne sont que quelques idées.
Phil
> Prévoir la possibilité de faire faire l'envoi par un script indépendant
> qui serait lancé via un (web)cron ...
Il faudra m'expliquer l'intérêt. Si tu as un site fréquenté par absolument
personne, il ne risque pas d'avoir des centaines de milliers d'abonnés à ses
listes ; et vice-versa. De toutes façons, n'importe quel cron qui vient
taper sur la page d'accueil déclencherait l'envoi de mail, pas besoin de
faire un truc spécifique... Non ?
-- Fil
Il faudra m'expliquer l'intérêt. Si tu as un site fréquenté par
absolument personne, il ne risque pas d'avoir des centaines de
milliers d'abonnés à ses listes ; et vice-versa.
Certes, mais il peut justement être intéressant de programmer les
envois des mails à une heure où personne ne passe, pour que cela
n'impacte pas les perfs.
De toutes façons, n'importe quel cron qui vient taper sur la page
d'accueil déclencherait l'envoi de mail, pas besoin de faire un truc
spécifique... Non ?
Sauf si on veut découpler les deux, justement ...
-Nicolas