Notifications avancées

Une API générique pour créer des notifications.

Description

Ce plugin est avant tout un outil de développement, qui permet de déclarer des notifications possibles et fournit des moyens pour gérer des abonnements et des désistements pour celles-ci.

On part du principe qu’une notification c’est :

  • un contenu, possiblement en plusieurs format (texte brut, HTML, court)
  • des destinataires par défaut, choisis par la notification elle-même
  • des destinataires explicites, qui se sont abonnés
  • des rabats-joie qui veulent bloquer une notification
  • optionnellement des préférences qui conditionnent l’envoi ou pas pour un destinataire
  • des modes d’envoi (email, jabber, sms, pigeon...)

Tous ces éléments sont alors programmables lors du développement de la notification, de manière assez fines, et toujours optionnelle. On peut donc déclarer une notification avec juste un squelette SPIP, ou bien imaginer des choses plus complexes.

Appeler une notification

Tout d’abord, pour utiliser une notification, il faut qu’elle soit appelée quelque part. C’est la fonction classique de SPIP :

// Chargement de la fonction
$notifications = charger_fonction('notifications', 'inc/');

// Appel générique
$notifications('truc', $id, $options);

// Exemple
$notifications('patate_instituer', $id_patate, array('avant' => $statut_avant, 'apres' => $statut_apres));

Contenu de la notification

Une notification sans contenu, c’est comme une mouche sans ailes. Plusieurs moyens sont proposés pour indiquer ce qui sera envoyé.

Uniquement en créant des squelettes

  • notifications/truc.html correspond au texte brut de la notification, c’est le minimum à fournir pour l’envoi par email
  • notifications/truc_html.html correspond à la version HTML
  • notifications/truc_court.html correspond au format court, de type SMS ou Microblog (limité en caractères, donc)

Ces trois squelettes reçoivent diverses informations utiles en contexte :

  • quoi : le nom de la notification
  • id : l’identifiant passé en paramètre
  • options : l’éventuel tableau d’options
  • mode : le mode d’envoi pour lequel on est en train de générer le contenu
  • destinataire : un id_auteur (souvent) ou bien une information de contact (adresse email par exemple)
  • contact : toujours l’information de contact en rapport avec le mode d’envoi utilisé
  • objet, id_objet, id_truc : les informations sur l’objet concerné par la notification en utilisant le même principe que pour les modèles : le premier mot du nom de la notification est le type de l’objet (article_instituer, patate_supprimer, etc).

En passant par PHP

Vous pouvez aussi créer une fonction notifications_truc_contenu_dist($id, $options, $destinataire, $mode) dans le fichier notifications/truc.php. Cela permet parfois plus de possibilités ou de lisibilité.

Cette fonction prend en paramètre l’identifiant et le tableau d’options qui ont pu être passé dans la notification, mais aussi le destinataire à qui est en train d’être envoyé le message (un id_auteur ou une info de contact, comme précédemment), ainsi que le mode d’envoi (« email » par exemple).

La fonction peut soit renvoyer directement un texte, ce qui correspondra au texte brut de la notification, soit renvoyer un tableau avec trois clés optionnelles :

  • texte : le texte brut du message
  • html : la version HTML
  • court : la version courte

Pour chaque possibilité, si la clé n’existe pas dans le tableau, alors le plugin cherchera le squelette correspondant dans la première méthode, sinon rien.

Destinataires

Désormais, votre notification existe. Mais elle ne sera jamais envoyée à personne si elle n’a pas de destinataires ! Le plugin permet trois sources d’où peuvent provenir les malheureux spammés. :) :

  1. Une liste définie lors du développement de la notification.
  2. Des gens abonnés explicitement, stockés dans une table de la base.
  3. Ces deux sources s’additionnent, et une fois la liste constituée, elle passe dans le pipeline notifications_destinataires, et peut donc être étendue.

Destinataires par défaut

Vous pouvez définir les destinataires d’une notification en créant la fonction notifications_truc_destinataires_dist($id, $options) dans le fichier notifications/truc.php.

