Introduction
Ce plugin a pour but de permettre à des visiteurs identifiés de recevoir des alertes lors de la publication d’un article.
Il leur permet de s’abonner à divers objets SPIP (secteurs, rubriques, mots-clés, auteurs) et de recevoir un email (personnalisable) les informant de la publication d’un article associé à ceux-ci.
Les administrateurs du site peuvent définir à quels types d’objets SPIP les visiteurs ont le droit de s’abonner.
Attention toutefois : même si ce plugin est fonctionnel tel quel, il n’est pas « clef en main » et nous vous recommandons fortement de réaliser vos propres squelettes d’alertes afin d’obtenir des emails conformes à la charte de votre site.
Installation
Ce plugin nécessite le plugin Facteur : télécharger.
Il s’installe comme tous les autres plugins SPIP.
Configuration
Une fois l’installation terminée, il faut configurer le système d’abonnement aux alertes, via la page « Configuration Alertes » ( ecrire/?exec=configurer_alertes
) dans l’onglet « Configuration ».
Le formulaire de configuration présente les champs suivants :
- « Activer les alertes par email ? » : tant qu’il n’est pas à « Oui », aucune alerte n’est envoyée.
- « Mode d’envoi » : permet de choisir comment sont envoyés les emails d’alertes.
Si « Envoyer directement » est choisit (ce que nous déconseillons) : les emails d’alertes sont envoyés directement (et potentiellement en masse) dès que l’article correspondant est publié. Le top de la réactivité, mais très gourmand : à réserver aux petits sites n’ayant pas une grande base d’abonnés et/ou une faible fréquence de publication.
Si « Envoyer via le CRON » est choisit (ce qui est recommandé) : les emails d’alertes seront envoyés peu à peu (par lot) lors du passage du pseudo-CRON SPIP. Il faudra donc un certain temps pour que tous vos abonnés soit prévenus, mais cela allégera la charge.
Attention : si vous utilisez la configuration « Ne pas publier les articles avant la date de publication fixée. » de « Publication des articles post-datés », le système d’envoi d’alertes utilisera obligatoirement l’envoi via le CRON.
- « Intervalle de passage du pseudo-CRON SPIP (en minutes) » : vous permet d’indiquer à quelle fréquence (en minutes) le CRON de SPIP doit vérifier s’il y a des alertes à envoyer. Fonctionne si le mode d’envoi est à « Envoyer via le CRON » (ou si vous utilisez des articles post-datés).
- « Nombre d’emails d’alertes envoyés en un lot (CRON uniquement) » : vous permet de définir combien d’emails d’alerte sont envoyés à la fois par le CRON de SPIP, afin de ne pas surcharger votre serveur.
- « Identifiants des groupes de mots-clés abonnables (séparés par une virgule) » : vous permet de définir à quels groupes de mots-clés doivent appartenir les mots-clés auxquels les visiteurs peuvent s’abonner. Ils recevront donc une alertes dès qu’un article portant l’un des mots-clés choisis est publié.
Attention : nous définissons bien ici le(s) groupe(s) de mots, alors que l’abonnement en lui-même porte sur le (ou les) mot(s) de ce(s) groupe(s).
- « Identifiants des secteurs abonnables (séparés par une virgule) » : vous permet de définir à quels secteurs (rubriques de premier niveau) les visiteurs peuvent s’abonner. Ils recevront donc des alertes dès qu’un article est publié dans le secteur (sous-rubriques comprises).
- « Identifiants des rubriques abonnables (séparés par une virgule) » : vous permet de définir à quelles rubriques précises les visiteurs peuvent s’abonner. Ils recevront donc des alertes dès qu’un article est publié dans l’une de ces rubriques et uniquement dans celles-ci (sous-rubriques exclues).
- « Identifiants des auteurs abonnables (séparés par une virgule) » : vous permet de définir à quels auteurs les visiteurs peuvent s’abonner. Ils recevront donc des alertes dès qu’un article est publié par cet auteur.
Comment permettre aux visiteurs identifiés de s’abonner ?
Deux mécanismes distincts sont possibles : soit une gestion d’abonnement « générale », soit une gestion d’abonnements « au cas par cas » sur les objets possibles.
Gestion d’abonnement global
Un formulaire affichant tous les types d’abonnements possible pour un visiteur identifié est disponible.
Dans vos squelettes, vous pouvez appeler ce formulaire de gestion d’abonnement globale via #FORMULAIRE_ALERTES_EMAIL{#ID_AUTEUR}
Il faut donc lui passer une variable id_auteur, correspondant à celle de l’utilisateur (#SESSION{id_auteur}
par exemple).
Ce formulaire peut être placer dans une page de profil privée par exemple.
Un exemple basique est disponible dans le répertoire du plugin : /exemples/exemple-mes-alertes.html
Notez que vous pouvez surcharger ce formulaire d’abonnement global en surchargeant /formulaires/alertes_email.html
(et éventuellement /formulaires/alertes_email.php
si vous voulez ajouter vos propres traitements).
Abonnement au cas par cas.
Dans vos squelettes #FORMULAIRE_ALERTE
peut être utilisé dans une boucle pour permettre au visiteur de s’abonner (ou se désabonner) à l’objet affiché. Le formulaire capte automatiquement le type de la boucle et l’identifiant de l’objet affiché.
Bien évidemment, cela ne fonctionne que sur des objets pouvant recevoir des articles publiés : secteurs, rubriques, mots-clés ou auteurs.
Il est également possible d’expliciter sur quel objet portera le formulaire : #FORMULAIRE_ALERTE{rubrique,42}
affichera un formulaire pour s’abonner ou se désabonner à la rubrique 42.
Un exemple basique est disponible dans le répertoire du plugin : /exemples/exemple-abo-rubrique.html
Notez que vous pouvez surcharger ce formulaire d’abonnement global en surchargeant /formulaires/alerte.html
(et éventuellement /formulaires/alerte.php si vous voulez ajouter vos propres traitements).
Un fichier CSS (basique) les concernant se trouve dans le dossier /css/alertes.css
du plugin.
Personnaliser les alertes email envoyées
Une alerte est une email comprenant un sujet, une entête, un corps et un footer, qui disposent de leur propre squelette dans le dossier /alertes/
du plugin :
-
/alertes/sujet-email-alerte.html
: squelette servant à générer le titre de l’email envoyé. Doit renvoyer du texte brut. -
/alertes/header-email-alerte.html
: squelette servant à générer l’entête de l’email. Il peut contenir par exemple le nom du site, la date ou un message à l’intention du visiteur. -
/alertes/corps-email-alerte.html
: squelette servant à générer le contenu proprement dit de l’alerte, c’est à dire des informations sur l’article publié. -
/alertes/footer-email-alerte.html
: squelette servant à clôturer l’email d’alerte. Il peut contenir divers informations annexes (liens vers le site, vers le profil du visiteur ou le système de gestion des abonnements aux alertes).
Les squelettes d’alertes fournis sont très basiques : surchargez-les et créez les vôtres en ajoutant un répertoire /squelettes/alertes/
contenant vos fichiers de même nom.
Attention : ils s’agit de squelettes destinés à générer du contenu envoyé par email : cela implique moult restrictions et formatages particuliers (CSS dans le code html « inline » par exemple).
Dans chacun de ces squelettes, vous pouvez accéder à l’identifiant du visiteur abonné via #ENV{id_auteur}
, ce qui permet de personnaliser l’email.
Vous pouvez également accéder à l’identifiant de l’article concerné par l’alerte via #ENV{id_article}
.
Les emails sont envoyés via le plugin Facteur : veuillez à le configurer correctement.
Discussions par date d’activité
8 discussions
Bonsoir
Merci pour ce plugin... qui doit me résoudre un souci important. Avant ce plugin, je faisais des fichiers backend spécifique par mot clé, à la demande... Donc j’ai hâte qu’il puisse marcher. Mais pour le moment, j’ai une erreur. Voici mon code
Cordialement Christophe
Quel est le préfixe des tables de ta BDD ? La table spip_alertes y existe t elle ? As tu des messages utiles dans /tmp/log ?
Répondre à ce message
Bonjour,
Suite à la modification de connect.php afin de modifier l’adresse de notre serveur de base de données, l’ensemble des mails d’alerte (les articles publiés dans les rubriques « abonnables » depuis le début du site) sont repartis.
Est-ce normal ou prévisible ?
Note : nous sommes sur Spip 3.1.3, Php 7.1.24, MySQL, Alertes 2.03
Merci d’avance.
Janolap1
Répondre à ce message
Ce plugin peut-il fonctionner dans un site fermé aux visiteurs ? Sans utiliser les formulaires.
En effet nous aurions besoin qu’un agent soit alerté lors de la mise en ligne d’un article dans une rubrique spécifique.
il irait sur le lien du nouvel article, le relirait et transmettrait les corrections si il y en a.
Répondre à ce message
Bonjour,
Je cherche en ce moment à choisir quel plugin d’infolettre je vais choisir pour mon site. Permettre à l’utilisateur de choisir les éléments qui l’intéressent est l’avantage du votre, bravo.
Est il possible de faire un squelette d’alerte qui tienne compte de la date de dernière modification d’un article ? L’info sur la date de modif est disponible dans la table « spi_versions ».
Et puis la possibilité d’alerter quand un message est mis dans le forum d’un article surveillé (ou dans une rubrique surveillée) m’intéresse aussi.
Si c’est compatible avec la conception du plugin, je pourrai travailler sur les squelettes adéquats et partager, sinon ... je ferai autre chose ;-)
Faire un squelettes d’alerte « qui tient compte de la date de la dernière modification » est possible : c’est à dire modifier les squelettes d’alertes d’exemple pour y afficher par exemple la date de mise à jour.
Mais cela ne servira pas à grand chose : une alerte n’est envoyée que lors de la publication d’un article (passage à un statut « publié »). Il n’y aura donc pas de renvoi si l’article est édité/mis-à jour.
A moins bien sûr que vous déplubliez l’article, faîtes vos modifictaion puis le republiez : là il y aura renvoi d’un email d’alerte.
En l’état actuel du plugin , celui-ci envoi des alertes uniquement lors de la publication d’article. Les forum ne sont pas concerné.
Répondre à ce message
Bonjour,
Merci pour ce travail.
Je cherche à aussi envoyer une alerte quand un message est déposé dans le forum.
Possible ?
J’ai essayé mais visiblement je ne reçois rien...
Merci
Robert
Non, ce n’est pas possible en l’état actuel du plugin : celui-ci envoi des alertes uniquement lors de la publication d’article.
Répondre à ce message
bonjour, dans le formulaire, le chemin des images est de la forme
#CHEMIN{plugins/alertes/prive/themes/spip/images/
ce qui ne convient pas à certaines configurations, notamment si le plugin est dans le répertoire auto ou si l’on veut surcharger les images dans squelettes
Il vaudrait mieux mettre le répertoire images à la racine du plugin et faire
#CHEMIN{images/
merci +++
J’ai changé ça dans la 1.2.1
N’hésitez pas non plus à surcharger les formulaires (au moins les .html) pour les adapter à votre site.
bonjour, oui bien sûr c’est que j’ai fait, je signalais simplement la chose pour d’autres utilisateurs et que vous puissiez rendre ce plugin accessible. Il n’en reste pas moins qu’il ne fonctionne pas en l’état, voir mon message ci dessous concernant la confusion sur le destinataire, c’est l’auteur de l’article qui reçoit la notification, non pas l’abonné. Il y a un problème bloquant lié à l’ambiguité du champ id_auteur.
En ce qui me concerne, dans le besoin j’ai fait fait une système basé sur notifications et notifications avancées.
Bonne continuation
Répondre à ce message
Bonjour,
pb lors d’une notification de nouvelle publication dans une rubrique,
l’abonnement est bien présent dans la base. mais l’alerte est envoyée à l’auteur qui publie, non pas à l’abonné...
à plus
Répondre à ce message
Bonjour, voici quelques pb constatés en spip 3.0.17, z-core et spipr-dist
- Autorisations par secteurs ne fonctionne pas, les
#FORMULAIRE_ALERTE et #FORMULAIRE_ALERTE{rubrique,#ID_RUBRIQUE}
n’affichent rien, ni à la racine, ni dans les sous rubriques... ça roule pour une autorisation par rubriques. (testé avec et sans acces_restreint)-
#FORMULAIRE_ALERTE_EMAIL
dans une page profilSans acces restreint : erreur Table SQL « spip_zones_liens » inconnue (bonux 3.07 activé)
Avec acces restreint : les secteurs ne s’affichent pas et seuls les auteurs auxquels on s’est abonné s’affichent
vala pour un premier test, encore merci pour ce boulot
Bonjour, j’ai un pb bloqant, les alertes ne partent pas avec ou sans cron...
alerte.log
Nov 28 13:12:00 178.20.55.6 (pid 14983) :Pub:ERREUR : Lacement du cron
Nov 28 13:12:00 178.20.55.6 (pid 14983) :Pub:ERREUR : Il y a des resultats
mysql.log :
Nov 28 13:12:00 178.20.55.6 (pid 14983) :Pub:ERREUR : Table ’test0.id_alerte_cron’ doesn’t exist -
SELECT COUNT(DISTINCT date_pour_envoi <= ’2014-11-28 13:12:00’)
FROM id_alerte_cron
WHERE spip_alertes_cron
une idée ? merci, c’est complexe les notifications...
quelqu’un fait tourner ce plugin sur 3.0.17 ?
à propos, notifications est activé, pas d’incompat ? m’enfin j’ai essayé sans aussi...
Bonne journée
Bonjour,
Désolé de l’attente, mais j’ai bien pris en compte vos retours et merci d’avoir remonter ces problèmes.
J’ai publié une version 1.2 qui devrait je l’espère les résoudre .
Il est intéressant de savoir qu’on a une erreur " erreur Table SQL « spip_zones_liens »" même quand on entoure la boucle d’Accès Restreint par une boucle condition.
J’ai essayé de reproduire au mieux votre configuration (z-core, spipr-distn, comments, boostraps, less css, facteur, bonux, alertes, notifications, et éventuellement accès restreint) et tout semble fonctionner correctement.
Notification ne semble pas avoir d’impact. Enfin si : si vous êtes un des auteurs de l’article publié et qu’en plus vous êtes abonnés à une alerte qui lui correspond, vous recevrez deux email lors de la publication en ligne : celui d’Alerte et celui de Notification.
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 : |