Leaderboard

Hey everyone, we just released a small companion module for StripePaymentLinks: 👉 GitHub: https://github.com/frameless-at/StripePlCustomerPortal PW Repo: https://processwire.com/modules/stripe-pl-customer-portal What it does The module auto-creates a ready-to-use page at /account/ where logged-in customers can: view all their purchases (table or grid view) access their purchased products / membership pages update profile data (name + password) open Stripe’s Customer Portal to download invoices or manage subscriptions No custom template coding required — the module installs a template + page, and you can still override the markup if you want. ⸻ Why we built it StripePaymentLinks already handles the checkout & user/purchase creation. This module completes the loop and gives customers a proper account area. 💡 Bonus benefit (Marketing): The grid view not only shows purchased products — it also shows available-but-not-yet-purchased products in greyscale. This turns the account page into a soft upsell area without being salesy. ⸻ Requirements ProcessWire 3.0.210+ StripePaymentLinks module installed & working Stripe Billing Portal must be enabled (Stripe → Settings → Billing → Customer Portal) ⸻ Status 🚧 BETA — already used on live sites, but we’d love developer feedback. If you try it out, please tell us what works and what’s still missing. Issues / PRs welcome. ⸻ Cheers & happy coding, frameless Media

AIOM is alive 🙃 I am pleased to announce that the AIOM module will be further developed and supported by @matjazp. My original repository is now archived, and matjazp's fork is now the official one. The forked version is now also listed in the Processwire module directory. This should make it possible for everyone to update the old version to the new one, either manually or via the ProcessWire upgrade module.

View website: ID Studio Web Agency We have been working on the ID Studio website for quiet some time using ProcessWire extensively for ourseleves and 90% of all our clients. This post will highlight some features we have implmented and also show off some of the hidden functionality. A quick overview is as follows: Custom web design of course 🙂 Front-end uses Canvas and Three.JS The core objective for us is to get users engaged, reviewing the showcase and services, then getting in touch The showcase and blog have alot of content We hide the ID Lab and About section in the footer but there if folks want to dive in and have the time Development features include: We use the form builder system with some custom modifications 3D tools and management Linking 3D elements to HTML elements Repeater matrix for content panels and lots more, best way is to see it on the video overview below ID-Overview.mp4

You guys rock!

Hi Juergen I have the new title property set - ->title('<h1>From LPN website contact form</h1>') // this is a new property from this module but it does not show up in the email. I've read your docs where you say "This will be added automatically to the email, independent if you are using a HTML email template or not - no need to add it manually." so I'm puzzled. Thanks for a great module

@Robin S Good question, theoretically it's more efficient to hook to an object directly when it suits your need, though I'm not sure if it is in practice... I've not done any tests to measure. When hooking '$pages' it's called a "local" hook because it's local to just that instance named $pages (and the hooks are stored with the instance), whereas when hooking 'Pages', it's called a "static" hook and it keeps track track of it in the WireHooks class, as it would apply to any current or future instance of the Pages class. But there's only ever one instance of Pages (named $pages) so it doesn't matter in this case. https://processwire.com/api/ref/wire/get-hooks/ Another way of saying it: The $pages->addHook('method') and $wire->addHook('Pages::method') are technically different calls in that $pages->addHook('method') is saying "Hook method in JUST THIS instance of Pages" and $wire->addHook('Pages::method') says "hook method in ALL instances of Pages". While it may not matter in the case of $pages (since only ever one instance), it does matter in cases where there can be multiple instances of the class, such as with the $page class. In that case, you have a choice to make of "do I want to hook JUST THIS $page"... $page->addHook('method', ...); ...or "do I want to hook ALL Page instances" or "do I want to hook ALL BlogPostPage instances", etc. $wire->addHook('Page::method', ...); $wire->addHook('BlogPostPage::method', ...); What's more efficient about local hooks: If hooking just a single $page instance (or other type), then the attached hooks disappear when the $page instance does. When hooking all instances of a class, then that hook sticks around for the entire request, or until manually removed. When a single instance is hooked (local) rather than all instances (static) then ProcessWire only has to consider that hook for the one instance, rather than all instances. So less work. For $pages vs Pages, there's only one of them either way, so it probably doesn't matter much one way or the other in that case.

@dab thank you so much for sharing! That actually solved my problem! Because $config->httpHosts = array('domain.com'); didn't work, but $config->httpHosts = array('domain.com', 'www.domain.com'); did!

@BigRed I experienced this & in my case I pinned it down to the $config->httpHosts = array('xxxxxxxxxxx'); in config.php not matching the sub-domain I has hosting the new site on. Sorry if I've stated the obvious & e.g. adding www. when it wasn't required.

I was able to use http:// and the IP address, then everything worked as expected. I was using https:// and the domain name before.

I'm not sure if it's a solution to your issue, but I have this hook in every site (see the referenced issues for background): // Instead of rebuilding image variations, remove them and they'll be rebuilt when next requested // Fix for: https://github.com/processwire/processwire-issues/issues/1301 // Also see: https://github.com/processwire/processwire-issues/issues/1277 $wire->addHookBefore('Pageimage::rebuildVariations', function(HookEvent $event) { /** @var Pageimage $pageimage */ $pageimage = $event->object; $event->replace = true; $pageimage->removeVariations(); // Return expected output to avoid errors $event->return = [ 'rebuilt' => [], 'skipped' => [], 'reasons' => [], 'errors' => [], ]; }); It's only safe to do this if you do not allow image variations to be directly inserted into RTE fields. More info in this comment: https://github.com/processwire/processwire-issues/issues/1301#issuecomment-893957331