La liste est un tableau donc chaque élément est un destinataire. Ce dernier peut être décrit de trois manières différentes suivant vos besoins ou infos à votre disposition :

  • un id_auteur : c’est le cas le plus courant et le plus générique, car il permet ensuite d’envoyer par plusieurs modes d’envoi
  • une adresse de courriel : dans ce cas seul le mode d’envoi « email » pourra être utilisé, c’est un cas possible pour des forums publics par exemple où les gens ne sont pas inscrits
  • un tableau explicite des modes d’envoi : enfin on peut décrire explicitement comment sera envoyé le message à un destinataire, avec un tableau dont chaque clé est le nom d’un mode d’envoi, et la valeur de la clé est l’information de contact pour ce mode d’envoi

Exemple :

function notifications_truc_destinataires_dist($id, $options){
	return array(
		16, 38,12,  // des id_auteur
		'paul@personne.fr', 'livarot@fromage.com', // des emails
		array( // un tableau explicite pour UN destinataire
			'email'=>'truc@bidule.net',
			'sms'=>'0606060606',
			'jabber'=>'truc@jabber.fr'
		),
	);
}

Destinataires abonnés

La deuxième méthode consiste à fournir à vos utilisateurs des moyens pour s’abonner explicitement à une notification. Le plugin contient donc une table dédiée à cela, ainsi que des actions.

La table des abonnements contient :

  • id_auteur : l’utilisateur concerné par cet abonnement, peut valoir 0 si on utilise plutôt l’information de contact
  • contact : une information de contact si ce n’est pas pour un utilisateur inscrit (par exemple une adresse email)
  • quoi : le nom de la notification
  • id : l’identifiant éventuel pour cette notification
  • preferences : un éventuel tableau (sérialisé pour le stockage) contenant les préférences de l’abonné, si la notification en utilise
  • modes : un tableau (sérialisé aussi) contenant la liste des modes d’envoi à utiliser pour cet abonné ; si cette liste est vide, cela signifie que l’utilisateur ne veut PAS recevoir cette notification (blacklist)
  • actif : 1 pour activer l’abonnement, 0 pour le désactiver

Action « abonner_notification »

Cette action permet d’abonner peut être utilisée soit telle quelle pour un abonnement très simple, soit dans le traitement d’un formulaire.

Par défaut, elle abonne l’utilisateur actuellement connecté, uniquement par email, en prenant en paramètre la notification « quoi-id » :
#URL_ACTION_AUTEUR{abonner_notification, truc-32}

Mais on peut aussi l’appeler en PHP :

$abonner = charger_fonction('abonner_notification', 'action/');
$abonner('truc-32', $modes, $preferences);

On peut donc optionnellement passer deux tableaux $modes et $preferences, qui seront utilisés pour cet abonnement.

L’action sait aussi récupérer les POST contact pour l’information de contact si ce n’est pas pour un utilisateur, modes et preferences qui seront utilisés si on ne les fournit pas à la fonction.
On peut donc facilement utiliser cette fonction comme traitement d’un formulaire.

À terme le but est de savoir générer automatiquement des formulaires pour s’abonner ou pour configurer des abonnements.

Programmer des préférences

Une notification complexe peut définir une fonction qui indiquera pour chaque destinataire abonné (ceux qui sont dans la table) s’il doit recevoir ou pas le message suivant des préférences qu’il aurait.

Pour cela il faut définir une fonction notifications_truc_preferences_dist($id, $options, $preferences) dans le fichier notifications/truc.php.

En plus des informations classique de la notification, la fonction reçoit les préférences d’un destinataire. Normalement ces dernières ne sont jamais vides puisque la fonction n’est justement appelée que s’il y a des préférences.

On doit renvoyer « true » ou « false », suivant que le destinataire doit être ajouté ou pas.

Ne plus recevoir une notification

Le système d’abonnements explicites permet de s’assurer que vos utilisateurs veulent vraiment recevoir une notification. Mais comme nous l’avons vu, certaines notifications définissent elles-mêmes leur liste de destinataires, et ces derniers n’ont donc pas leur mot à dire.

Avec la même table, on permet donc la désinscription explicite à une notification. Vous pouvez donc proposer à vos utilisateurs de ne surtout pas recevoir telle ou telle notification.

Pour cela, il faut les abonner à une notification avec une liste de modes d’envoi vide. Cela signifiera qu’ils sont blacklistés pour cette notification.

Modes d’envoi

Les modes d’envoi sont un ensemble de fonctions PHP placées dans notifications/modes/bidule.php.

Pour implémenter un nouveau mode d’envoi, il faut deux fonctions :

  • notifications_modes_bidule_envoyer_dist($contact, $contenu) qui va envoyer le contenu au contact par le mode bidule
    • $contact contient une information de contact déjà vérifiée et cohérente avec le mode
    • $contenu est un tableau pouvant contenir « texte », « html » et « court », les trois formats de message
  • notifications_modes_bidule_contact_dist($destinataire) qui doit renvoyer une information de contact cohérente avec le mode en question (une adresse email pour le mode « email », un numéro pour le mode « sms », etc) par rapport au destinataire passé en paramètre
    • $destinataire peut être une information de contact à vérifier et si c’est bon la garder, sinon renvoyer « null »
    • ou bien cela peut être un id_auteur, et dans ce cas la fonction doit essayer de trouver une information de contact valable pour ce mode en rapport avec cet id_auteur, sinon renvoyer « null »

Il faut ensuite créer un fichier bidule.yaml au même endroit, afin de déclarer ce mode d’envoi. Le fichier doit contenir :

titre: 'Nom du mode'
description: 'Une description un peu plus longue'

# On peut utiliser des chaînes de langue simple
titre: '<:truc:bidule_titre:>'

Encore à faire

Le noyau des fonctionnalités est normalement assez complet. Maintenant ce qu’il manque, ce sont les interfaces et formulaires prêt-à-l’emploi pour gérer les notifications.

Il faudrait donc faire :

  • un formulaire de configuration pour les admins qui liste automatiquement toutes les notifications déclarées afin de les activer ou pas pour l’ensemble du site
  • un formulaire pour gérer les abonnements d’un auteur (un début simple existe) listant ses abonnements actuels et permettant de les modifier
  • un formulaire permettant de créer ou modifier un abonnement et sachant automatiquement générer les champs pour les préférences qui auraient été décrites dans le fichier de déclaration de la notification (en YAML)

Discussion

15 discussions

  • 10
    Stanislas

    Bonjour,

    C’est tip-top pour faire envoyer un message par formulaire CVT pour un bidouilleur dans mon genre !

    J’ai une question liée à l’utilisation du plugin job-queue. L’envoi du message se place dans la liste des jobs et donc est envoyé lorsqu’un visiteur s’agite sur le site.

    Mon problème est qu’il s’agit d’un intranet en accès restreint donc avec un traffic faible ou en tout cas à la fréquence aléatoire. Comment faire pour déclencher immédiatement l’envoi du mail (réserver à 2 ou 3 admins) ?

    Merci d’avance pour votre aide ou une piste.

    • La réponse se trouve là : http://www.arscenic.tv/mediaspip/ferme-a-mediaspip/gestion-generale-de-la-ferme/article/le-plugin-gestion-de-la#super_cron

      Un cron système qui appelle toutes les minutes le cron de SPIP, et donc lance des tâches, sans visiteur du site.

    • Stanislas

      Merci ! :-)

    • Bonsoir,
      je remonte ce thread car j’aurais besoin de cette possibilité : envoyer des notifications plus rapidement, soit activer le cron plus souvent qu’avec des visites. Mais le site de kent1 arsenic n’existe plus.

      y-a-t-il depuis une autre possibilité ?

      Sinon avec un envoi groupé, ce qui ne semble pas possible - à part en utilisant une liste- tel que je comprends les choses -j’ai tenté différentes approches pour envoyer la liste ou tableau des id_auteurs mais job_queue prend les destinataires un à un.

      merci !

    • Oui c’est voulu car les notifs peuvent toutes être potentiellement personnalisées destinataire par destinataire (le contenu final est produit pour chaque destinataire, on peut possiblement y mettre son nom, etc).

      « super cron » c’est obsolète je crois, la simple action=cron suffit il me semble. Pour cela tu dois avoir la main sur un cron linux (celui du serveur du site par ex, ou pas), et tu le programmes *toutes les minutes* par ex (c’est le plus petit qu’on puisse faire en cron linux), pour appeler l’URL action=cron de ton site. Et hop, ça fait un hit dessus toutes les minutes et lance donc les jobs en attente.

    • Merci Maieul,
      je ne connaissais pas.
      Cela ne semble pas très différent de la page « exec=job_queue »

      Maieul, Rasta,
      Je cherche du simple et sans action supplémentaire, soit lancer une action de déclenchement job autrement qu’avec un bouton ou depuis le serveur ?
      -  soit via un job déclencheur de(s) action(s) que l’on veut qui aurait un timing plus court
      -  soit modifier le timing du job des notifications avancees ?

      J’ai vu passer la possibilité de dire que les mails étaient « importants » pour squizzer le temps du cron du job.

      Merci !
      ++

    • Bé c’est ce que je t’ai décrit non ? Tu dois configurer un cron linux pour faire un hit (avec curl par exemple) sur ton site à l’URL action=cron : curl  http://www.domaine.tld/spip.php?action=cron

      Et ça lance alors les jobs toutes les minutes, en continue, tant qu’il y en a.

    • Ce que je demande et qui intéressera aussi les personnes qui n’ont pas la main sur le serveur c’est si il n’y a pas d’autres moyens ?

      merci

    • Du peu que je sais, de ce que j’ai pour l’instant compris, c’est antinomique : un site PHP classique (et d’autant plus sur un hébergement classique justement) ça ne s’exécute que s’il y a des hits dessus, des visites.

      Donc soit ton site a plein de visites, et les jobs se lancent souvent. Soit tu dois obligatoirement forcer de faire des hits dessus, et souvent on fait ça avec un cron linux toutes les minutes pointant sur action=cron de ton site (le cron linux n’étant pas forcément sur la même machine que le site, peu importe du moment que ça fait un appel dessus, avec curl).

      Tant qu’il n’y a pas de hit, le site « n’existe pas », il ne fait rien tout seul, il n’y a pas de logiciel qui tourne tout seul en arrière plan.

    Répondre à ce message

  • 2

    Bonjour,

    Pour mémoire :
    Un bug de Notifications avancées avec le multilinguisme a été signalé par ici :

    Merci

    Répondre à ce message

  • 6

    Bonjour, je cherche à faire quelque chose d’à priori simple, à savoir d’avertir le webmestre quand un auteur modifie sa fiche, mais il semblerait qu’il me manque quelque chose.

    J’ai créé un mail basique instituerauteur.html ainsi qu’un instituerauteur.php sous squelettes/notifications avec ceci :

    function notifications_instituerauteur_destinataires_dist($id, $options){
    	$notifications = charger_fonction('notifications', 'inc');
    	$options = array('statut' => $statut, 'statut_ancien' => $statut_ancien);
    	return array(1);
    }

    Que me manque-t-il, pour me coucher moins bête ? Merci beaucoup pour tout éclaircissement.
    Amicalement.

    • Mais est-ce qu’il y a bien un appel pour lancer une notification avec ce nom quelque part ?

      (et par ailleurs « instituer » c’est juste quand on change le statut, pas les autres champs)

    • En effet, pas. Je me suis peut-être un peu surestimé en m’imaginant que ce serait simple, je ne suis pas très familier des fonctions de SPIP non plus. Est-ce que je peux faire un appel à cette fonction dans ce même fichier PHP et y a-t-il un event quand on édite un auteur (via auteur_modifier() ou revision_auteur() ?).

    • Une notification est… « enclenchée » on va dire (et non pas « envoyée » car justement par défaut ça ne génère ni n’envoie rien tant que la notif n’est pas « implémentée » par quelqu’un) lorsqu’on appelle la fonction centrale d’API qui est fournit par SPIP directement : #Appeler-une-notification

      SPIP en appelle déjà un certain nombre lui-même dans divers fonctions génériques (objet_modifier, etc). Donc à toi de voir si yen a déjà une d’appelée lors de l’événement que tu veux notifier. Et ensuite faut l’implémenter, soit soi-même dans une fonction qui fait tout (ce que cherche l’API de SPIP par défaut), soit avec les facilitations de ce plugin-ci (décrire quels destinataires, quel contenu, etc), cf sa doc.

      Si SPIP n’appelle pas de notification pour l’événement que tu veux, eh bé oui là va falloir t’insérer quelque part, dans un pipeline au bon endroit (post_edition, etc) et appeler une notification du nom que tu veux. Il est fort probable que pour l’édition d’un auteur il y ait déjà un appel, car c’est le cas pour tous les objets à priori MAIS, ça va être une notification appelée pour chaque modif, sans savoir de qui elle vient. Si tu veux envoyer une notif seulement quand tu sais que c’est la personne elle-même qui a modifié sa propre fiche, là forcément faut que tu t’insères dans post_edition, que tu testes qui vient de faire la modif de qui, pour comparer, etc.

    • Ok, merci beaucoup pour ces éclaircissements, je vais potasser la chose et te redirai si je parviens à mes fins.

    • Luc, je serais intéressé par ce que vous venez de décrire.
      On peut mettre en commun ?
      Merci par avance

    • Volontiers. Je n’ai pas encore eu l’occasion d’aller plus loin, mais en tout cas, la simple fonction citée plus haut envoie bel et bien, en cas de changement de statut de l’auteur, le mail html. Reste à adapter la fonction pour qu’elle capte la modification du contenu de l’objet à la place... Je pensais poster le résultat (si je trouve), de toutes façons.

    Répondre à ce message

  • 1
    Khalman

    Bonjour,
    l’installation du plugin Notifications avancées 0.4.3 échoue sur un SPIP3.2.4 neuf et aucune table n’est installée.
    « Erreur SQL 1146
    Table ’spip_notifications_abonnements’ doesn’t exist »

    Que faut-il modifier ?
    Merci

    • Cette erreur, c’est après l’installation, une fois que ça n’a pas marché. Mais est-ce que tu vois des erreurs au moment de l’installation, dans le dossiers des logs de SPIP, pour mysql ou sqlite ? Genre qui diraient qu’il y a une erreur sur tel champ…

    Répondre à ce message

  • 6

    Sur un site en SPIP 3.2.1 [23954]
    lorsque je veux mettre à jour ce plugin Notifications avancées 0.4.2 - test j’ai le message :
    « • Le plugin Notifications avancées dépend du plugin S. » [sic : je ne sais pas quel est ce S.]

    J’ai le plugin « Saisies pour formulaires 3.11.2 - stable » activé

    • Du plugin « S » ? Jamais vu ça. Si c’est coupé c’est qu’il y a un bug PHP à priori.

      L’autre S c’est spip_bonux dans les dépendances.

    • Bonjour RastaPopoulos,
      Bonne année à toi ! Et à la communauté Spip également.
      J’ai le même problème, mais sur un SPIP 3.2.0 que je m’apprête à mettre à jour (et que tu connais bien ;)).
      J’ai mis à jour Saisies pour formulaires vers la version 3.11.2 et SPIP Bonux en est à la v3.4.6, mais je ne peux pas mettre à jour Notifications avancées 0.4.2. : même message d’erreur.
      Merci d’avance pour ton coup d’oeil,
      Nathalie

    • J’avais le même problème. C’est la 1re fois que j’avais ce type de message d’erreur
      J’ai téléchargé manuellement le zip, dézippé, uploadé dans le répertoire plugins\auto\notifavancees\v0.4.3 puis activé.
      En activant la v0.4.3, ça a désactivé la v0.4.2 que j’ai supprimée totalement après vérif.
      Tout à l’air de fonctionner

    • Merci guilaind ! J’ai suivi cette méthode et ça a fonctionné !

    • Bonjour,
      Même erreur ici : « Le plugin Notifications avancées dépend du plugin S. »
      Le mystérieux plugin S. Ça sonne comme un album de Blake et Mortimer :-)
      Bon je vais mettre à jour à la mano.
      Pierre

    • Juste une remarque supplémentaire, Rastapopoulos (oui on est finalement plus dans un album de Tintin :-) dit que si c’est coupé comme ça c’est un problème de PHP, mais ça n’est pas exactement coupé net, c’est un message propre dans la page avec un "." à la fin de la phrase ... Exactement « Le plugin Notifications avancées dépend du plugin S. » sous la bannière "Liste des plugins" avec un joli cadre rouge et tout le reste de la page propre.
      Bizarre.
      Pierre.

    Répondre à ce message

  • 3

    Bonjour,

    j’utilise les plugins commande et facteur et j’aimerai lors d’un envoi d’une notification de commande ajouter un document à la notification en utilisation $corps[’pieces_jointes’] de facteur. Je ne vois pas ou je peux intervenir afin de modifier cette variable.

    Merci Rainer

    • Je me réponds à moi même.

      En utilisant

      notifications_truc_contenu_dist($id, $options, $destinataire, $mode)

      dans le cas d’une commande

      notifications_commande_client_contenu_dist()

      il est possible de retourner un tableau contenant les pieces jointes.

      		$corps = array(
      			'pieces_jointes' => array(
      				array(
      					'chemin' => $chemin,
      					'nom' => $nom,
      					'encodage' => 'base64',
      					'mime' => $doc['mime_type']
      				),
      			),
      		);
      
      		return $corps;

      par contre, pour que cela soit pris en compte, il faut encore surcharger notifications/modes/email.php

      en y ajoutant

      		if ($contenu['pieces_jointes']) {
      			$corps['pieces_jointes'] = $contenu['pieces_jointes'];
      		}

    Répondre à ce message

  • 5

    Bonjour,
    1/ j’ai crée un objet spip et l’objet a une date début et une date fin
    2/ Je veux recevoir un mail 30jours avant la date fin

    Est ce plugin peut m’aider a réalisé ce que je veux faire ??? si oui quelques sont les fichiers a modifié ??

    Merci de votre aide

    • Hello,

      Je relance cette question. Pour un futur plugin, j’ai une date de fin sur un objet. Et je voudrais recevoir une alerte X temps avant cette date de fin.

      Comment le plugin peut m’aider ?

      Amicalement

    • Bah non, enfin oui et non, mais pas la partie qui est la plus importante. Ce plugin ne s’occupe que de gérer la génération des messages, les destinataires, et les envois suivant plusieurs modes SI il y a un appel à la fonction « notifications » quelque part. Le plugin n’appelle rien, lui.

      Or là votre besoin, il faut forcément qu’un cron teste tous les jours si ya un truc qui se finit dans 30 jours, et que dans ce cas, le cron fasse une notif (avec l’aide de ce plugin ou pas, c’est une autre histoire).

    • Cool. Merci pour l’info.

      En lisant l’article, j’avais l’impression (fausse) que ce plugin permettait d’avoir des règles pour envoyer des notifications.

      Or, de ce que tu fais, on doit créer les règles en question. Le plugin gérant des modes de notifications (et le(s) qui associé(s) en conséquence).
      C’est le paragraphe « Programmer des préférences » qui m’a induit en erreur je pense.

    • Teenoo

      Sujet qui m’intéresse également ! Du coup, on laisse tomber ce plugin pour ce genre d’utilisation et on se dirige vers un autre ?

    • Bah pas forcément à laisser tomber mais ce n’est pas le cœur du sujet. La partie qui dit QUAND envoyer, peut très bien ensuite utiliser Notifications avancées pour déléguer la gestion des envois, la définition des contenus (avec la formalisation des squelettes utilisée ici) etc.

      Mais le cœur, ça reste le QUAND est-ce qu’on envoie. Donc forcément un truc perso ou un plugin générique (Touti avait commencé un plugin Relances pour ça, peut-être à améliorer/rendre plus générique) qui ajoute des génies réguliers, qui testent des dates de fin bien définies, et qui alors décident d’envoyer des choses à telles et telles personnes.

    Répondre à ce message

  • Si on a un problème dans l’affichage du mail, particulièrement si le mail est en plain texte et se trouve tronqué ou raccourci, inutile de passer 3 heures à chercher, il faut désactiver le mode convertir en ISO-8859-1 dans la configuration du plugin facteur …

    Répondre à ce message

  • 4

    J’utilise « notifications avancées » pour suivre une certaine activité éditoriale sur abonnement.
    J’aimerais retarder l’envoi de la notification de quelques minutes,
    pour laisser le temps au rédacteur de modifier l’objet qu’il crée avant de notifier tous les abonnés.

    S’il modifie, je récupère alors le job dans la queue et ajoute un nouveau délai.
    Et ainsi de suite jusque quand l’objet ne bouge plus.

    Je pensais donc appeller la fonction avec job_queue_add(), comme ceci :

    	$function = 'notifications';
    	$description = "NOUVEL OBJET notification abonnés de $id_rubrique";
    	$arguments = array($id_rubrique, $options);
    	$file = 'inc/';
    	$time = time() + 60*5;  // dans 5 minutes
    	$id_job = job_queue_add($function, $description, $arguments, $file, $no_duplicate, $time, $priority);

    Ca ne marche pas, et sans doute je me dis parce que le pipeline ’notifavancees_pipelines.php’ appelle lui-même la fonction job_queue_add() pour envoyer à chaque abonné.

    job_queue_add() qui appelle job_queue_add() : est-ce bien la raison pour laquelle que ça ne fonctionne pas ?

    Dois-je m’y prendre autrement ?

    Merci d’avance pour les pistes de solutions.

    • Je pense avoir à peu près compris le but final recherché, mais je ne comprends absolument pas ce que tu crois faire avec tes appels là.

      Au moment de la modification d’un objet, il faut plutôt aller chercher dans la queue s’il y a déjà une tâche d’envoi programmée avec tel ou tel paramètre (tel nom de notif, tel id d’objet, etc), récupérer alors son identifiant de tâche (id_job), et modifier alors sa date. Enfin je vois ça comme ça.

    • Petite confusion dans mon explication : le bout de code ne montrait pas comment j’allongeais le délai, mais seulement comment je créais ma nouvelle tâche dans la queue.

      Ca parait peut-être aller de soi, mais alors que la tâche est bien dans la queue, au final elle ne s’exécute pas.

      Et comme ça ne marche pas, je me demandais si on peut mettre en queue une fonction comme ’notifications’ qui, lorsqu’elle s’exécute, va passer dans le pipeline notifavancees_pipelines.php et donc à nouveau exécuter job_queue_add().

      J’espère avoir été plus clair.

    • Les tâches dans la file d’attente ne s’exécute que s’il y a des visites sur le site. Sinon c’est toujours en attente. Pour remédier à ça, le mieux est de programmer un serveur (n’importe lequel, le même où est le site où un autre, peu importe) avec un cron (une tâche régulière) pour appeler toutes les minutes le cron du SPIP (spip.php?action=cron).

    • Apparemment c’est l’influence du plugin tickets qui pose un problème. Voir la suite par là : 471183
      Bonne journée,

    Répondre à ce message

  • 1

    Salut !
    Alors que la notification est correctement envoyée à ma liste d’abonnés, à chaque envoi j’ai ce message dans les logs de spip :

     :Pub:ERREUR: fonction execute_pipeline_notifications_destinataires absente : pipeline desactive

    Est-ce dû à une erreur de ma part ?

    • Mmmh je ne sais pas. En tout cas ce n’est pas bien grave.

      Je ne sais pas si c’est parce que ce plugin ne déclare pas ce pipeline mais l’utilise dans le code, sauf que ce ppipeline est déjà utilisé aussi par le noyau de SPIP donc c’est pas une invention.

      Fin pour l’instant j’en sais rien. Oui je sais je ne suis pas d’une grande aide là. :D

    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