All Activity

Hello Jan, I did not find any infos about the possibility of creating multi-step forms inside the form builder docs, but maybe I have overlooked it too.😉 I will take your request as an idea about a new feature for the future and maybe I will integrate the possibility of creating a multi-step form out of the box in an easy way. I have some ideas but I guess this will take a lot of time, so it cannot be realized in the next days.

🎉 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

@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!

@matjazp First I downgraded to PHP 7.4, made no change. Then I replaced wire 3.0.246 with wire 3.0.123 from your link. PW 3.0.123 was the version I had a month ago when everything still worked. Then the site didn't show anything, not even errors. So I uploaded wire 3.0.246 and got the error back. Finally I uploaded the latest dev version from GitHub upgraded again to PHP 8.2 and, hurray the site is back – a bit crippled as now quite some errors appear in my templates. There are apparently many changes between PHP 7.4 and 8.2 that I need to figure out now.

Hello @Juergen, once more thank you very much for your superb support 🙂 In the meantime I found the "Multi-language" section in the documentation as well - sorry I have overlooked this. But the infos you provided above are much appreciated, I will dive into this later on today. Regarding the multi-page form - I need to reconsider this as implementing forms seems to be a challenge for me as a citizen web developer on its own.Maybe the Form Builder plugin can help to achieve this...

Good morning Jan! I guess you have installed the language support module first?? If not, here is a little screen cast how to do it. You will need it to translate strings. Languaga install.MP4 You are German speaking too , so you could install the language files for German translations from the module itself as shown in the clip. Now every English phrase should be translated into German, but if you are not satisfied with the translation text, you can overwrite it with your own text (but be aware that every time you install the translation files again, every changes will be overwritten). You will find the file containing the text for the privacy checkbox here: By clicking the "Edit" link you will be redirected to the editable page: There you can make your changes if you want. Not out of the box. Maybe you can use URL segments and put each form on a segment page. Example if form 1 is valid, then you will be redirected to the URL segment 2 which contains form 2 and so on. You will need to store the form values inside a session variable. At the end (last URL segment) you can take all the values stored in the session variable and output it to the user (as a kind of list of entered values) Every value output to the user should have an edit link next to it and if the user clicks on the link, he will be redirected to the appropriate form, where he can change the value. I would add a query string at the end of the link to determine that the user wants to change something. If the user have changed the value, everything is valid and the query string is present in the URL then the user will be redirected directly to the last page again, where he can check his entered data once more. If there is a need for changing another value, then he clicks on the next edit link and so on. That was my idea, but you could also write a question in the general forum about this issue. I guess there are some people who have written a multi-page form and can give you a hint how to solve it. FrontendForms only creates single forms, but it is not impossible to combine the values of multiple single forms by using sessions. Good luck!

Why it would work for an hour or two and then stopped? Can you limit access to the website to just your IP? I guess you'r using apache, so you could put this in your .htaccess: <RequireAll> Require all denied Require ip x.x.x.x </RequireAll> Or perhaps you have an option to do that in admin panel of your provider. It sounds like an incomplete upload (with FieldtypeFile.module being an older version that lacks those method implementations, otherwise FieldtypeImage would inherit them). Please double check that you uploaded the complete wire directory. As an alternative you can add public function hasFiles(Page $page, Field $field){} public function getFilesPath(Page $page, Field $field){} to /wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module. But you said it worked already so I'm without the ideas here. Try to downgrade PHP to 7.4 if that helps?

@BrendonKoz No, I do everything on the site hosted by OVH provider. I've done it for 12 years now and it has over 30.000 pages. You can see how it actually looked like on 24 June 2025 here: https://web.archive.org/web/20250624203839/https://www.birthfactdeathcalendar.net/. I have a database backup from the PW module 'bfd_20251003_processwire.sql'. So do you mean installing a fresh PW site on a local computer, install all the site modules and templates, and import the sql database? That simple? I'm an artist (https://www.performan.org/exhibitions/), and not really a coder....

Sorry, you've said you could, and couldn't a few times, I wasn't sure what was currently accessible anymore. Are you able to develop this website locally, off of the live production server, in an environment that you control? Due to the restoration process from your host seemingly not working as expected, it would be nice to get the filesystem to a properly restored and working point, and developing locally might be the simplest option.

@BrendonKoz As said above I can't get into the PW admin interface anymore. No matter what page is called, everything gets stuck at Uff da… Fatal Error: Class FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (FieldtypeHasFiles::hasFiles, FieldtypeHasFiles::getFilesPath) (line 18 of wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged. I can access the errors.txt file via ftp. For today (2025-10-07) only there are 19092 errors as above. In my provider's error log I can see plenty of [Mon Oct 06 20:26:03 2025] [X-OVHRequest-Id: 0b8c2f578748d1061d5e670a11218ce2] [error] [client 54.161.50.125:0] [host birthfactdeathcalendar.net] AH10157: FastCGI: An error happened during Fastcgi processing, fallback to CGI [Mon Oct 06 23:52:49 2025] [X-OVHRequest-Id: da62e0ad0f08ee270e46e69c4cdbb0b7] [error] [client 51.57.57.231:0] [host birthfactdeathcalendar.net] AH01264: script not found or unable to stat: /homez.863/birthfac/cgi-bin All those are Amazon and Microsoft ip addresses. Apparently the robots.txt file doesn't keep those away. I manually replaced the latest wire and all site modules are up to date. Template errors that showed up earlier are all fixed. But as long as I can't get past the Fatal Error there's not much more to do or try I presume. And the most baffling thing is that everything worked fine yesterday for about two hours, without any further change the Fatal Error just popped up.

I would recommend deleting the errors.txt file (if/when you have access to the PW admin, it's under Logs -> Burn [while viewing that log; expand "Helpers" at the top, and then "Actions"]), or if not deleting, pruning it. I suspect that log has lived since the website has been running. It's unlikely you care about errors from 2 months ago or more - just the recent issues. I leave that decision up to you, but having an error log that large is unlikely to be useful (at least for me). I think it would be good to fix the errors that are popping up first. Your upgrade of the /wire/ directory is the first step; making sure the modules you have installed and enabled are up-to-date is another (and maybe you have some that aren't fully compatible?). Then making sure each template no longer has any problems (since we're working on a newer version of the core, it's unlikely but entirely possible). If you don't yet want to invest in additional development time to implement ProCache, you could try the built-in template cache as a quick test to see how your website would behave with that enabled. This would be good for pages (URLs) where the content doesn't change often. The cache is rebuilt after a set period of time, or when changes are made to the page, or its template. To enable template caching, go to the template you might want to try this on, head to the "Cache" tab, then enable it and choose the settings you think would best suit your site's template.

Hello @Juergen, me again and sorry for bothering you in this regards... Adding the privacy checkbox including a standard text phrase referencing the gdpr website link works in English, but how can I display a German version of this? It is there in the translation, but I didn't figure out to get this working. I can partly achieve this by adding a custom field name holding the German text, but then the link to the referenced gdpr-page disappears. As a workaround I just overwrote the original english text phase in /Formelements/Inputelements/Inputs/defaults/Privacy.php to get the job done. But I think there must be a more handy way to achieve this? Another upcoming challenge would be to implement a multi-page form, where the user should shall enter form data in consecutive steps/pages, being able to go back and forth. On the last page I'd like to output all entered data to be confirmed as correct before submitting the form. Could this use case also be done using FrontendForms? Many thanks in advance!

It's a great module either way!

@bernhard I just found this one myself this week 🤦‍♂️ I was so proud of my code being 8.4 ready too 🤣

🙂

@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.

Thank you for the link. I am a bit concerned that it specifically mentions "Padloper 2", and I can see our version being "0.0.9". Does it still apply? George

Hello @Juergen, thank you very much for your quick fix. I updated the module and the error messages are now all gone. Many thanks!

Good morning @Jan S. Thanks for reporting these issues. I have fixed them and updated the module version to 2.2.55. Alternatively you can replace the following files, which contain the changes: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Form.php https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php PHP 8.4. is more strict than the previous version and in addition I use declare(strict_types=1); on all PHP files in FrontendForms. As a result, any warning will be treated as an error. So please test if it works now and let me know if you discover some issues again. Thanks!!

@ryan The $config->debug is set to true. The errors.txt is a hefty 257,8MB file.... The last lines are 2025-10-06 22:26:49 ? https://www.birthfactdeathcalendar.net/places/hobart-tasmania-australia/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) 2025-10-06 22:26:55 ? http://birthfactdeathcalendar.net/events/18-june-2024/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) 2025-10-06 22:27:03 ? http://birthfactdeathcalendar.net/people/van-zon-hans/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) 2025-10-06 22:27:08 ? https://www.birthfactdeathcalendar.net/places/holmby-hills-california-united-states-232-mapleton-drive/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) 2025-10-06 22:27:11 ? http://birthfactdeathcalendar.net/events/31-august-1986-b/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) 2025-10-06 22:27:19 ? https://birthfactdeathcalendar.net/events/dates/november/4-november/ Fatal Error: Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) The wire is now 3.0.246, uploaded from processwire-30246-master. It's now visible if you go to the site. In this log there are still 11 or 12 errors per minute, so I presume there are still bots targeting the site. Apart from the Amazon bot mentioned earlier I also stopped Google Search Console, so it's hard to tell where they keep coming from.

I think you can find your answer here :: But please, don't test this on a production site.

Hello @Juergen, I have an issue installing FrontendForms on my processwire instance. After installing the module, the following error appears on the very top of the admin page: Deprecated: FrontendForms\Inputfields::removeSanitizers(): Implicitly marking parameter $sanitizer as nullable is deprecated, the explicit nullable type must be used instead in /home/web/_dev/site/modules/FrontendForms/Formelements/Inputelements/Inputfields.php on line 183 The module seems to work... but I also need to put more efforts in the forms I want to ceate and will see, if it is working as expected despite the error message. I use FrontendForms 2.2.54 together with processwire 3.0.246 stable and PHP 8.4 on Apache webserver. Thanks in advance for investigating. EDIT: it seems to work, but the frontend also displays errors in debug mode: Deprecated: FrontendForms\Form::getLangValueOfConfigField(): Implicitly marking parameter $modulConfig as nullable is deprecated, the explicit nullable type must be used instead in /home/web/_dev/site/modules/FrontendForms/Formelements/Form.php on line 1278 Deprecated: FrontendForms\Form::newLineToArray(): Implicitly marking parameter $textarea as nullable is deprecated, the explicit nullable type must be used instead in /home/web/_dev/site/modules/FrontendForms/Formelements/Form.php on line 1448 Deprecated: FrontendForms\Inputfields::removeSanitizers(): Implicitly marking parameter $sanitizer as nullable is deprecated, the explicit nullable type must be used instead in /home/web/_dev/site/modules/FrontendForms/Formelements/Inputelements/Inputfields.php on line 183

@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.

I have found the issue: This only happens if the ID and name attribute are exactly the same on a single upload field. If there is a difference, everything works as expected, so I have added an additional suffix to the ID attribute of a file upload field to prevent this behavior. display-change.MP4 Now everything should work fine! Module version is updated, so please test if everything works now as expected.

@BFD Calendar Make sure you've got /site/config.php setting $config->debug = true; just so you can see errors. You may want to set it so that it's only in debug mode for your IP address, i.e. $config->debug = $_SERVER['REMOTE_ADDR'] === '123.123.123.123'; Keep an eye on the files in /site/assets/logs/, especially errors.txt. If you have shell access, you can "tail errors.txt" in that directory to see what the latest error messages are. You don't need to be able to login to the admin to view these logs, you can just locate them on the file system. Most of the time they will reveal whatever the issue is. If it's not clear, then post the last few log entries here to see if we can identify anything from it. The errors you mentioned may be expected, as it looks like they are trying to access something related to cgi-bin or a .well-known file, which are specific to your hosting and not to ProcessWire. So if your host blocks those addresses, then you'd expect to see this in the apache error log. Basically, I don't think those error messages are related to whatever is preventing your site from running.