Le développement de cette version a coûté 4 250 euros. Le coût de la première version était de 38 000 euros. Le coût cumulé depuis la première version est de 46 610 euros, mais le coût pour vous est seulement la licence à partir de 80€.
Nouvelle branche 3.0.x du plugin Abonnements Avancés pour WooCommerce. C'est une version majeure : elle introduit les options d'achat sur la fiche produit (« Achat unique » ou « Abonnez-vous et économisez »), la remise optionnelle Abonnez-vous et économisez avec des règles propres, la traduction complète en français et la possibilité pour le client de changer la quantité et la fréquence de son abonnement depuis Mon compte. De plus, elle apporte un audit de sécurité complet et une longue liste de corrections sur les renouvellements, les changements de plan, les remises et les passerelles de paiement.
Versions de la branche
3.0.0
Important :
- Mise à jour recommandée pour toutes les boutiques : inclut des corrections de sécurité et de paiements dans les passerelles incluses, dans Mon compte et dans les renouvellements.
- Le sélecteur « Achat unique / Abonnement » qui apparaissait sous le prix disparaît et est remplacé par le nouveau widget d'options d'achat. Si votre thème ou un extrait de code en dépendait, vérifiez-le avant de mettre à jour.
- Le module de date de début personnalisée (Custom Start Date) est désactivé dans la 3.0.0 et sa section de réglages ne s'affiche pas, même dans les boutiques qui l'avaient activé : il affichait la date choisie, mais l'abonnement commençait et était facturé immédiatement. Il reviendra, terminé, dans une version ultérieure.
- L'email de rappel de renouvellement est désactivé par défaut. Si vous l'aviez enregistré comme activé, il sera désactivé une fois la mise à jour effectuée pour que vos clients ne reçoivent pas d'emails par surprise ; vous pouvez le réactiver quand vous le souhaitez.
- Lors de la mise à jour, les abonnements qui étaient restés en « En attente d'annulation » sont annulés à leur prochaine date de paiement, ou dans les douze heures suivantes si cette date est déjà passée. Vous recevrez alors leurs emails d'annulation.
- Lors de la mise à jour, les abonnements actifs avec la date du prochain paiement dans le passé et rien de programmé passent à être facturés à la prochaine date de leur cycle. La période échue n'est pas facturée et une note est laissée sur l'abonnement.
Nouveau :
- Options d'achat sur la fiche produit : « Achat unique » ou « Abonnez-vous et économisez », comme un groupe d'options natif et gérable au clavier, avec l'économie mise en avant dans une étiquette. Fonctionne sur des produits simples et variables (par variation) et sur des thèmes classiques et de blocs. L'option pré-sélectionnée est choisie dans les réglages.
- Abonnez-vous et économisez (désactivé par défaut ; rien ne change jusqu'à ce que vous l'activiez) : le prix de l'abonnement est le prix normal du produit moins un pourcentage (de 1 % à 50 %), qui peut provenir d'un réglage du produit ou de la variation, de la première règle qui correspond ou du réglage global. Vous pouvez également déduire la première commande et limiter le nombre de commandes avec remise. Tout est enregistré dans l'abonnement lors de l'inscription, donc changer les réglages plus tard ne change jamais son prix.
- Nouvelle interface WooCommerce › Abonnez-vous et économisez avec des règles ordonnées par conditions (prix au-dessus ou en dessous d'un montant, catégorie, étiquette ou produits spécifiques). La première règle qui correspond l'emporte. Les règles peuvent être montées, descendues, glissées pour les réorganiser et supprimées en deux étapes.
- Le client peut choisir la fréquence de livraison dans les périodes et limites que permet la boutique, sauf si le produit la bloque.
- Dans le panier classique, chaque ligne qui l'admet peut être changée entre achat unique et abonnement, avec sa fréquence. Les totaux du panier et du paiement (classiques et de blocs) affichent une ligne avec l'économie d'Abonnez-vous et économisez.
- Dans Mon compte, le client peut changer la quantité et la fréquence de son abonnement. Le changement s'applique à partir du prochain renouvellement, avec un aperçu du nouveau montant et de la nouvelle date.
- Chaque ligne d'un produit qui offre les deux options affiche « Achat : achat unique » ou « Achat : abonnement », avec ses conditions, dans le panier, le paiement (classique et de blocs), la commande, Mon compte, la confirmation de commande et les emails. Un abonnement de N unités est créé et renouvelé pour N unités.
- Les tranches de remise de renouvellement peuvent s'ajouter à la remise d'Abonnez-vous et économisez ou s'appliquer après elle : d'abord Abonnez-vous et économisez tant que cela dure, puis les tranches (c'est un réglage). Un changement de plan prend les tranches du nouveau produit.
- Traduction en français (fr_FR) incluse : tout le plugin, avec les passerelles incluses de Redsys, Bizum, Google Pay et Inespay. Une boutique en français n'affiche plus de textes en anglais lors du paiement, dans Mon compte, dans les emails ni dans les réglages.
- Lors de la mise à jour, les abonnements qui se renouvellent avec un cycle différent de celui de leur produit apparaissent dans un avis d'administration avec le bouton « Aligner avec le produit » pour les aligner.
Corrigé :
- Les traductions incluses dans le dossier
languages/du plugin se chargent vraiment. Dans WordPress 6.7 et versions ultérieures, elles étaient recherchées dans un dossier qui n'existe pas, donc seules celles installées danswp-content/languages/plugins/. - Un abonnement annulé par le client dans Mon compte, ou par la boutique depuis l'administration, se termine maintenant vraiment. S'il n'avait pas de date de fin, il restait pour toujours en « En attente d'annulation » : il n'était jamais annulé, l'email d'abonnement annulé ne partait pas et une boutique qui donne accès selon l'état de l'abonnement continuait à le faire. Maintenant, il est annulé à la fin de la période déjà payée. Nouveau filtre
aswc_prepaid_term_end. - Une nouvelle tentative de paiement facture chaque période au maximum une fois. Avec un paiement en attente, ou avec un qui a expiré après que la banque l'ait approuvé, la nouvelle tentative pouvait créer et facturer un deuxième renouvellement de la même période.
- Lorsqu'une nouvelle tentative paie un renouvellement échoué avec une nouvelle commande de renouvellement, le client ne peut plus non plus payer la commande échouée (dans le paiement, dans Mon compte ou avec l'action d'administration « Réessayer le paiement de la commande en attente »). S'il y avait déjà un paiement en cours lorsque la nouvelle tentative a été exécutée, il est marqué dans les deux commandes pour que vous décidiez du remboursement.
- Deux exécutions de renouvellement simultanées pour le même abonnement (plusieurs lots d'Action Scheduler, ou un exécuteur de WP-CLI avec WP-Cron) ne peuvent plus le facturer toutes les deux.
- Stripe : un renouvellement dont la réponse est perdue (un délai d'attente dépassé, un serveur qui s'arrête au milieu de la demande, une erreur de proxy) n'est plus marqué comme échoué, ce qui le laissait payable et permettait qu'une nouvelle tentative facture la période deux fois. Maintenant, il reste en attente avec une note dans la commande, n'est pas facturé entre-temps et est consulté dans Stripe une heure plus tard : il est complété si le paiement a été effectué et passe aux nouvelles tentatives normales si ce n'est pas le cas.
- Stripe : tant qu'un renouvellement est retenu en attente de confirmation de son paiement, réactiver l'abonnement ne permet plus à la prochaine exécution de créer et de facturer un autre renouvellement de la même période. La rétention est également notée dans l'abonnement.
- Stripe : un avis tardif de « paiement échoué » ne fait plus échouer un renouvellement qui est déjà payé. Stripe et PayPal : un renouvellement ne remet plus la carte que le client avait remplacée.
- PayPal : lorsque PayPal ne répond pas (délai d'attente dépassé, erreur de connexion ou erreur de serveur), le renouvellement est retenu pour que vous le vérifiiez, au lieu d'être marqué comme échoué et réessayé, ce qui pouvait le facturer deux fois.
- PayPal et WooPayments : un renouvellement ne reste jamais payable lorsque le plugin de paiement échoue avec une erreur interne après avoir envoyé le paiement. Ceux de PayPal restent retenus pour que vous les vérifiiez et ceux de WooPayments sont conciliés. Avant, une nouvelle tentative pouvait les facturer une seconde fois.
- Un abonnement sans un cycle de facturation valide ne se renouvelle plus chaque jour : il prend le cycle de son produit ou est mis en attente et n'est jamais facturé. Il n'est pas non plus facturé par une nouvelle tentative de paiement ni par les actions manuelles de la boutique (Créer une commande de renouvellement en attente, Réessayer le paiement de la commande en attente et Réessayer le paiement de renouvellement), qui maintenant le rejettent avec une note.
- Lors de la mise à jour vers la 3.0.0, les abonnements sans cycle de facturation prennent celui de leur produit.
- L'intervalle de facturation d'un produit d'abonnement, et celui de chaque variation, n'est plus pré-sélectionné en « Jours » : il faut le choisir, sinon le produit n'est pas enregistré comme abonnement.
- Le « Paiement » et la « Période de facturation » d'un abonnement existant sont enregistrés depuis sa boîte de programmation, et un cycle vide n'est plus affiché comme « Jours ».
- Les vérifications du cycle de facturation acceptent des périodes ajoutées par d'autres plugins, ne modifient jamais un abonnement juste pour l'afficher et envoient à la boutique au maximum un email par jour sur les abonnements sans cycle.
- Un abonnement avec période d'essai se renouvelle le jour où l'essai se termine, pas le jour où il a été acheté (le deuxième paiement arrivait moins d'un mois après le premier).
- Un nouvel abonnement est daté au moment réel de sa création. Sa date de création était l'heure locale du magasin enregistrée comme UTC, donc dans un magasin à l'est de l'UTC, elle apparaissait plus tard que la réalité (deux heures en Espagne en été) et les nouveaux abonnements étaient classés sous d'autres plus anciens. Les abonnements créés avant la 3.0.0 conservent leur date.
- Une commande de renouvellement payée par le client est enregistrée : un renouvellement échoué payé sur la page de paiement de la commande, ou un renouvellement manuel, déplace maintenant la date du prochain paiement d'un intervalle et programme ce paiement. Auparavant, l'abonnement redevenait actif sans rien de programmé et ne se renouvelait plus jamais.
- Un renouvellement sans rien à payer (un coupon récurrent de 100 %) est enregistré comme n'importe quel autre : l'abonnement reste actif et son prochain renouvellement est programmé.
- La vérification quotidienne de la programmation restaure l'action de paiement manquante dans les magasins avec un stockage de commandes haute performance (HPOS). Elle recherchait les abonnements uniquement parmi les entrées et n'en trouvait aucun.
- Un abonnement ou une commande annulée, remboursée ou expirée après avoir programmé sa date de début n'est plus activé lorsque cette date arrive.
- Un abonnement supprimé, annulé par un administrateur ou remboursé pendant qu'un renouvellement échoué attend sa nouvelle tentative ne maintient plus cette nouvelle tentative programmée.
- Réactiver un abonnement suspendu dans Mon compte ne programme plus une nouvelle tentative de paiement.
- Un remboursement total de la première commande d'un abonnement l'annule à nouveau. Le magasin traitait cette première commande comme un renouvellement, donc un client remboursé restait abonné et était facturé lors du prochain renouvellement.
- Les tranches de remise de renouvellement s'appliquent à tous les renouvellements pour lesquels elles ont été configurées : le compteur de renouvellements payés n'avançait jamais, donc une tranche commençant au deuxième renouvellement ou plus tard ne s'appliquait jamais. Maintenant, chaque renouvellement payé compte une fois, et un renouvellement remboursé continue de compter.
- Modifier les tranches de remise de renouvellement d'un produit ne change plus le prix des abonnements existants. Les tranches sont enregistrées au début de l'abonnement et sont maintenues telles qu'elles ont été vendues, y compris celles des coupons.
- Les tranches de remise de renouvellement configurées dans un coupon, et les tranches par rôle de client, s'appliquent maintenant aux renouvellements. Elles étaient enregistrées, mais jamais utilisées. Celles d'un coupon s'appliquent également à un produit sans tranches propres, même si « Override Product Discounts » est décoché.
- Le paiement ne se termine plus par une erreur fatale lorsque le produit a des tranches de remise de renouvellement.
- La remise du premier paiement s'applique une seule fois et uniquement au premier paiement. Elle s'appliquait deux fois et était reportée à tous les renouvellements. Elle ne s'applique pas à une période d'essai ni à un changement de plan.
- Un produit avec une remise sur le premier paiement affiche lors du paiement son prix réel de renouvellement. Les deux checkouts affichaient le premier paiement avec remise comme prix de tous les renouvellements, bien que les renouvellements soient facturés au prix plein.
- Un produit avec une période d'essai acheté avec un coupon récurrent se renouvelle à son prix avec remise. Il était enregistré avec un montant de renouvellement de 0 et se renouvelait gratuitement.
- Les frais d'inscription sont facturés une fois par abonnement, quelle que soit la quantité. Un abonnement acheté avec une quantité de 3 payait les frais trois fois.
- Avec les prix introduits avec taxes incluses, le total récurrent de l'abonnement est enregistré arrondi aux décimales du magasin.
- Changements de plan : le changement est facturé à la date du prochain paiement affiché par l'abonnement, et la nouvelle date est comptée à partir du changement (auparavant, une amélioration offrait une période entière). Un changement ne donne jamais droit à la période d'essai du nouveau produit ; le crédit de la période non utilisée est ce qui a réellement été payé pour cela ; une seconde ligne de changement pour le même abonnement est rejetée et une commande de changement confirmée deux fois à la fois s'applique une seule fois.
- Changements de plan avec prorata : le crédit de l'abonnement précédent s'applique une fois par ligne, pas une fois par unité.
- Un changement de plan vers une variation qui prend la période de facturation du produit variable est reconnu pour ce qu'il est. Auparavant, il était toujours traité comme une baisse de plan, quel que soit le prix.
- Une baisse de plan vers une variation qui hérite de l'intervalle de son produit parent reçoit son crédit. Elle était calculée comme infinie et n'était jamais appliquée.
- Un changement de plan maintient la facturation d'un abonnement sans date de fin lorsque son crédit est ajouté comme jours, commence la nouvelle période le jour du changement et conserve les tranches de remise d'un coupon d'inscription.
- « Stop Downgrade » et « Allow switching only to the same interval » sont désactivés sauf si vous les cochez. Une fois les paramètres enregistrés, ils étaient lus comme activés et toutes les baisses de plan et tous les changements entre intervalles étaient rejetés.
- Jour de renouvellement synchronisé : le premier renouvellement mensuel est le jour de ce mois s'il n'est pas encore passé ; tous les renouvellements restent ce jour-là ; la fiche produit annonce la date qui est facturée ; « Dernier jour du mois » renouvelle le dernier jour de chaque mois, et un site à l'est de l'UTC ne fait plus avancer d'un jour le premier renouvellement à la fin de sa journée.
- « Laissez le client choisir l'expiration » dans un abonnement variable : le champ d'expiration propose la période de facturation du produit (auparavant, il tombait dans « Jours ») et rejette une expiration plus courte que l'intervalle de facturation. La même chose s'applique à un abonnement créé à partir d'une vente additionnelle de CartFlows.
- La limite d'annulations de périodes d'essai d'un produit s'applique : après le nombre indiqué d'essais annulés, le client ne peut plus annuler le suivant.
- Le bloc de Paiement affiche dans le résumé de la commande la période de facturation (« / 1 mois »), comme le faisait déjà le bloc de Panier.
- Les chiffres de renouvellement du bloc de Paiement suivent le panier : après un coupon ou un changement de quantité ou d'expédition, ils ne conservent plus les montants précédents jusqu'à ce que la page soit rechargée.
- Bloc de Paiement : le premier prélèvement d'un essai gratuit (les frais d'inscription, ou rien) n'apparaît plus comme une offre. La ligne montre ce qui est facturé maintenant, l'essai et le prix de renouvellement.
- Un produit variable qui mélange des variations d'abonnement et d'achat unique ne montre plus sa fourchette de prix avec une période de facturation, ce qui présentait le prix d'achat unique comme mensuel. Nouvelle fonction auxiliaire et filtre.
aswc_variable_product_has_one_time_variation(). - L'icône de carte de Redsys (et les icônes par défaut des autres passerelles incluses) ne remplit plus toute la boîte de paiement dans le checkout classique avec un thème de blocs. Votre propre logo n'est pas touché.
- Passerelle Redsys incluse : un renouvellement facturé avec la carte enregistrée ne la sauvegarde plus à nouveau. Chaque renouvellement ajoutait une autre carte identique au compte du client. Lors de la mise à jour, les doublons enregistrés par les versions précédentes sont supprimés, conservant celle utilisée pour les renouvellements.
- Redsys : un renouvellement prélève la carte enregistrée la plus récente du client, pas la plus ancienne, et une carte déjà enregistrée n'est jamais enregistrée à nouveau chez les clients ayant plus de dix cartes.
- Une annulation dans Redsys, Bizum ou Google Pay annule la commande dans le magasin. Auparavant, elle restait en attente.
- Les paiements par contre-remboursement, virement ou chèque, et les abonnements manuels, envoient au client la facture de renouvellement avec le lien pour la payer. Auparavant, le client ne savait rien jusqu'à ce que le magasin utilise « Retry Renewal Payment ». Nouveau filtre.
aswc_send_manual_renewal_invoice. - « Retry Renewal Payment » est de nouveau proposé dans une commande de renouvellement en attente, et l'e-mail que reçoit le magasin concernant un renouvellement échoué indique qu'il s'agit d'un renouvellement et nomme son abonnement.
- Le magasin reçoit une seule fois l'e-mail d'un renouvellement échoué. Le plugin envoyait sa propre copie avec celle de WooCommerce.
- L'e-mail de rappel de renouvellement est envoyé avant le renouvellement lorsque le magasin l'active. Il était programmé et n'était jamais envoyé.
- L'e-mail « Subscription on hold to active » est envoyé lorsque le magasin réactive un abonnement en attente depuis son écran d'édition.
- L'objet par défaut de cinq e-mails (annulé, expiré, en attente, suspendu et réactivé) écrivait mal « Subscription ».
- Les liens de l'administration vers l'écran des abonnements fonctionnent à nouveau : le lien des paramètres du plugin, celui de l'abonnement dans les notes de commande, le retour après avoir suspendu, réactivé ou annulé, « Go Back » et l'exportation CSV se terminaient par « Désolé, vous n'avez pas la permission d'accéder à cette page ».
- La corbeille de la liste des abonnements propose « Restaurer » et « Supprimer définitivement », pour restaurer ou supprimer un abonnement spécifique.
- Le chemin REST
aswc-view-subscriptionrenvoie les abonnements. Il filtrait par une clé de métadonnées sans son trait de soulignement et ne renvoyait aucun. - Un bug JavaScript disparaît sur les pages de panier et de paiement classiques : le script des blocs s'exécutait là où il n'y a pas de blocs.
- WordPress 6.7 et versions ultérieures ne signalent plus l'avertissement « translation loading was triggered too early » à chaque demande. Deux avertissements PHP disparaissent également dans le magasin et sur l'écran d'édition de produit.
- Le modèle de traduction (.pot) couvre à nouveau tous les textes : environ 360 ne pouvaient pas être traduits, y compris l'e-mail HTML de facture de renouvellement.
- Accessibilité : tous les champs du panneau d'abonnement du produit (simple, multiproduit et par variation) ont maintenant un nom qui annonce le lecteur d'écran.
- Enregistrer un abonnement au début d'une demande d'administration (par exemple, depuis admin-ajax ou admin-post) ne se termine plus par une erreur fatale.
- Désinstaller le plugin supprime également ses données transitoires.
Sécurité :
- Redsys, Bizum et Google Pay n'acceptent le résultat d'un paiement que lorsque sa signature est valide. Un retour falsifié au magasin pouvait marquer une commande comme payée.
- Les notifications de paiement d'Inespay sont authentifiées. Une notification dont le montant signé ne correspond pas à la commande est mise en attente, et une notification répétée pour une commande déjà payée est ignorée.
- Les liens d'administration pour mettre en pause et réactiver un abonnement nécessitent une autorisation pour modifier les commandes, un lien valide et l'état attendu. Une réactivation pouvait être déclenchée sans être connecté.
- Les vérifications de licence et de mises à jour vérifient toujours le certificat du serveur, et un paquet de mise à jour n'est accepté que s'il provient du serveur de licences par https.
- Dans Mon compte, les détails d'un abonnement, sa liste de renouvellements et son changement de méthode de paiement (y compris Stripe) ne sont disponibles que pour le client auquel ils appartiennent.
- Les actions du client pour mettre en pause, réactiver et annuler sont décidées à partir de l'état enregistré de l'abonnement et des paramètres de la boutique, donc il n'est plus possible de contourner le délai minimum ni la limite d'annulations d'essai. Un lien affiché avant la mise à jour échoue une fois ; en rechargeant la page, un lien fonctionnel apparaît.
- La date de début envoyée par un client n'est acceptée que si elle fait partie de celles proposées par le produit.
- Le bloc de Paiement crée toujours l'abonnement lorsque le panier le contient ; un paramètre de la demande pouvait le contourner.
- Un changement de plan ne donne un crédit que pour un abonnement propre et actif du client, et chaque crédit est dépensé une seule fois. Une période remboursée ne génère pas de crédit.
- Renforts de l'audit de sécurité de la 3.0.0 : les routines de mise à jour et la configuration du coffre-fort de PayPal ne s'exécutent que pour les administrateurs ; l'action massive de date de début personnalisée vérifie l'utilisateur et la demande ; une action de fin de période ne termine que les abonnements qui attendent de se terminer ; le restaurateur de la programmation ne réessaie jamais les retenues décidées par la boutique, et les passerelles Redsys incluses n'écrivent plus la clé de signature dans le journal de débogage.
- L'onglet des remises du produit et les champs de remise de chaque variation ne sont enregistrés que pour un utilisateur qui peut éditer ce produit (défense en profondeur).
Développement :
- Le sélecteur « Achat unique / Abonnement » qui était imprimé sous le prix a été supprimé ; il est remplacé par le nouveau widget. L'action AJAX
aswc_onetime_purchasereste enregistrée comme obsolète et ne fait rien (elle est enregistrée dans le journal au maximum une fois par jour avecWP_DEBUG). Consultezdocs/reference/hooks-and-extension-points.md. - Il est supprimé
ASWC_Admin::aswc_admin_reactivate_onhold_subscription()et son hook deinit: c'était le gestionnaire d'un lien que aucun écran ne montrait. - Nouveaux filtres :
aswc_prepaid_term_end,aswc_send_manual_renewal_invoiceetaswc_variable_product_has_one_time_variation.
Compatibilité :
- Testé jusqu'à WordPress 7.1 et WooCommerce 11.1.0.
- Nécessite WordPress 6.5 ou supérieur, WooCommerce 8.0 ou supérieur et PHP 7.4 ou supérieur.
- Entièrement compatible avec le stockage de commandes haute performance de WooCommerce (HPOS) et avec les blocs de Panier et Paiement.
- Continue de fonctionner de manière autonome, sans dépendre de l'extension WooCommerce Subscriptions.







