Abonnements

Gérer des abonnements à des offres, et uniquement cela.

Ce plugin a pour but de regrouper tout ce qui est commun aux différents types d’abonnements possibles (à des zones restreintes, à des contenus précis, à une version papier pourquoi pas aussi...).

Il permet de définir les offres d’abonnement proposées par le site, et gère les personnes qui y sont abonnées, désactivant l’abonnement au bout d’un temps donné.

Comme il peut y avoir toute sorte de cas, ce n’est pas ce plugin qui décide quels droits sont donnés lors d’un abonnement. C’est à d’autres plugins d’implémenter cela, par exemple pour lier alors automatiquement un utilisateur à une zone restreinte.

Offres d’abonnement

L’élément central proposé par ce plugin est l’offre d’abonnement. Une offre contient :

  • un titre
  • un descriptif
  • une durée (un nombre) et un type de période (mois, jours, ou heures)
  • un prix (qui peut être 0, donc gratuit)

Vous devez donc créer au moins une offre pour ensuite avoir des abonnés. Pour cela il faut aller dans Publication => Offres d’abonnement.

Ajouter un⋅e abonné⋅e

Dans ce plugin, un⋅e abonné⋅e met en relation un⋅e utilisateurice de SPIP et une offre d’abonnement. Cette relation est datée avec un début et une fin.

Pour ajouter des abonné⋅e⋅s, vous devez donc déjà avoir des gens inscrits sur votre site, quelque soit leur statut. Dans la plupart des cas, il s’agira du statut “visiteur”, qui sert uniquement dans le site (sans accès à l’admin). Il faut ensuite aller sur la page d’une offre où se situe un lien d’ajout.

Lorsqu’on ajoute un⋅e nouvel⋅le abonné⋅e, il est seulement possible de sélectionner un⋅e utilisateurice. Automatiquement, le formulaire utilisera la date de création comme date de début, et calculera la date de fin en ajoutant la durée de l’offre dans laquelle on se trouve.

Pour des besoins particulier, ces dates sont toujours modifiables après-coup. On peut donc éditer un abonnement, et changer ces deux dates. En revanche, le compte SPIP lié à l’abonnement n’est pas modifiable.

Suivre les abonné⋅es

Sur la page de chaque offre, on trouve la liste des abonné⋅e⋅s à celle-ci. Mais il existe aussi une page de suivi générale qui permet d’avoir une vue d’ensemble de tous les abonnements dans Activités => Suivre les abonnements.

Cette page liste les abonnements actifs dans une liste et les abonnements terminés dans une autre.

Dans tous les listes, vous trouverez un bouton de renouvellement rapide pour chaque abonnement. Cette action va automatiquement changer la date de fin de l’abonnement en ajoutant la durée de l’offre. Si l’offre est pour 12 mois, l’abonnement durera 12 mois supplémentaires.

Notifications de relance

Sur la page d’une offre, il est possible de configurer des dates de relance automatique. Ce sont des emails envoyés aux abonné⋅e⋅s aux dates choisies dans ce formulaire. Comme pour les offres, on choisit une durée (un nombre) et un type de période (mois ou jours).

On peut par exemple ajouter deux relances : 1 mois et 7 jours. Dans ce cas, 1 mois avant la fin, et 7 jours avant la fin, la personne recevra un email l’invitant à renouveler son abonnement.

Il est possible de personnaliser cet email en surchargeant le squelette notifications/abonnement_echeance.html.

Oui mais des abonnements à quoi ?

Comme expliqué précédemment, ce plugin ne gère que le mécanisme central d’abonnement, sans préjuger de ce qui se passe lorsqu’on est abonné⋅e.

Actuellement il existe un premier plugin qui active l’autorisation de voir des contenus restreints lorsqu’on a un abonnement valide : Abonnements à des zones restreintes.

updated on 11 April 2020

Discussion

