Alertes

Cette contribution ou ce plugin est en phase de test. Des bugs peuvent subsister. N’hésitez pas à les signaler dans le forum ci-dessous.

Ce plugin a pour but de permettre à vos visiteurs identifiés de recevoir des alertes email lors de la publication d’un article, en fonction des abonnements qu’ils ont choisit (à certains secteurs, à certaines rubriques, à certains mots-clés ou à certain auteurs selon ce qu’autorise le webmestre, bien sur).

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 ».

Configuration du plugin « Alertes »
Formulaire de configuration en back-office du plugin, permettant de choisir à quoi les visiteurs identifiés ont le droit de s’abonner : des secteurs, des rubriques, des mots-clés de certains groupes de mots-clés et/ou des auteurs

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

Formulaire d’abonnement global du plugin Alertes
Exemple basique d’un formulaire d’abonnement global du plugin « Alertes ».
Le rendu peut varier selon vos styles.

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.

Bouton d’abonnement du plugin « Alertes »
Exemple de bouton d’abonnement à un objet SPIP (ici une rubrique).
Son apparence peut varier en fonction de vos styles CSS.
Bouton de désabonnement du plugin « Alertes »
Exemple de bouton de désabonnement (ici à une rubrique).
Son apparence peut varier en fonction de vos styles CSS.

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.

Discussion

8 discussions

  • 1
    Christophe Noisette

    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

    [(#SESSION{id_auteur})]
    [(#FORMULAIRE_ALERTES_EMAIL{#id_auteur})]
    <code>
    
    Et le message affiché : 
    <code>
    1 	Erreur SQL HY000 / 1
    no such table: spip_alertes
    SELECT id_objet FROM spip_alertes WHERE objet = 'mot' AND id_auteur = 0

    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

  • obiwanriko

    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

  • 1

    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

  • 1

    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

  • 2

    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

  • 2

    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 profil

    Sans 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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom