Leaderboard

I’ve been working on a module to store ProcessWire files directly on Backblaze B2, and wanted to share it with the community. Why I Built This I needed to host video content without breaking the bank on storage costs. AWS S3 was too expensive, and I wanted something that integrates seamlessly with ProcessWire’s existing file fields. Key Features 🚀 Direct B2 Upload - Files go straight to Backblaze, no local storage needed 💰 Dirt Cheap - $6/TB/month (AWS S3 costs 5x more) 🌐 Custom Domain Support - Use your own CDN domain ⚡ Cloudflare Integration - Combine with Cloudflare for FREE bandwidth 📦 Works with Repeaters - Multiple files per repeater item 🎬 Perfect for Video - Tested with Plyr, Video.js, and HTML5 video Real Cost Savings Here’s what I’m actually paying for 500GB of video storage: Backblaze B2 + Cloudflare: - Storage: $3/month - Bandwidth: $0 (free via Cloudflare Bandwidth Alliance) - Total: $3/month AWS S3 (same usage): - Storage: $11.50/month - Bandwidth: $450/month (5TB) - Total: $461.50/month That’s a 99% savings on bandwidth costs! How It Works The module extends ProcessWire’s file fields to upload directly to Backblaze B2. You can use it just like regular file fields: // Single video <video controls> <source src="<?= $page->b2_video->url ?>" type="video/mp4"> </video> // Multiple videos in repeater <?php foreach($page->videos as $item): ?> <?php foreach($item->b2_video as $video): ?> <video controls> <source src="<?= $video->b2url ?>" type="video/mp4"> </video> <?php endforeach; ?> <?php endforeach; ?> Cloudflare CDN Integration Want free bandwidth? Here’s the magic setup: CNAME: cdn.yourdomain.com → f005.backblazeb2.com (with Cloudflare proxy) Transform Rule: Rewrite paths to include /file/bucket-name/ Module setting: Enable custom domain Now all files serve through Cloudflare’s global CDN with zero bandwidth costs thanks to the Bandwidth Alliance partnership. Setup is Simple Create Backblaze B2 bucket Configure module with API keys Create field (type: FieldtypeFileB2) Add field to template Upload files - they go straight to B2! Optional: Add Cloudflare for free bandwidth and caching. Use Cases Video hosting (my use case) Large image galleries Audio files / podcasts Downloadable resources Any high-bandwidth file hosting Technical Details Works with public and private buckets Supports custom Cache-Control headers Files are deleted from local server after upload Can use custom domains via Cloudflare CORS configurable for cross-domain access Try It Out GitHub: https://github.com/mxmsmnv/FieldtypeFileB2

Hey everyone! After the StripePaymentLinks module has been running smoothly, a few customers with multiple Stripe accounts asked for better analytics capabilities. The Stripe dashboard is okay, but when you have multiple accounts and need specific analysis, it quickly becomes tedious. StripePlAdmin is an admin interface that displays the data stored by StripePaymentLinks in three perspectives: Purchases: All transactions with customer details, subscription status, renewals Products: Aggregated product performance (revenue, purchases, quantities) Customers: Customer lifetime value, purchase behavior Features: Configurable columns per tab Dynamic filters (Boolean search, date ranges, number ranges) Clickable product/customer names open detail modals CSV export with active filters Summary totals at table footer You can show/hide columns and filters in the module settings as needed. Everything is very flexible. Available on GitHub and in the Modules directory. Feedback welcome! 🚀 Cheers, Mike

There is a module in development: https://processwire.com/talk/topic/31052-xforum-proof-of-concept-front-end-forum/ I tested it a while ago, and it worked fine. You only have to customize the styling to your needs.

No unfortunately not. I wrote a new module WireMailBrevo that uses the API to connect instead. https://processwire.com/modules/wire-mail-brevo/

Whether or not the system is built on top of a framework is, in my opinion, largely irrelevant. Or perhaps it would be better to say that "it is impossible to guess if and how it would've mattered in the big picture". Call me cynical, but dependencies are never free. Each adds weight to the codebase, requires upkeep and maintenance (sometimes including major updates or rewrites), and increases potential attack surface. Also many dependencies — and especially frameworks — bring in their own way of doing things, and since ProcessWire's architecture (hooks, data structure, etc.) is really a major selling point for the system, using a framework could've had a massive impact on that. Part of the reason why ProcessWire is such a brilliant system could very well be due to it not being powered by a framework itself. This means that every decision could be made without considering how that would fit the framework. What is also interesting, in my openiin, is the framework landscape itself. Back when ProcessWire 2.0 was launched, Laravel — now considered the latest state of the art PHP framework — wasn't even around yet. Zend Framework was probably the biggest name back then, or at least the one that most serious developers considered "most likely to thrive and stay around"... yet it was discontinued. Had ProcessWire gone with the "safe bet", that would've meant a big rewrite later, or alternatively staying on a platform that is merely a shadow of its former glory. Long story short, I think Ryan made a good choice ? Don't get me wrong, though: I'm a big fan of the Composer ecosystem — almost all of my modules are available as Composer dependencies, etc. And, in my opinion, ProcessWire actually integrates quite nicely with external dependencies. Since HTTP clients were mentioned, I'll use that as an example as well: in some recent projects I've used Guzzle together with ProcessWire. I may not be able to (easily) swap the client used by the core itself, but I've yet to come across such a need anyway. Of course this comes with a cost: I recently had to migrate one project to a new server simply because a third party dependency decided to drop PHP 7.4 support. In a minor version, because why the heck not. Not that it's a bad thing necessarily to bump up the PHP version, but having to do that sort of thing in a hurry just because I prefer to use a recent and patched version of a dependency is just bollocks. This is starting to get a bit rambly, so I'll just leave it here.