12 discussions

  • 12

    Bonjour,

    Je teste ce plugin avant mise en production.

    (tests faits avec spip 3.2.4 plugin 3.3.6)

    Je n’arrive pas à avoir de désactivation automatique (par le cron) à l’échéance.
    Ceci parce que objet_modifier se voit refuser l’autorisation par
    autoriser_abonnement_modifier_dist.

    Avec des traces dans autoriser_abonnement_modifier_dist,
    voilà les arguments (avec dump du $qui et de $opt):

     $qui :
     array(4) {
              ["statut"]=> string(0) ""
              ["id_auteur"]=> int(0)
              ["webmestre"]=> string(3) "non"
              ["restreint"]=> array(0) {
      }
    }
    
    $faire  :modifier
    $type  :abonnement
    $id  :127
    $opt  :array(1) { ["statut"]=> string(7) "inactif" }

    Dans abonnements.log

    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_abonnement_modifier_dist(modifier, abonnement, 127, ) : niet
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_instituer_dist(instituer, abonnement, 127, ) : niet
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser modifier abonnement 127 () ?
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_abonnement_modifier_dist(modifier, abonnement, 127, ) : niet

    C’est refusé parce que id_auteur par le cron est 0 .
    Est-ce un comportement normal ?

    Merci.

    • Pourtant la fonction de désactivation contient parfaitement les exceptions qui disent que ça ne doit pas appeler les autorisations :
      https://git.spip.net/spip-contrib-extensions/abonnements/src/branch/master/inc/abonnements.php#L239

    • Merci Rastapopoulos ,

      Oui, mais c’est en passant par un autre objet_modifier que ça bloque.

      https://git.spip.net/spip-contrib-extensions/abonnements/src/branch/master/abonnements_pipelines.php#L138

      Pour mes tests, je force une date d’échéance pour le jour par l’interface privée; Et j’attends le travail de la cron. Et alors ça passe par cet objet_modifier, qui n’a pas d’exception.

    • Mais cet appel est aussi à la suite de celui de la désactivation, donc bien avec l’exception autour. Sinon je ne vois pas de quel moment tu parles. Là c’est dans le pipeline, mais le pipeline lui-même il est appelé… quand il y a un objet_modifier sur spip_abonnements, et cet appel là, bah c’est lequel ? Si le tout premier appel qui déclenche toute cette suite est bien celui de la désactivation, il y a bien l’exception autour (elle vaut à l’infini tant que que pas rappelé avec false ensuite).

    • Ce n’est par le genie/abonnements_verifier_echeances.php
      que le pipeline est lancé dans mon exemple de test ?
      https://git.spip.net/spip-contrib-e...
      Si c’était le cas , comme il n’a pas d’exception,
      alors l’objet_modifier du pipeline serait aussi sans exception?

    • Ah oui et bien ça dépend, c’est pour ça que je demande :)

      Car le truc par défaut de désactivation c’est pas ça, c’est un job prévu à une date bien précise, et qui lance alors la fonction de désactivation à cette date là. Mais ça c’est pour les abonnements qui ont déjà une date de fin.

      La deuxième méthode c’est quand l’échéance (qui n’est pas la date de fin fin fin) est vraiment trop dépassée (parce qu’un paiement automatique n’est pas arrivé par ex, ce qui arrive mais rarement), et effectivement là il manque à priori quelque chose !

      Quel est ton type d’abonnement là ?

    • L’abonnement pour mon site est le plus simple.
      Donc, la date de fin est la même que la date d’échéance .
      Mon test ne reflète pas le fonctionnement réel, c’est vrai.

    • Bé c’est bizarre alors car tu n’entres pas dans ce cas du coup. Si la date de fin est la même que celle de l’échéance, ce qui est toujours le cas quand il n’y a PAS de renouvellement automatique (quand c’est un abonnement “one shot”, quelque soit la durée), et bien comme je le disais au début, tu as normalement un job précis (et non pas un génie récurent) qui est mis à la même date de fin que l’abonnement, et qui donc se lance à ce moment pour désactiver (en lançant la fonction abonnement_desactiver() qui contient bien les exceptions).

    • Oui, mais pour mon test, je mettais manuellement la date d’échéance à celle du jour, mais tout en laissant la date de fin dans le futur.
      Voilà sans doute l’explication.
      Mais, le plugin doit en réalité bien fonctionner, comme tu l’expliques, pour mon type d’abonnement.

    • Oui mais pour lé vérif d’échéance, c’est bien dans un génie qu’on change la date directement (c’est pas une autre fonction programmée qui se lance plus tard) et ya pas les ecceptions à cet endroit, donc j’ai ajouté merci (3.5.8)

    • Oui, j’ai essayé, ca règle bien le problème. Le merci , c’est surtout à moi de le dire.
      Une question : pourquoi l’objet_modifier de verifier_echeance ne bloquait pas en premier?
      C’était seulement l’objet_modifier du pipeline (qui lui déclenchait bien la vérification d’autorisation) qui se voyait logiquement refusé ?
      Par exemple, si on met les exceptions modifier seulement autour de cet appel objet_modifier dans le pipeline: ça marche aussi (et sans exception dans verifier_echeances)

    • Parce que objet_modifier ne fait pas d’autorisation, par contre quand tu changes la date de fin, ça peut demander le changement du statut, et là ça va alors appeler objet_instituer derrière, et par contre celle là demande une autorisation par défaut (perso j’ai toujours dit que les fonctions d’API unitaires “en bout de chaine” ne devrait jamais appeler d’autorisation du tout, cas on doit pouvoir les utiliser de manière scriptée, etc, ou dans des génies, dans des conditions où ya pas d’utilisateur connecté).

    • Merci pour ces explications. C’est plus cohérent.
      C’est vrai que, en pensant le génie comme partie du système, je n’imaginais pas
      qu’il lui faille demander des autorisations :-)

    Reply to this message

  • 2

    Bonjour,

    Dans les logs j’ai ceci :

    2020-01-27 06:41:20 109.234.161.155 (pid 16729) :Pub:ERREUR: Erreur 1052 de mysql: Column 'id_abonnements_offre' in where clause is ambiguous
    in /abonnements/v3.3.6/genie/abonnements_verifier_notifications.php L55 [sql_allfetsel(),genie_abonnements_verifier_notifications_dist(),queue_start_job(),queue_schedule(),inc_genie_dist(),cron(),action_cron(),traiter_appels_actions(),include()]
    SELECT id_abonnement, nom, email
    FROM `base`.v1_abonnements as a left join `base`.v1_auteurs as u on a.id_auteur=u.id_auteur
    WHERE DATE_FORMAT(date_fin, "%Y-%m-%d") = '2020-02-03'
    	AND id_abonnements_offre = 14
    	AND email is not null

    Comme on peut amélioré pour réduire ce log ?

    merci

    Reply to this message

  • 1

    Bonjour,

    J’utilise le plugin pour gérer des abonnements (Dans l’idée du suivi de personnes ayant accès à mes contenus).
    Je créé un visiteur et le rattache à un abonnement.
    C’est le fait d’être connecté en public qui lui permet de lire les contenus.
    J’ai créé une page reprenant des infos sur son compte (identifiant et mail + formulaire de contact).
    Je voudrais pouvoir insérer des infos sur l’abonnement (date de fin, nom de l’abonnement,...)

    Comment faire ?

    Merci d’avance

    • Et bien comme n’importe quels autres boucles, dans tes squelettes… la table des abonnements, la table des offres… Si tu as “créé une page”, c’est bien que tu crées tes squelettes, donc tu fais pareil que pour n’importe quel autre objet de SPIP. Sans plus de précision je ne vois pas trop quoi répondre de plus :)

    Reply to this message

  • 1

    Bonjour,

    Comment modifier le texte et le design de l’email de notification ?

    Quand je regarde le squelette notifications/abonnement_echeance.html, il ya les variable mais pas le texte. Où puis-je le trouver ?

    Merci pour votre réponse

    Reply to this message

  • Bonjour,

    Comment faire pour que les abonnements soient mis en bout a bout
    quelque soit l’offre choisie ?

    Si on a par exemple une offre1 de 10 euros pour 6 mois pour
    un service (exemple acces a une partie restreinte d’un site)
    et une offre2 de 15 euros pour un an pour le meme service.

    Si un visiteur choisit d’abord de s’abonner pour 6 mois, puis
    ensuite enchaine pour une autre offre de 6 mois, les abonnements sont mis en serie et c’est parfait.
    Mais si apres avoir choisi un offre de 6 mois, il veut avant la fin de ce premier abonnement, enchainer avec une offre2 de 12 mois: alors, ca ne marche plus, car cette premiere offre2 est creee en parallele et demarre le jour ou il s’abonne, ce qui n’a pas de sens dans ce cas. Les 12 mois devraient aussi pouvoir etre ajoutes apres la fin de son abonnement de 6 mois qui est toujours en cours.

    Ce cas est-il prevu ?
    Sinon, y a t’il un workaround?

    Merci

    Reply to this message

  • 1
    Christian Voillemont

    Bonjour,

    Est ce que la comptabilité avec SPIP 3.2.0 sera assurée ?

    Reply to this message

  • 2

    Petit retour d’expérience sur le plugin Abonnements...
    ...avec SPIP v.3.0.20 et Abonnements v3.0.7

    Avec l’aide du plugin Tuto-commerce, j’ai réussi à y voir plus clair sur la façon de mettre en place un site de e-commerce,

    J’ai ainsi joint à Abonnements les plugins suivants :

    -  Panier
    -  Commande
    -  Banque et paiement

    Peux-tu me confirmer que j’ai fait le bon choix ?

    Peetdu

    Ps : Pour la gestion du Panier, j’ai dû écrire un petit script vérifiant l’unicité du panier. En effet, dans le cas où l’internaute veux changer de formule d’abonnement, on se retrouve avec un panier avec deux abonnements. Le script supprime le plus vieil item du panier.

    • Ça dépend de la complexité des abonnements. Moi j’utilise bien le plugin Commandes, mais j’ai développé un formulaire (non générique, propre au projet pour l’instant) de commandes d’abonnements, qui crée tout, l’utilisateur si besoin (car il le faut pour la commande), la commande avec les trucs complexes de prélèvement auto parfois (champs “echeances” et “echeances_type” ya pas d’API pour ça), la transaction liée à la commande, et enfin je garde tout ça en mémoire pour afficher le bon formulaire de paiement après validation…
      (Je t’ai envoyé un exemple par mail.)

      Après il faudrait réussir à faire un truc plus générique. Sûrement possible comme tu l’expliques là, pour les cas simples et classiques. Pour les trucs plus complexes comme ce que j’ai eu à faire (enfin j’ai l’impression), là j’ai pas encore de solution toute faite.

    • Spidermian

      bonjour,
      Je suis en train de me dépatouiller sur Spip 3.1 avec le plugin Abonnement, le plugin Bank le plugin Commandes et je serais aussi intéressé de visionner ton exemple de formulaire qui fait tout, ce qui m’aiderait surement à y voir plus clair...

    Reply to this message

  • 3

    Bonjour,

    D’abord merci pour vos contributions qui me permettent d’être toujours accro à Spip sans être experte !

    J’essaie de comprendre : pour un site d’information en ligne avec une partie accessible en abonnement, j’ai mis en place “accès restreint” + “accès restreint partiel”, puis “abonnements” + “abonnements à des zones restreintes”, et enfin un formulaire d’inscription en tant que visiteur.

    Jusqu’ici tout fonctionne bien, et l’administrateur peut abonner un visiteur. Mais je voudrais que le visiteur puisse s’abonner tout seul en sélectionnant une offre. Comme Jacangers, je bloque un peu sur l’absence de squelette, je précise que je ne maîtrise pas le php ni vraiment les boucles Spip, seulement le html et css…

    – Comment je peux faire ça, dans un premier temps en considérant que l’offre est gratuite ? Donc comment proposer à un visiteur de s’abonner à une offre ou de voir la liste des offres pour s’abonner à celle de son choix ?

    – Et si l’offre est payante, j’imagine que là ça se complique, et qu’il faudra coupler avec les plugins “panier”, “commande” et “banque et paiement” dont vous parlez plus haut avec Peetdu ?

    J’espère vraiment pouvoir répondre à ce type de projet avec Spip, est-ce pertinent, et pouvez-vous m’aider ?

    Bien cordialement,
    Karen

    • Bonjour,
      Je suis dans la même situation que Karen. Je voudrais bien qu’à l’issue de la validation de la transaction, l’abonnement puisse être généré automatiquement.
      En fouillant un peu, je suis tombé au niveau du code source sur une fonction nommée abonnements_creer_ou_renouveler https://zone.spip.org/trac/spip-zone/changeset/90516/
      Quelqu’un pourrait-il me dire comment utiliser cette fonction depuis le site public lorsqu’une transaction est validée ?
      Merci à vous.

    • Bonjour,

      Tu devrais regarder le plugin https://plugins.spip.net/tutocommerce.html.
      Cela ma grandement aidé à comprendre comment mettre en place ma solution d’abonnement en ligne. Et, dans mon souvenir, il y a en partie réponse à tes questions.

    • @ludo mais au moins pour cette partie là il n’y a rien à coder, tout est déjà fait. La partie à coder actuellement c’est le fait de créer une commande avec une offre d’abonnement dedans. Mais une fois que cette partie est ok chez toi, pour la suite c’est déjà tout automatique : quand une transaction est validée, ça met la commande liée en “payée” (ça c’est Commandes qui reconnait Bank), et quand une commande est payée et qu’elle contient au moins une Offre d’abonnement, alors ça génère l’abonnement automatiquement pour l’utilisateur de la commande, tu n’as absolument pas à le créer toi-même en appelant les fonctions.

    Reply to this message

  • 1

    bonjour,
    avec le plugin “abonnements” en version 3.1.7, si je clique sur “désinstaller” : la table “spip_abonnements_offres_notifications” qui a été créée lors de l’installation n’est pas supprimée. C’est une erreur ou bien c’est volontaire ?

    Reply to this message

  • 3

    Hello,

    j’utilise de nouveau avec bonheur ce plugin.

    Je ne suis pas sûr de comprendre la différence entre les dates de “Prochaine échéance” et “Fin de l’abonnement”.

    Peux-tu m’éclairer ?

    Merci

    • C’est depuis qu’il PEUT (pas obligatoire) avoir des prélèvements automatiques depuis des commandes liées à des renouvellements auto.

      La prochaine échéance, c’est quand on est censé avoir un paiement pour la période suivante. C’est un prévision.

      La fin de l’abonnement, c’est VRAIMENT la fin de l’abonnement, là où il va être désactivé.

      Par défaut les deux sont pareils. Si t’arrives à la prochaine échéance et que tu ne payes pas sous 48h (délai par défaut personnalisable), bah ça coupe.

      Mais si t’as un abonnement qui a été payé avec un renouvellement auto de ta banque par carte bleue : la fin de l’abonnement c’est la date de validité de ta carte bleue. Ça te coupera pas sous 48h, car des fois les banques mettent plus de temps à envoyer le “ping” pour dire que le renouvellement a été fait.

      Et si t’as payé avec une autorisation de prélèvement SEPA : la fin de l’abonnement est nulle, elle n’existe pas, car là ya même pas de date de fin de validité.

    • Ok. Merci pour cet éclaircissement.

      Une dernière question : en regardant le code, il me semble que les notifications sont basées sur la date “Fin de l’abonnement”. Tu confirmes ?

      encore merci
      Peetdu

    • Oui, et du coup théoriquement, si t’as des renouvellements automatique ça va PAS t’envoyer de notifications lors de l’échéance de la période qui arrive, seulement tout à la vraie fin de l’abonnement. Sachant que normalement, si tu payes en carte bleue ça met la fin de l’abonnement à la fin de validité de la carte, et si tu payes en prélèvement SEPA ça met aucune date de fin, c’est infini.

    Reply to this message

Ajouter un commentaire

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom