Leaderboard

Hey folks, fun fact: this module was already featured in this week’s ProcessWire Weekly – even before we managed to post it here in the forum. So, here we are, finally giving it a proper introduction! 😅 TL;DR: This module connects Stripe Payment Links with ProcessWire and provides a simple checkout integration for sites that don’t need a full shop. 🎯 ✅ Drop a Stripe buy button anywhere ✅ Redirect back to PW thank-you or delivery pages ✅ Buyers get accounts, purchases are logged, access is granted ✅ Access mails are sent automatically ✴️ New in v 1.0.7: Sync existing purchases and buyers from Stripe to PW with test/write option ✴️ New in v 1.0.8: Full Stripe subscription support with real-time webhook updates (cancel, pause, resume, renew) and smarter access control logic ✴️ New in v 1.0.14: Create and send "Magic Links" (access links) to customers for products they've already purchased. First things first: What are Stripe Payment Links? Stripe Payment Links are basically hosted checkout pages that you can create directly in the Stripe Dashboard – no coding required. You define a product (or multiple line items) in Stripe. Stripe gives you a unique URL (the “Payment Link”). You can drop this URL behind any button, on any landing page, newsletter, or social media bio. When a customer clicks the link, they’re taken to a secure Stripe Checkout page (PCI compliant, supports all major payment methods, Apple Pay, etc.). After payment, Stripe redirects them back to your success URL. Super simple. But… on its own, Stripe has no idea about your ProcessWire site, your users, or your gated content. That’s where this module jumps in. 🚀 Why another payment module? We at frameless Media often work on small client projects where setting up a full e-commerce shop would be complete overkill. Think: Coaches selling a few courses or workshops Businesses offering a handful of digital products or subscriptions Creators who just need a buy button on a landing page Stripe Payment Links are perfect for this. But: ProcessWire on its own doesn’t handle redirects, user handling, or gated delivery pages. So we built StripePaymentLinks – a lightweight drop-in module to connect Stripe with PW. What it does Handles the redirect back from Stripe Checkout that contains the session id Creates or updates the buyer’s user account Records purchases in a repeater field Manages access to “delivery pages” (only available after purchase) Auto-sends access mails (configurable: never / new users only / always) Provides Bootstrap-based modals for login, password reset, set-password Usage examples Example 1: Sales page + delivery page Sales page has a “Buy now” button (Stripe Payment Link). After checkout, the user is redirected to the delivery page, which is access-protected. → Module logs them in, grants access, and if they’re new: a set-password modal pops up. → An access mail with product links is sent. Example 2: Product without a delivery page Some products don’t need protected pages (e.g. a consulting slot or voucher). → The success redirect goes to a generic thank-you page. → The module shows an access summary block with purchased products and sends the mail. Example 3: Mixed purchase (thank-you + delivery page) A checkout with multiple items: e.g. a “simple product” plus an addon that has its own delivery page. → Thank-you page shows the addon link(s). → The access mail lists all purchased products. Source & License The module is open-source under the MIT License. 👉 GitHub: https://github.com/frameless-at/StripePaymentLinks 👉 ProcessWire modules directory: https://processwire.com/modules/stripe-payment-links/ So yes: if you or your clients just need a few low-barrier buy buttons, not a full-blown webshop, this might be the module you’ve been looking for. If needed we can provide some screenshots and visual examples next week 😉 Happy to hear your thoughts, ideas, and testing feedback! Cheers, Mike

I had to push a small update as I noticed on a new installation that it seems you cannot send an empty <mjml></mjml> tag anymore. The fix was rather simple: add a <mj-body> and it stopped complaining.

I wouldn't call it extensive knowledge 😅 It was just a regular PW installation that was copied via cronjob to another vhost on the server (both files and DB).

TagsToFolders Github: https://github.com/eprcstudio/TagsToFolders Modules directory: https://processwire.com/modules/tags-to-folders/ This is a small helper tool to visually organise fields/templates into folders in the menu when they are tagged. This is a simple module that can help you declutter your templates/fields menu by organising them in folders using tags. I initially envisionned this module to be used for cases where fields and/or templates were created by modules and thus not polute the ones created by the user.

I just pushed a tiny update to make adjustements to the CSS for the new Konkat theme. It’s just some spacing details and it now uses the --pw-border-color CSS var (and falls back to the original theme color if not set).

@virtualgadjo - thanks for reporting. I've fixed in the latest version. I also added the PW namespace as I will be doing with all my modules are new versions are released.

I don't want to be too blunt and I can't speak for anyone else, but I've never referred a client to a software or service website as part of the education process. It doesn't do anything for them. You are the expert. The person making the pitch should be able to fully explain the technology stack to the extent that the conversation requires it in language they can understand because we are the interpreters. Clients trust me because I am the expert and the top 3 things they care about are these, in this order: How much is this going to cost me? Why don't we use xxx? (or, our current site is xxx I'm not sure we want to switch) When is it going to be done? Sending a client to any site for tools or software is like saying "here, do your own research". The ProcessWire site, like any other development tools/software sites, isn't there to woo clients. Most clients don't care enough to take time and truly understand it because that's not their job. If a curious client is in a position to go to websites like ProcessWire, several steps have been skipped in the client discovery/planning process IMHO. I'd even go so far as to say that if a site has "Docs" or "Documentation" in the primary nav, it's not for clients and they shouldn't be there. I hope this isn't a too hot a take... I would say that improvements could be made iteratively with more use of color for contrast, emphasis, and indicating priority. I think it's a flexible design that can evolve in whatever capacity that may be needed. This has the ability to highlight some impressive facts and figures. No notes on the content, some elements could be integrated into the current design. Even then, facts and figures are for devs. I used the word "scalability" with a manager once and they stopped the conversation to ask "wait, what does that mean?" and still didn't care when I explained. A a CMS or framework site is never going to lead to clients translating what's on the page to time or money. In all likelihood, the conversation you are having with a client at 10:00 just followed a call with their product distributor at 8:00am, their accountant at 9:00, and at 11:00 they're meeting with other members in management. Personally, I would no sooner send someone to processwire.com than I would laravel.com. You are the time and money. I agree with this. I will go out on a limb and say the number of end customers who went to the Drupal site and left thinking they need a Drupal site isn't zero, but it's probably close. If someone is hiring a Drupal developer then they're in a role where it's part of their job to understand the tech stack even if they aren't a dev. Visiting wordpress.com, it doesn't target the end user but name recognition still draws business which overcomes the website entirely. This is fair. It doesn't take a monitor that computer professionals use to get this experience. All you need is a consumer iMac. I think iteration can address concerns. I don't want to belabor the point, but to be fair, did you ever send a client to the QuarkXpress website... Just a little joke ☺️ Cheers from a fellow old school developer who built their first website in 1997 and tinkered with QuarkXpress 🍻

hi again 🙂 @monollonom is right the solution is to use pages, you can do this with the page reference fielfd and get this kind of thing quite easily sorry most things are in french its just in a demo website i use to help french guys with pw 🙂 you can see i hav a spécial field named resume and a list of radio button coming from a page reference field allowing hidden pages, the parent page is like this as you can read in the blog page, you can use any kind of type for those page reference fields, actually it works a lot like the way i use them for blog categories and/ot tags have a nice day

I just tried on a test setup to install the FieldtypeOptions module and add it as an image’s custom field but it is not displayed when editing an image, nor is it available to toggle on in the FieldtypeFile’s module settings: And it's actually normal behavior as this Fieldtype is basically blacklisted as a FieldtypeFile’s custom field. @tires your best bet is to use a Page field instead and have your options stored as pages somewhere: