All Activity

This gives a solution to what sounds like it might be the same problem:

@ErikMH - I don't think I have ever seen a discounted renewal option. How do you renew a module for those reduced prices?

In case you are using this module and want to sync customers/purchases to Mailchimp – we just released an add-on for this module:

Hi, everyone! We recently built a small add-on module for our StripePaymentLinks setup and thought it might be useful to share here. We’ve been working with StripePaymentLinks quite a lot lately, and one thing the clients always wanted was a simple way to get purchases synced into Mailchimp without relying on external paid add-ons. So we built a small ProcessWire module to handle exactly that. The idea is simple: every time a customer makes a purchase via StripePaymentLinks, their details (name, email) plus the purchased products (as tags) get synced directly into Mailchimp. That means you can instantly segment, automate, and follow up with buyers without any manual exports. We built this because we didn’t want to rely on a separate paid Stripe → Mailchimp connector. With this add-on, it’s all handled natively inside ProcessWire — lightweight, minimal, and no extra subscription fees. What it does right now: Hooks into the creation of purchase repeater items (repeater_spl_purchases) Pulls customer name + email from the User created by StripePaymentLinks Extracts product names either from the expanded Stripe session line_items or as fallback from the purchase_lines field Pushes everything to Mailchimp, creating the subscriber if you allow it in the config Assigns the product titles as Mailchimp tags Config is super simple: just drop in your Mailchimp API key, Audience ID, and decide if you want to auto-create subscribers or only update existing ones. We’re keeping this intentionally minimal — one module, no extra steps, no fuss. Install, configure, and you’re done. We’ve been running it in production for some clients and it’s working reliably. If you’re already using StripePaymentLinks, this could save you the cost of external integrations while keeping everything in one place. Get it here: ProcessWire: https://processwire.com/modules/stripe-pl-mailchimp-sync/ [pending approval] Github: https://github.com/frameless-at/StripePlMailchimpSync Happy to hear your feedback or ideas for tweaks. Cheers, Mike from frameless Media

Hi all. Loving the searchEngine Module!!! Just a quick question, I have a global search in the main navigation as well as on the search results page. How do I set the action on the renderedForm to point to the search Page results? got it! $searchEngine->renderForm(['form_action' => '/search/']); Many thanks in advance 🙂

Is there a way to remove sites from the ProcessWire Sites directory, that are no longer powered by ProcessWire or does this happen automatic? https://processwire.com/sites/ Sadly, I have a few websites, that are no longer powered by ProcessWire anymore. 🙁

Hello all, @BFD Calendar - this did actually the trick. If no user is logged in the textblocks render once as expected. Thanks for the hint! I also figured out, that this behaviour depends on frontend editing, which is enabled for this particular field in my case. Once this is disabled, it also works fine even when logged on to processwire's backend. For my scenario I m fine, however, I think it is a small glitch and could be enhanced... any opinions if I should file a bug report for this and how and where? Many thanks!

FYI, you can view all the template access overrides for a field on the Overrides tab of Edit Field.

I think it is out of scope for this module, but it sounds like a useful thing to have in a separate module. I'll add it to my list of things to do.

Ok, thanks. When I get a few minutes I'll take it up again and see what happens.

I should mention that the files actually seem to be uploaded when I look in the asset folder

I've been getting this error suddenly when trying to upload files. ( "Unable to move uploaded file to:..." ) The site runs fine on my local server but the live server gives me this error everytime I try to upload a file. Both servers run PHP 8.3. I have tried to change the permission of the asset folder without any luck. Has anyone else gotten this error before?

Thank you - this is really useful to know. If I’m understanding it correctly I think we’re ok in this instance as we’re only pushing content to Bunny via API rather than the CDN hitting the site itself. It’s definitely early days though and I think there will be lots of edge cases to look out for. We’ve thrown this together for a product MVP that will have some ad traffic sent to it, so there should be plenty of data to look at. The main motivation at the moment is to minimise the data storage burden vs local storage on the VPS where the rest of the site runs rather than performance optimisation. But caching/compression etc will be interesting next steps.

