Leaderboard

🎉 Now with Subscriptions & Webhooks! (v 1.0.8) In the past months, several frameless clients asked for an easy way to sell their content as subscriptions — without manually managing access. Think of a coach publishing daily audio files and offering a weekly subscription for them. That’s exactly what this update makes possible. 💡 🆕 What’s new in 1.0.8 Stripe Webhook support The module now listens at /stripepaymentlinks/api/stripe-webhook and reacts in real-time to subscription events — cancel, pause, resume, renew, or failed payment. → Access updates instantly. No cron jobs, no manual actions. Subscription handling Each purchase now stores a period_end_map, so the module knows exactly when access should expire. Pause or cancel a subscription → access is blocked immediately. Resume or renew → access restored automatically. Smarter access logic hasActiveAccess() now distinguishes between: recurring products (time-limited access) one-time purchases (lifetime access) Config update Added a field for the Webhook Signing Secret in module settings. ⚙️ Setup (2 min) In Stripe → Developers → Webhooks → Add endpoint https://yourdomain.com/stripepaymentlinks/api/stripe-webhook Choose either “All events” or only the relevant ones: customer.subscription.updated customer.subscription.deleted customer.subscription.paused customer.subscription.resumed invoice.payment_succeeded invoice.payment_failed Copy your Signing Secret into the module config. Done ✅ — test by pausing, resuming or cancelling a subscription and watch access update live. Short, clean, and 100 % ProcessWire-native. Perfect for creators, coaches, and anyone who wants to sell recurring access without maintaining users manually. Cheers, Mike

@BFD Calendar Btw, I did try to access your site, and am getting an HTTPS error. So I think whatever your webhost restored might have broken the HTTPS setup. Chances are your webhost can fix that by checking a box somewhere, or if you have cPanel or something you might be able to do it from there. Once I proceeded without HTTPS, then I got ProcessWire's "internal server error" message, which means that ProcessWire found and logged an error to /site/assets/logs/errors.txt. So the source of the issue is likely identified in that log file.

Last week I was on a boat, far from any computer, so that’s why there weren’t any updates. This week I’m back in the office and back to work on the core. The focus has been primarily on optimizations and issue fixes (see dev branch commit log). There were also a couple commits related to PHP 8.4 support. Issue fixes and optimizations will likely continue to get more focus as we get closer to our next main/master version.There are also some Pro module updates in the works as well. Have a great weekend!

Good luck to the Craft team, but to me it looks like they need to reinvent the wheel every now and then. Luckily, we have our own genius, Ryan, who figured that reinventing the wheel is not for everyone. At least not for us ;)

I'm no longer maintaining any of my modules. If someone wants to take them over, let me know. It's been a long time since I first asked, but nobody has reached out.

@Jonathan Lahijani - not sure if this is what you are looking for, but all Tracy's settings can be overridden in config.php like: $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ]; Not sure if those are the exact options you want, but hopefully that approach works for you.

Deprecation warnings say, that it potentially may not be ready for 8.4.2 or 8.4.3 or any other further version. But in my understanding, it is ready for PHP 8.4.0 and 8.4.1. 🙂 If the deprecation warnings bother you, you can disable showing only those messages with a call of PHPs set_error_handler(): /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { return true; // true | false = suppress further processing } // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ I often use this directly in site/config-dev.php, when I want to collect them, but only show them collected at the end of pages in dev local. /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { // CHECK / CREATE COLLECTION CONTAINER if (!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if (!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } // DO NOT SHOW THIS KNOWN THIRD PARTY ONES : $hideThisOnes = [ //'FileCompiler', 'Duplicator', 'ProcessCustomUploadNames', ]; foreach($hideThisOnes as $item) { if (preg_match("/{$item}/", $errfile)) return true; } // ADD IT TO THE COLLECTION $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/

Hay Ryan.. I can confirm that it is a issue with PHP 5.3/4 and 5.2 Keep it up.. Im still in love...