Par info-lettre, on désigne ici le contenu éditorial qui va être composé et envoyé par courriel à une liste d’adresses abonnées.
Le plugin permet de composer une info-lettre à partir d’un modèle pré-composé, d’un texte que vous pourrez rédiger spécifiquement, et d’une sélection d’articles et/ou de rubriques.
Si vous utilisez un outil externe pour composer vos info-lettres, vous pouvez aussi directement coller le contenu au format HTML (et au format texte pour l’alternative).
Enfin, ce plugin implémente la partie compose de l’API Newsletter.
Installation
Le plugin s’installe classiquement. Il nécessite le plugin Mailsubscribers pour la gestion des inscriptions et le plugin Mailshot pour l’envoi.
Configuration
La seule configuration du plugin concerne la possibilité de masquer certains modèles d’info-lettres. Vous n’en aurez pas besoin au départ, mais le plugin fournit certains modèles par défaut, et une fois que vous aurez choisi et/ou personnalisé celui qui vous convient le mieux, vous pourrez vouloir masquer les autres modèles pour ne pas risquer de vous tromper ou perturber vos rédacteurs.
Documents joints
Vous pouvez permettre de joindre des images ou autres documents aux infolettres, pour les utiliser dans le contenu éditorial spécifique.
Pour cela, allez dans le menu Configuration > Contenu du site, et dans le formulaire Documents joints en bas de page, cochez la case Infolettres en face de Activer le téléversement pour les contenus.
Composition d’une Info-lettre
Administration des info-lettres
Toutes les info-lettres existantes sont consultables depuis le menu Edition > Infolettres.
Composition d’une nouvelle info-lettres
En cliquant sur Créer une infolettre vous arrivez sur le formulaire de composition ci-dessous :
Il vous permet de choisir le modèle pré-composé, de fournir un chapeau et un texte et de faire une sélection d’articles et rubriques qui seront mis en avant dans l’info-lettre.
En bas du formulaire vous disposez d’une case à cocher qui permet de passer en mode édition avancée :
Dans ce mode là, vous composez directement le HTML et le texte qui seront envoyés par courriel. C’est un mode dans lequel vous maîtrisez tout, et qui peut vous servir si vous utilisez un autre outil pour composer le HTML de votre info-lettre.
Ce mode d’édition avancée est aussi le seul qui sera disponible une fois que votre info-lettre sera publiée. Il permet de corriger une éventuelle coquille dans le HTML ou le texte.
Mais revenons au mode d’édition simple en remplissant les différents champs et en faisant une sélection d’articles :
Après enregistrement, vous arrivez sur la page de présentation de l’info-lettre. Vous pouvez alors y associer un logo qui sera éventuellement utilisé dans le modèle pré-composé que vous avez choisi (ici le modèle basic).
Tant que votre info-lettre n’est pas publiée (ou que vous n’êtes pas en mode édition avancée), cette page ne présente que le contenu éditorial.
Pré-visualisation d’une info-lettre
Il faut passer en pré-visualisation pour voir la mise en forme réalisée par le modèle pré-composé qui va utiliser votre contenu éditorial. Cela se fait en cliquant sur le lien Prévisualiser dans le cartouche de gauche. Vous passez alors sur une page spécifique du site public, qui présente votre info-lettre dans sa version HTML [1] :
Cette prévisualisation vous permet par exemple de vérifier son affichage sur un écran de largeur réduite [2] :
Ou de voir aussi la version Texte du mail qui sera envoyé :
Le lien Version HTML email vous montre la version qui sera envoyée dans l’email, alors que le lien Version HTML en ligne vous montre la version qui sera affichée dans le navigateur pour les utilisateurs qui cliquent sur le lien « Voir cette Infolettre dans votre navigateur » présent en début d’email. Les deux versions sont par défaut très proches et ne se distinguent que par des petits détails masqués dans la version navigateur. Mais vous pouvez complètement les distinguer comme il sera vu par la suite.
Si vous avez des modifications à faire suite à cette prévisualisation, vous pouvez retourner modifier l’info-lettre via le formulaire d’édition. A chaque fois que vous faites une modification et enregistrez ou que vous prévisualisez, votre info-lettre est recomposée automatiquement à partir du modèle pré-composé et de vos contenus.
Test d’envoi d’une info-lettres
Une fois composée votre info-lettre, il est souvent nécessaire de l’envoyer par mail pour tester qu’elle s’affiche bien dans un lecteur de mail.
Vous disposez pour cela d’un formulaire sur la page de l’info-lettre :
Tant que vous n’avez pas publié votre info-lettre, vous ne pouvez l’envoyer qu’à une adresse email à la fois. De plus, par précaution, le sujet sera préfixé par l’avertissement [TEST]. Ceci vous évite la moindre confusion.
Publication d’une info-lettre
Après ce test d’envoi, vous pouvez alors publier votre info-lettre :
Votre info-lettre est alors recomposée une dernière fois par sécurité, les images sont copiées dans un dossier IMG/nl/xx/ pour ne pas risquer d’être perdues après l’envoi de l’info-lettre, et elle est passée en mode édition avancée sans possibilité de revenir en arrière.
Vous voyez alors que la page est modifiée dans ce contexte. Vous voyez directement les différentes versions HTML et Texte [3].
Dans ce mode, si vous essayez de modifier votre info-lettre, vous ne pourrez plus accéder qu’aux versions définitives composées, et non plus au contenu éditorial :
Envoi de l’info-lettre
Une fois publiée, vous pouvez envoyer cette info-lettre à l’aide du formulaire d’envoi présent sur la page :
La suite du processus d’envoi est décrite dans la documentation du plugin Mailshot.
Programmation d’une info-lettre
Un usage possible du plugin est de programmer une info-lettre qui sera générée et envoyée automatiquement selon une fréquence programmée.
Pour que cela ait un sens, le contenu de l’info-lettre doit se générer automatiquement à chaque nouvel envoi. Cela ne peut se faire qu’avec un modèle dédié conçu pour cela. Voyons un exemple avec le modèle Nouveautés fourni avec le plugin.
Cliquez sur l’icône Programmer une infolettre depuis la page d’administration des info-lettres. Vous arrivez alors sur un formulaire complet de programmation :
Ce formulaire vous permet de définir le titre, la récurrence de l’envoi, le modèle à utiliser pour composer automatiquement l’info-lettre. Vous pouvez aussi renseigner un chapeau et un texte et faire une sélection d’articles et rubriques, mais cela a souvent moins de sens car il vaut mieux que tout le contenu soit calculé automatiquement par votre modèle.
Pour la récurrence d’envoi, vous fixez une date et heure de début à partir de laquelle l’envoi sera programmé. Puis vous fixez la fréquence de répétition :
- tous les jours
- toutes les semaines, avec la possibilité de choisir quel(s) jour(s)
- tous les mois
- toutes les années
Dans tous les cas vous pouvez fixer un intervalle (tous les 2 jours, 3 semaines...). Vous pouvez également fixer une fin à l’envoi automatique : après un nombre d’occurrences [4], ou à une date précise.
Pour l’envoi, vous avez deux choix non exclusifs :
- l’envoi en test à une adresse mail
- l’envoi direct sur une liste d’inscrits
Choisissez par exemple juste le premier pour recevoir une version de relecture dans votre boîte mail, et vous n’aurez plus qu’à lancer manuellement l’envoi en nombre si cela vous convient.
Une fois tout bien rempli cela donne par exemple, pour un envoi quotidien automatique des nouveautés, à 10h, aux inscrits à la liste newsletter :
Enregistrez pour voir votre info-lettre programmée dans la liste des info-lettres :
Automatisme d’envoi
A chaque nouvelle occurrence de la date programmée, le plugin va essayer de composer la version HTML de l’info-lettre avec le modèle sélectionné. Si celle-ci est vide, il considère qu’il n’y a rien à envoyer et se reprogramme à la date de la prochaine échéance.
Si le contenu composé n’est pas vide, le plugin crée alors une nouvelle info-lettre avec le titre, chapo, texte et sélection d’article qui ont été programmés. La date de l’info-lettre est positionnée à la date de l’occurence et la date de rédaction antérieure de l’info-lettre est fixée à la date du dernier envoi [5]
L’info-lettre est alors composée avec le modèle, et le plugin envoie une version de test sur l’adresse email programmée si nécessaire, puis publie l’info-lettre. Si un envoi à une liste a été défini, celui-ci est automatiquement déclenché.
A noter que si pour une raison ou une autre le plugin rate une échéance (site en panne ou pas de visites sur le site), il fusionnera toutes les occurrences ratées et fera son envoi à la dernière occurrence passée.
Création d’un gabarit
Comme vu plus ci-avant, les Info-lettres sont en général générées à partir de modèles pré-composés que l’on appelera ici gabarits [6]. Ces gabarits sont en fait des squelettes SPIP, rangés dans le dossier newsletters/. Vous pouvez en ajouter dans votre dossier squelettes/newsletters/, ou personnaliser un modèle fourni dans le dossier newsletters/ du plugin en le copiant dans votre dossier squelettes/newsletters/ avant de le modifier.
Un gabarit est constitué au moins d’un squelette pour la version HTML de l’email. Il peut être accompagné de 2 variantes facultatives pour la version Texte de l’email, ainsi que pour la version HTML de l’info-lettre telle qu’affichée dans le navigateur.
Gabarit HTML
Pour créer un gabarit de la version HTML de votre email, créez simplement un fichier mongabarit.html dans votre dossier squelettes/newsletters/.
Il va alors apparaître automatiquement dans la liste des modèles disponibles quand vous créez une nouvelle Info-lettre :
Le nom du fichier gabarit apparaît entre crochets. Pour lui donner un petit nom en clair, ajoutez en début de votre fichier mongabarit.html [7] :
<BOUCLE_rem(CONDITION){si #REM}>
<!-- titre=Mon gabarit à moi -->
</BOUCLE_rem>Le titre en clair de votre gabarit apparaît alors dans l’interface d’édition des info-lettres :
Mais pour l’instant votre gabarit n’affiche rien. Ajoutons le code minimum suivant :
<BOUCLE_newsletter(NEWSLETTERS){id_newsletter}{statut?}>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>#TITRE</title>
</head>
<body>
<h1>Hello World !</h1>
</body>
</html>
</BOUCLE_newsletter>
#FILTRE{newsletters_liens_absolus}On peut voir qu’on a ici :
- ajouté une boucle
NEWSLETTERS: celle-ci doit avoir les deux critères{id_newsletter}{statut?}pour bien s’afficher sur l’info-lettre en cours de composition, quel que soit son statut ;- si vous avez configuré l’utilisation des langues sur les newsletters, vous devrez compléter cette boucle avec le critère
{lang_select}, et veiller à ce que cette langue soit transmises aux squelettes inclus en passant{lang}aux#INCLURE.
- si vous avez configuré l’utilisation des langues sur les newsletters, vous devrez compléter cette boucle avec le critère
- inséré dans la boucle le code minimum d’une page HTML :
- DOCTYPE
- balises
<html>,<head>,<body> - un
<title>dans le<head> - un
<h1>dans la page
- complété avec un appel à
#FILTRE{newsletters_liens_absolus}: cet appel vous sera bien utile car il transformera les URLs des liens et des images en URLs absolues qui fonctionneront dans tous les cas [8]
Dans cet exemple minimal, on utilise la balise #TITRE pour récupérer le titre de l’info-lettre tel qu’il aura été rempli dans le formulaire d’édition.
Les balises disponibles dans dans la boucle NEWSLETTERS sont :
-
#TITRE: le titre de l’info-lettre -
#CHAPO: le contenu du chapeau de l’info-lettre -
#TEXTE: le contenu du texte de l’info-lettre -
#URL_NEWSLETTER: l’url publique qui permet de voir l’info-lettre en ligne, dans le navigateur -
#LANG: la langue de l’info-lettre -
#DATE: la date de publication de l’info-lettre -
#DATE_REDAC: la date de rédaction antérieure de l’info-lettre (correspond à la date de la dernière occurrence dans le cas d’une info-lettre programmée)
Par ailleurs, la récupération des articles et rubriques sélectionnées dans une info-lettre se fait au moyen des boucles suivantes :
<ul>
<BOUCLE_selectionarticles(ARTICLES){id_newsletter}>
<li><a href="#URL_ARTICLE">#TITRE</a>
</BOUCLE_selectionarticles>
</ul>
<ul>
<BOUCLE_selectionrubriques(RUBRIQUES){id_newsletter}>
<li><a href="#URL_RUBRIQUE">#TITRE</a>
</BOUCLE_selectionrubriques>
</ul>Pour la structure HTML de votre info-lettre, vous pourrez avantageusement vous inspirer des ressources suivantes [9] :
- HTML EMAIL BOILERPLATE qui fournit un code type bien documenté des meilleures pratiques ;
- Le guide du Support de CSS dans les emails ;
- Emailology qui est un guide complet d’intégration des emails HTML
- Responsive Email Templates proposé par Zurb qui fournissent une base standard assez bien testée
Vous pouvez aussi partir des deux gabarits fournis dans le plugin :
-
basic.htmlest inspiré des gabarits HTML fournis par Mailchimp, avec des améliorations pour prendre en charge l’affichage dans les petits écrans ; -
letter.htmlest inspiré des mails HTML envoyés par le service Feedburner ; il repose sur une approche plus simple avec un minimum de stylage pour laisser les styles par défauts des lecteurs de mail.
Si vous faites de beaux gabarits robustes, n’hésitez pas à les ajouter au plugin pour en faire profiter le plus grand nombre.
Pour finir, une petite astuce de travail : pour dégrossir la mise en forme de votre gabarit lors de sa réalisation, vous pouvez directement l’afficher dans votre navigateur (si vous avez bien le statut de webmestre) par l’url spip.php?page=newsletters/mongabarit&id_newsletter=1 en choisissant bien un id_newsletter d’une info-lettre existante. Cela vous permet ainsi de visualiser rapidement toutes vos modifications sans avoir à générer une info-lettre et faire des aller-retour entre le mode prévisualisation et l’espace privé de SPIP.
Gabarit Texte
Les emails HTML sont toujours accompagnés d’une alternative au format texte, qui est affichée dans les lecteurs de mail ne supportant pas le HTML, ou si l’utilisateur à choisi ce réglage dans ses préférences.
Il est donc crucial de bien générer une variante texte du gabarit HTML. Si vous ne fournissez aucun gabarit pour la variante texte, le plugin va automatiquement générer une version texte à partir du HTML. Cette version texte repose sur une conversion au format MarkDown, avec quelques structurations supplémentaires (analyse des structures <table> du mail HTML pour générer des séparations structurelles dans la version texte).
Dans la plupart des cas, la version texte automatique est suffisante. Mais si vous voulez avoir un contrôle fin de ce que vous envoyez, vous pouvez créer un second gabarit pour la version texte : créez un second fichier mongabarit.texte.html dans votre dossier squelettes/newsletters/. Ce gabarit sera alors utilisé pour générer la version texte de votre email.
Mettez y la boucle (NEWSLETTERS) comme dans la version HTML, et composez le contenu de votre email en texte, en utilisant les mêmes boucles et balises que dans la version HTML.
Gabarit HTML pour la version en ligne
Lorsque votre info-lettre est affichée dans le navigateur, c’est par défaut le HTML de l’email envoyé qui est utilisé.
Toutefois, certaines informations ne sont pas pertinentes dans la version en ligne (par exemple le texte qui dit « vous pouvez voir cette infolettre en ligne »).
La feuille de style css/newsletter_inline.css est automatiquement ajoutée dans la page de la version en ligne. Il est ainsi possible de faire de petits ajustements CSS pour masquer certains blocs de texte, ou modifier quelque peu l’apparence de la version affichée dans le navigateur.
Si cela ne vous suffit pas, ou que vous voulez présenter en ligne une version très différente, qui reprend par exemple une partie de la charte graphique du site public, vous pouvez générer une version spécifique de votre info-lettre.
Pour cela créez un second fichier mongabarit.page.html dans votre dossier squelettes/newsletters/. Ce gabarit sera alors utilisé pour générer la version de votre info-lettre affichée dans le navigateur.
Personnalisation des info-lettres
Pour finir abordons l’aspect personnalisation. Dans de l’envoi en nombre il peut être utile et profitable de personnaliser chaque email envoyé en fonction de son destinataire.
Pour cela, le plugin propose un système de variables à deux niveaux, qui sont remplacées au moment de l’envoi, en fonction du destinataire.
Variables simplifiées
Les variables simplifiées s’expriment sous la forme @nomdelavariable@.
Chaque variable qui apparait ainsi dans l’infolettre composée est remplacée par son contenu. Si la variable n’est pas connue ou pas fournie, elle est simplement retirée (remplacée par un contenu vide).
Ces variables peuvent être utilisées dans le gabarit de l’info-lettre, mais aussi dans les champs titre, chapeau et texte de l’info-lettre.
La liste des variables disponibles dépend en fait du plugin d’envoi Mailshot, qui se charge d’appeler cette fonction dite « de contextualisation » juste avant chaque envoi. En plus des variables utilisateurs fournies par Mailshot la date courante est aussi disponible sous le nom date.
Langage SPIP
Pour des besoins plus complexes, il est possible d’utiliser le langage de squelette SPIP pour contextualiser l’info-lettre. Toutes les variables sont disponibles sous la forme #ENV{nomdelavariable}.
L’avantage de ce format est que l’on peut appliquer des filtres sur les valeurs des variables, ou indiquer une valeur par défaut quand la variable n’est pas fournie.
Il est donc possible d’utiliser une balise SPIP de ce type dans les champs titre, chapeau et texte de l’info-lettre : elle sera remplacée au moment de l’envoi.
Par exemple, pour faire un titre d’infolettre programmée qui change automatiquement en fonction de la date d’envoi, on y mettra :
Nouveautés du [(#ENV{date}|affdate)]
Pour utiliser ce formalisme dans les gabarits, il faut faire un peu plus attention. En effet si vous mettez simplement le code
<h1>Bonjour #ENV{nom}</h1>dans gabarit, #ENV{nom} sera calculé lorsque l’info-lettre est générée et non au moment de l’envoi.
Il faut donc échapper la balise pour qu’elle ne soit pas évaluée lors de la génération, et reste dans l’email pour être évaluée au moment de l’envoi :
<h1>Bonjour \#ENV{nom}</h1>C’est ainsi comme si on avait mis un @nom@ : c’est une variable de personnalisation, qui est calculée pour chaque destinataire
Le corrollaire de cette fonctionnalité, c’est que si vous voulez écrire du langage SPIP dans le texte votre infolettre envoyée [10], il faudra échapper les balises et les boucles pour éviter que celles-ci ne soient évaluées lors de la contextualisation.
Les variables accessibles par #ENV sont les mêmes que par le système de variables simplifiées [11].
Migration depuis un ancien plugin
Les anciens plugins SPIP-Listes, SPIP-Lettres et autres ne distinguaient pas réellement le contenu éditorial de l’infolettre et son envoi. Ainsi les info-lettres envoyées dans le passé avec ces plugins sont importées dans l’historique des envois par le plugin Mailshot et pas comme objet Newsletter par ce plugin.
Par ailleurs, le passage à ce plugin nécessitera que vous adaptiez vos gabarits selon les consignes indiquées plus haut, ou que vous utilisiez un des gabarits prêt à l’emploi du plugin.
Discussions par date d’activité
245 discussions
Bonjour, D’abord Merci pour votre aide et pour vos réponses.
Je suis entrain de mettre en place une newsletter, quand j’ai voulus l’installer il m’a dis qu’il dépendait de MAILSHOT, MAILSUBSCRIBER et FACTEUR.
Mais je n’arrive pas a trouvé comment le faire fonctionné, Pouvez-vous me dire comment procéder ? dans Édition > Infolettres , je veux Créer une infolettre, mais il n’y a pas de Modèle, comment ajouter le modèle BASIC SIMPLE ?
Merci
j’ai ce message lors d’envoi « SMTP Error : Could not connect to SMTP host. »
Répondre à ce message
Bonjour,
Tout d’abord merci pour ce plugin, qui qui permet de faire de jolies newsletters !
Néanmoins une petit problème :
La répétition mensuelle ne functionne pas bien et abouti à une répétition quotidienne.
La solution : une mise à jour des modules dans le répertoire « lib/when » du plugin.
On les trouve sur ce site : https://github.com/tplaner/When
Hanjo
Merci ! La version 1.3.1 du plugin intègre donc cette correction.
Répondre à ce message
bonjour,
l’orsque je fait le test d’envoi , j’ai l’erreur suivant :
Erreur SQL 1146
Table ’spip-ert.spipenpo_mailsubscribers’ doesn’t exist
SELECT DISTINCT listes FROM spip_mailsubscribers WHERE statut !=’poubelle’
quelqu’un peut m’aider
Répondre à ce message
Bonjour
Je rencontre un souci sur la version 1.3.0 SVN [75283] du plugin.
Je ne parviens pas à effectuer une sélection d’article par le navigateur proposé, le seul moyen est l’ajout rapide.
Quelqu’un aurait une idée du problème svp ?
Répondre à ce message
Bonjour
Je suis ravi du dev de ce plugin et ces composants.
pouvez vous m’expliquez dans la mesure de vos disponibilité pourquoi j’ai cet erreur
confirm_mailsubscriber : Accès interdit
Je suis configurer comme ça .
SPIP 3.0.11 [20757]
Newsletters 1.3.0 - stable
MailSubscribers 1.3.4 - stable
MailShot 1.5.8 - stable
Facteur 3.0.4 - stable
dans Interactivité de spip , j’accepte les inscriptions
dans Configuration des inscriptions à la Newsletter, Proposer l’inscription à la Newsletter lors de l’inscription au site
j’ai donc bien ma case a cocher avec #FORMULAIRE_INSCRIPTION
lors de l’inscription je reçois bien les deux mails :
lorsque je fait j’arrive sur la page du site avec le message suivant :
confirm_mailsubscriber : Accès interdit
pourtant dans l’espace privé de spip : Inscrits aux envois par email
À confirmer (1)
et c’est bien l’adresse de celui qui vient de s’inscrire,
il me faut donc changer la puce de en attente de confirmation a active
donc que puis je faire ?
@ bientôt dans la galaxie spip
Répondre à ce message
Bonjour,
Excellent plugin qui fonctionne parfaitement dans ces trois composants.
Bravo !
Néanmoins une petit problème qui peut devenir grand.
Tous les rédacteurs inscrits sur le site peuvent utiliser le module « infolettre » et envoyer « leurs » infolettres aux listes de diffusion disponibles sans que les administrateurs du site puissent contrôler cette activité. Est-il possible de n’accorder la possibilité d’utiliser le module « infolettre » qu’à certains rédacteurs choisis ?
Sinon, comme dans la gestion des articles et des brèves de Spip, ne serait-il pas plus judicieux de donner aux rédacteurs que la possibilité de « proposé à l’évaluation » leurs infolettres et non de les « publier ». Les administrateurs conservant exclusivement la faculté de publier ou non celles-ci, comme pour les articles et les brèves de Spip ?
Ce serait plus cohérent avec le fonctionnement habituel de Spip et éviterait, dans le cas d’un grand nombre de rédacteurs, une certaine « anarchie » dans la rédaction et l’envoi des infolettres, cause d’une saturation possible du serveur Smtp.
Cordialement et encore bravo !
Répondre à ce message
Bonjour,
Tout d’abord bravo et merci pour ce plugin, qui fonctionne très bien, et qui permet de faire de jolies newsletters personnalisées !
J’aurais toutefois une question concernant la génération de l’url de la newsletter.
En effet, de manière automatique, l’adresse générée est du type http://monsite.fr/newsletter/titre-de-la-newsletter.html .
Je souhaiterais pouvoir soit modifier cette url pour forcer l’affichage des newsletter dans une rubrique définie, soit restreindre l’accès à l’url directe de la newsletter (pour des utilisateurs inscrits).
Voyez-vous comment faire ?
D’avance merci pour votre aide.
Karen
Bonjour,
Pourriez-vous m’indiquer par quels moyens est-il possible de modifier l’url des newsletters (avant génération) ?
D’avance merci pour votre aide,
Karen
Répondre à ce message
Bonjour,
Merci pour ce plugin qui m’est bien utile !
Je me demandais s’il était possible, dans la phase de composition de la newsletter, de choisir les articles à mettre en avant via un mot-clé : j’affecte le mot-clé « newsletter » aux articles à mettre dans ma lettre d’info, et je choisis ce mot-clé dans une liste au moment de composer la lettre.
Est-ce que cela serait facile à mettre en place ?
Merci d’avance !
Répondre à ce message
bonjour
j’ai utilisé l’envoi rapide et évidemment j’ai eu beaucoup d’échecs. alors la question que je me pose est celle-ci : lors de l’envoi d’une nouvelle newsletter, les adresses mails classés en « fail » reste-t-il en mémoire ? dans le sens où lors d’un nouvel envoi, les adresses qui n’ont déjà pas reçu la première newsletter risquent-elles de ne pas recevoir les suivantes (à condition de ne plus être en envoi rapide biensûr) ?
je ne sais pas si ma question est très clair..
en fait je me demande s’il ne me faut pas vider la table spip_mailshots_destinataires..?
Non, les échecs d’envoi simple ne sont pas pris en compte dans la liste des abonnés. Seul l’envoi par Mandrill qui génère un feedback sur l’existence réelle de l’adresse est susceptible de provoquer des désabonnements.
Répondre à ce message
bonsoir
je suis désolé de ne cumuler que des probl !èmes sur ce plugin. excusez moi d’avance pour cette addition salée, mais si ça permet de débuguer...
1- aucun aperçu possible, la page reste blanche, quelque soit le modèle utilisé et le mode d’écriture à l’interieur de la lettre.
2 - envoi très lent, solutionné par envoir rapide.
3 - bouton test fonctionne une fois sur 10, le reste : « erreur d’authentification » (paramètres smtp vérifiés et ok)
4 - les lettres supprimées ne vont pas à la corbeille
5 - impossible d’avoir le contenu des boucles (articles, rubriques, etc) dans une newsletter, ce qui est le point le plus bloquant.
As-tu trouvé une piste ? Je rencontre les mêmes problèmes et j’ajoute un peu de sel...
Pour les boucles, elles ne s’affichent dans la newsletter envoyée que si tu les programmes toi-même en supprimant la jointure id_newsletter. Celle-ci est correcte sur l’aperçu, mais tout disparait à l’envoi. Il faut donc inventer sa propre boucle avec des critères plus classiques, et là ça marche. Il y a peut-être une question de version php ou mysql, mais là ça me dépasse.
Ce qui est bloquant c’est l’envoi exclusif par smtp (dans mon cas, deux hébergement OVH) : en rapide ça conduit à un taux d’erreurs de 96 % ! autant dire que rien ne part. L’envoi lent, lui, est aléatoire : entre 0 (la nuit) et 42% (le jour) d’erreurs. Par Mandrill, le taux de Spamming est tel que rien n’est distribué !
Les erreurs smtp sont celles que tu décris : erreur d’authentification pour un envoi sur deux en vitesse lente, et 9 sur 10 en vitesse rapide, c’est incompréhensible, puisque ce sont les bons identifiants, et cela rend le plugin inutilisable.
Les arguments hostiles à la fonction mail() sont contestables. Spip Listes marchait très bien, les 3600 et quelques newsletters partaient en une moins d’une heure, on maintenait la liste propre grâce aux retours sur le manager OVH et tout allait pour le mieux. Pourquoi ne pas laisser en option l’envoi par la fonction mail ? L’utilisateur choisit ce qui convient le mieux à son propre cas : ce n’est pas la même chose de gérer 100 abonnés et plus de 3500 !
Spip est un très bon CMS et ses auteurs sont des gens formidables, s’ils ont des réponses, des solutions ou même de simples pistes, cela aiderait bien !
Merci,
MR
les erreurs d’authentification aléatoires viennent du SMTP et pas du plugin : lorsqu’on utilise un serveur SMTP qui n’est pas dédié à l’envoi en nombre, il y a des limites en nombre d’envoi qui sont volontairement imposées par le fournisseur de mail pour éviter que le serveur ne soit justement utilisé pour l’envoi en nombre (spamming).
Donc je vais être un peu désagréable, mais les problèmes que vous rencontrez sont liés à une utilisation abusive d’un serveur SMTP qui ne devrait pas être utilisé pour faire de l’envoi massif.
Cela dit, il est vrai qu’il manque une gestion du retry sur l’envoi : quand un envoie échoue on ne re-essaye pas, et c’est un défaut de conception que je vais corriger asap. On ne devrait le marquer comme échoué qu’au bout de plusieurs essais (3, 4, 5 ?)
@michel :
Tu dis et c’est bien toute la question : cela montre que tes envois sont a priori non sollicités, ou à des adresses incorrectes etc.
En effet, on pourrait utiliser la fonction mail() pour envoyer ça, mais du coup ça veut dire que tes envois non sollicités considérés comme SPAM par les SMTP en réception ont toutes les chances de faire marquer le serveur en blacklist, et ensuite c’est tous les autres sites qui partages le même serveur qui seront pénalisés.
C’est la ligne de conduite que je me suis fixé dans le développement du plugin : permettre les envois en nombre qui sont respectueux de leurs abonnés (non considérés comme des SPAM), mais ne pas chercher à contourner les problèmes que posent les envois litigieux. Tout contournement pour résoudre son propre problème conduit inévitablement à dégrader la situation collective (plus de SPAM qui circulent, plus de règles strictes sur les SMTP, plus de difficultés à envoyer des mails).
Je vais donc corriger le problème du retry, mais je ne saurais que te conseiller de persévérer à utiliser Mandrill et à corriger ton problème à la source : contenu des mails envoyés, liste des destinataires... pour que ce ne soit plus considéré comme du SPAM.
@haqqtiviste :
pour l’aperçu quel navigateur utilise-tu ?
Pour le point 5, peux tu donner un exemple de boucle qui ne fonctionne pas ? Le modèle « basic » fourni par le plugin contient une boucle
ARTICLESqui fonctionne très bien, donc c’est un peu plus subtil que cela je suppose...Merci Cédric,
je suis entièrement d’accord avec toi sur les problèmes posées par le spamming et je te remercie de penser au retry. Peut-être que ça améliorera les choses.
Cependant, si je comprends très bien que la situation collective prime sur les cas particuliers, je ne pense pas être le seul à envoyer une newsletter hebdomadaire en nombre depuis plusieurs années avec Spip Listes et à ne pas trouver satisfaisantes les limitations du nouveau mécanisme, notamment le temps d’envoi interminable et le taux d’erreur, directement proportionnel à la vitesse d’envoi.
Ce que nous envoyons est honnête, la liste est nettoyée chaque semaine après les retours d’erreurs, et pour faire avancer les choses, voici un aperçu du Spam rating des messages (envoi depuis le site sur OVH) :
- envoi de la NL par Spip-Listes : 40.00
- envoi de la NL par Newsletters/Mailshot : 43.00
- envoi de la NL par Mandrill : 81.00
et pour info, les messages de contrib.spip.net ont 50.00.
Tu vois donc que le spam rating n’est pas seulement une question de contenu. Ce que je propose simplement, c’est de laisser aux utilisateurs la liberté de choisir leur système d’envoi, dont la fonction mail() de php, chacun assumant la responsabilité de sa décision.
Sur OVH, dès lors que le taux d’erreur dépasse 5%, les envois sont automatiquement bloqués. OVH évite ainsi le risque de « Black-listage ». Je ne suis pas un spécialiste, mais j’imagine que les spams ont pour source soit des sites piratés, soit des serveurs dédiés en divers endroits du monde, mais en tout cas qu’ils n’utilisent pas les outils Spip.
Pour conclure, je dirais que le plugin Newsletter mérite de sincères félicitations et que le seul bémol est dans les limitations imposées à l’envoi.
Merci en tout cas d’avoir répondu très clairement,
MR
J’ai oublié de parler du point 5 de @haqqtiviste, que j’ai rencontré aussi
La boucle basic :
BOUCLE_selectionarticles(ARTICLES)id_newsletter fonctionne très bien dans le squelette appelé par l’url page=newsletters/maNL&id_newsletter=x mais ne donne plus rien dès lors qu’on envoie le message.
Pour ma part, j’ai remplacé id_newsletter par des critères classiques (titre_mot=nnn et là, ça a très bien marché, tant en test par l’url que dans l’envoi.
C’est donc la jointure qui ne marche pas ou n’est pas prise en compte lors de l’envoi. Question de version sql ou php ?
MR
Non il n’y a pas de problème de jointure lors de l’envoi, ou de version sql ou php.
La différence entre la prévisu et l’envoi, c’est que la prévisu c’est toi qui la fait, sous ton nom, alors que l’envoi se fait en tant que visiteur anonyme (en tache CRON).
Tu n’utiliserais pas le plugin accès restreint, et une sélection d’articles à laquelle tu as accès mais pas les visiteurs anonymes ?
Merci de ta réponse,
J’utilise l’accès restreint, mais pas pour la rubrique concernée, qui est une sorte de back office pour la NL et quelques autres pages spéciales. Elle se nomme d’ailleurs Back Office.
Nuance toutefois, cette dernière n’est pas accessible au public et est exclue des boucles dans le site public par un id-rubrique !=x dans les squelettes de rubrique, de navigation et de backend.
Si on appelle un des articles directement, il s’affiche bien sur le site public sans restriction. Le plugin n’a pas à priori le moyen de connaitre les restrictions d’affichage dans les squelettes publics ?
@michel : non pas d’incidence a priori des restrictions d’affichage du squelette public lui même. Je ne peux pas voir a priori le problème donc, car je ne le reproduis pas, mais je suis preneur d’un modele de newsletter qui ne fonctionne pas pour le debug.
Par ailleurs la version 1.5.1 du plugin mailshot gère maintenant le retry (jusqu’à 5 essais par destinataire) en cas d’erreur. Et elle log dans tmp/log/bulksend.log les envois incomplets en mode cadence limitée, pour essayer de comprendre si c’est la raison pour laquelle l’envoi est plus lent que la cadence demandée dans ce mode là. Si tu peux tester et me faire des retours je suis preneur.
Pour info, je sais très bien que SPIP-Listes était capable d’envoyer très vites plein de mails, j’avais travaillé dessus il y a 5 ou 6 ans pour maximiser cette vitesse d’envoi. Ça n’a rien à voir avec l’utilisation de la fonction mail() en elle même, qui n’a aucun avantage par rapport au SMTP.
Mais les temps ont changé, et compte tenu de la prédominance du SPAM de nos jours et des stratégies de filtrage actuelles chez les fournisseurs de mails, ce n’est plus une bonne stratégie d’envoyer à toute vitesse.
Je ne nie cependant pas qu’actuellement le plugin ne respecte pas la cadence maxi demandée et envoie beaucoup plus lentement, ce qui est un bug que je cherche à corriger.
Merci Cédric, ta célérité m’emplit de confusion !
Je ne peux pas faire d’essai maintenant car il faudrait renvoyer la NL une nouvelle fois et c’est là que les abonnés vont nous prendre pour des indésirables. Je vais voir si je peux faire une liste de test avec des connaissances, mais cela n’ira pas au delà de quelques dizaines de personnes, je ne connais pas assez de monde.
En fait je m’occupe d’environ 25 sites dont une quinzaine ont une ou plusieurs newsletters. Ce sont les admins qui s’en occupent et gèrent les contenus et les listes, je ne suis que le développeur. Si je change leurs habitudes, il faut que ça soit pour un mieux. Le plus gros site a 5 listes différentes, la plus importante 3300 abonnés servis chaque lundi. J’ai pensé que le nouveau plugin serait plus simple pour eux et c’est ce dernier qui a posé problème.
L’envoi a commencé lundi soir, vers 18h00 avec 96% d’erreurs à vitesse rapide. Quand j’ai vu ça, j’ai mis en pause, c’était autour de 2500, et relancé en vitesse lente (2400/j), ça s’est terminé le lendemain vers 9h, soit plus de 12 h pour environ 700 mails seulement dont 420 erreurs.
J’ai recommencé un envoi complet en vitesse lente pour les 2500 premiers dont seulement 60 avaient été servis. Cela a duré de 9h à 14h30 le lendemain, environ 29 heures pour 2700 envois dont 897 en erreur.
Grâce au log mailshot, j’ai récupéré toutes les adresses non distribuées, j’ai créé une nouvelle liste Spip listes avec l’ancien patron relooké pour qu’il se rapproche du nouveau que j’avais modifié pour Newsletters, abonné les perdants et lancé l’envoi Spip Listes traditionnel. En 5 minutes les 897 étaient partis. Taux d’erreur = 0 sur le manager OVH de ce matin.
Mais bilan : la lettre du lundi est arrivé le mercredi pour pas mal de monde. Comme c’est une lettre hebdomadaire, ils ont ratés les premiers rendez-vous de la semaine.
Tout ce que je peux faire pour t’aider à fiabiliser Mailshot au niveau de Spip Listes, c’est de créer une (petite) liste de relations tolérantes et faire des essais avec eux pour t’envoyer les logs. Je ne peux pas jouer avec les abonnés de mes clients, certains comprennent que tout cela est compliqué, d’autres ne tolèrent pas la moindre anomalie et les eng... rebondissent en cascade jusqu’à moi. Par ces temps où beaucoup ne jurent que par WP ou Drupal, ce n’est pas le moment de prêter le flanc à la critique...
Et pourtant j’ai bien conscience que c’est un privilège de pouvoir travailler avec de tels outils. Il y a quelque chose de beau dans tous ces défis relevés !
MR
@cedric, j’ai le même problème que @haqqtiviste pour l’aperçu de la newsletter. J’utilise le navigateur chrome (à jour en v29).
Mes symptômes : J’ai une page blanche pour les boutons La version HTML email et La version HTML en ligne.
Par contre je vois bien la version texte email. Le bouton afficher sans iframe fonctionne aussi.
De plus, j’ai une page 404 quand je recalcule la page, bouton que j’utilise quand je modifie le gabarit de ma lettre. Pour voir mes modifications j’ai besoin de réenregistrer ma lettre dans la partie privée puis de re-cliquer sur le bouton prévisualiser, c’est une manip évidement répétitive et agaçante donc ;-).
C’est grave docteur ?
@michel : si tu peux faire les tests sur le site réel en conditions réelles cela suffit, pas la peine d’envoyer la newsletter à de vrais abonnés. Il faut que ce soit un vrai site (pour que le cron soit appelé en conditions réelles), et que l’envoi passe par le smtp qui te pose problème. Mais pour les destinataires on peut faire une liste de diff avec 100 adresses mails qui tombent dans ma boite, pour commencer, ça m’ira.
Contacte moi en direct par ma page http://contrib.spip.net/Cedric-Morin que l’on se cale ça si ça te convient.
@cdegourcy : pour voir la lettre après chaque chaque évolution du gabarit, il est plus simple de passer par l’url indiquée dans la doc plus haut :
spip.php ?page=newsletters/mongabarit&id_newsletter=XX
mongabarit étant le nom de ton squelette et XX l’id de ta newsletter en cours de travail. ça marche direct, nul besoin de faire les manips que tu décris.
@cdegourcy : le problème de prévisualisation est corrigé.
Le bouton prévisualiser est supprimé car il est ambigu et trompeur : il ne fait que recalculer le squelette qui affiche la newsletter, pas la newsletter elle même qui doit être regénérée après les modifs (oui ça oblige à passer par le bouton ’prévisualiser’).
Mais comme @michel le suggère, pour la mise au point du gabarit le mieux est d’utiliser l’url
?page=newsletters/mongabarit&id_newsletter=XX.@michel @cedric ça fonctionne parfaitement !
Une fois de plus, merci de votre réactivité et de votre efficacité.
La version 1.5.8 du plugin Mailshot résoud les problèmes de lenteur d’envoi : en dehors du mode rapide, quand on fixe une cadence, celle-ci est respectée (sauf si le SMTP est vraiment très lent, mais même dans de cas on sera beaucoup plus proche de la cadence demandée qu’avant).
La cadence maximale par défaut est passée de 300 à 600 mails/heure.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