Thanks! I'll see what our host (OVH) says and keep you posted.

Awesome. I use BunnyCDN as well (previously KeyCDN) configured with ProCache, mainly because they publish the list of IPs they use if their edge-servers need to pull assets (and then serve) from your website. While this post isn't directly related to your module, it matters if you are using WireRequestBlocker for the reasons I explained here (post only viewable if you have access). Long story short, if a CDN makes a request to a URL on your site that matches a blocking rule in WireRequestBlocker (rare, but it's bound to happen by accident) then the IP of that particular BunnyCDN edge-server will get blocked. Then if a visitor on your site is being sent assets from that edge server, then it will error because the CDN was never able to obtain it due to the edge-server being blocked. This is why the site might look fine in California, but broken in New York for example, as the user is being sent assets from different edge-servers. To prevent this from happening, I have a cronjob set up (runs every 24 hours) to grab the list of BunnyCDN edge-server IPs and I insert it into WireRequestBlockers "IP addresses to whitelist" field. This is a function that can do what I described above: function bunnycdnWhitelistIps() { if(!wire('modules')->isInstalled('WireRequestBlocker')) return false; // Fetch BunnyCDN edge server list $url = 'https://bunnycdn.com/api/system/edgeserverlist'; // Use cURL to fetch the content $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); curl_setopt($ch, CURLOPT_TIMEOUT, 30); $response = curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if($httpCode !== 200 || $response === false) { throw new WireException("Error fetching data from BunnyCDN API. HTTP Code: $httpCode\n"); } // Parse the JSON response $data = json_decode($response, true); if(json_last_error() !== JSON_ERROR_NONE) { throw new WireException("Invalid IPs."); } // Extract IP addresses into an array $ipAddresses = []; if(isset($data) && is_array($data)) { foreach($data as $ip) { if(filter_var($ip, FILTER_VALIDATE_IP)) { $ipAddresses[] = $ip; } } } // Remove duplicates and sort $ipAddresses = array_unique($ipAddresses); sort($ipAddresses); $data = wire('modules')->getModuleConfigData('WireRequestBlocker'); $data['goodIps'] = implode("\n", $ipAddresses); wire('modules')->saveModuleConfigData('WireRequestBlocker', $data); }

Could the idle timeout be caused by FastCGI waiting for an available PHP process due to too many active requests? Our site has been having outages within the last couple months, seemingly due to an increase in requests/visits by bots (crawlers for AI-specific data harvesters). Although I believe the server should be able to handle these requests perfectly fine, our host has said that seems to be our issue. I only bring it up since you seem to have mentioned it started somewhat recently (coincides similarly to our timeframe). If that is the case, the solution(s) would be upgrading to a beefier server, implementing caching solutions, attempting to block bots (ex: robots.txt, htaccess rules, etc.) and/or using Ryan's new [updated] Pro module (Request Blocker + Throttler), and examining all PW find requests to see if the raw versions of those API requests might be faster/more efficient...but yeah, caching mostly. Hopefully your host can give you some more insight. Our server log errors are a little different (webhost: Dreamhost): [Tue Sep 16 05:29:37 2025] [example.com] [warn] [client xxx.xxx.xxx.xxx] [pid 13103] fcgid_bridge.c(481): mod_fcgid: can't apply process slot for /dh/cgi-system/php82.cgi Once FastCGI hits a limit, it affects all rendering of the entirety of the website since it's linked to the webserver itself. Since removing some AJAX loading calls (that rendered PHP and made database calls) that were loaded on every page, a CSP report functionality, and adding Ryan's Request Blocker + Throttler, our site's total traffic (requests) has reduced 21% (from an average of 120k+ hits/mo), and stability has been better. I cannot say this is the same issue, I simply see comparisons, and since not much else has changed with your site, and PW is fairly stable overall through updates, I don't know what else it might be right now.

Thanks for this module. I've been using it a lot recently given that the web app I'm building makes heavy use of roles and permissions and I appreciate the "helicopter view" the module gives you. Recently, I've been using access rules on fields within the context of a template. Unfortunately, ProcessWire doesn't have a "helicopter view" of being able to see those settings, which means you have to go into each template and click on a field to bring up the modal, then go to the access tab to see what the settings are. Now imagine having to do that for dozens of fields. I wonder if you've dealt with that and if a feature like that makes sense for this module (or if it's out of scope).

At some point this happened to me as well. However only if I browsed the website while I was logged in as admin in the same browser. So for what it's worth try with a different browser, log out as admin or even use a VPN to test.

I'm monitoring the ProcessWire logs to find eventual PHP errors that needed a change by upgrading ProcessWire and PHP. Some old PHP was not recognised anymore, but most of that is done now. Most pages get some content (images) from external websites, usually just one per 'person'/page, and several on queried pages, like ' $features = $pages->find("parent=/events/|/the-eyes/, bfd_day.name=$todayday, bfd_month.name=$todaymonth, sort=bfd_year"); ', giving a list of events for 'today' with an average of 30-40 features. It all went well for over 10 years and without any notable changes the problem occurred and got worse. The problem affects the whole website, same when I call the home page or any other page including admin pages, even the Matomo statistics sometimes give a 500 error. From the hosting error logs I get many '[Wed Sep 24 00:08:51 2025] [X-OVHRequest-Id: 1d8b279cbdb0de4b3c5dad4c408a1f98] [error] [client 34.174.60.244:0] [host www.birthfactdeathcalendar.net] AH10141: FastCGI: comm with server "/homez.863/birthfac/www/index.php" aborted: idle timeout (160 sec)' errors. I filed an error report with them and wait for reply. There are no hooks used anywhere, site modules are up to date and give no errors at all in the logs. With an average of 30 visitors a day it's not extremely busy either. There are however over 33.000 pages.

Hi @Jan S.! Welcome to the forum, and congratulations on your first post! We're glad to have you. 😊 Based on what you're showing, your code looks good from what I can see of the TextBlocks documentation, so I am not entirely sure what to suggest, other than maybe seeing if removing the "echo" from your template call to the field will still render the field. I don't think it should, but since it's being duplicated, it can't hurt to try. Beyond that, TextBlocks is a paid ProDevTools module, so support for that module is in its own forum, locked down for paid/active module owners. Assuming your module support status is up-to-date, that can be found in the ProFields Support subforum here.

When I load up your site, although I'm seeing JavaScript errors, I'm not currently seeing any 500 errors in the browser console for loading up any assets. Have you identified and fixed all of the issues, or are the problem(s) you're experiencing not 100% repeatable? Database errors sound like a resource issue. If the 500 errors are related to a database issue, are there particular pages that show the errors more often than others? Do those pages have a lot of requests to pull in data for display of content? Can things be cached to alleviate database resources and PHP processing? Have queries made through the ProcessWire API been reviewed for efficiency? Since I'm not seeing the errors myself (or any errors that point to specific files), I'm only speculating. It's hard to know what to suggest. Do you have any further specifics? Any non-core modules installed? Any hooks being run?

Hello! I want to find out if this plugin is able to take over all mail sending within ProcessWire automatically by simply replacing the default WireMail Class. If so, where can I configure "SMTP via OAuth" like it is described here: https://github.com/PHPMailer/PHPMailer/wiki/Microsoft-Azure-and-XOAUTH2-setup-guide Is that even possible, or do I have to manually go through all my websites forms and send the mail programmatically? Luckily, I do have all the Azure Application-IDs and secret codes right here, but where do I fill them in?

I don't get a notice from LRP either. For the backend, I tried both a dash and now an underscore and neither work. I did manage to login via the backend after a few attempts.

If the issue is incorrect password then LRP normally shows a failure message, but I'm not seeing any notice at all, the form just reloads. FYI, for the backend login form you have to substitute the @ in your email address with an underscore.

Thanks @Robin S - I tried logging in via the backend login form. I couldn't, but I managed to use the password reset which worked, but then I still couldn't login with that new password via the backend or frontend forms still.