Recently Updated Topics

I am creating a module. The first-time install works without error, and the module functions without error. However, when I uninstall the module, then attempt to install the module again, I get the following error: "Unable to install module [module]: Role collision detected ([role]): role already exists." The role was deleted successfully, and no reference to that name exists in the database. Has anyone come across this before?

Ohh I hadn't understand this about WSL! So it's a case of docker inside docker? Interesting!

Let's say you have a repeater field. ProcessWire renders it in the default ProcessWire way in the page editor, which is fine, however there are times where you may want to render a particular repeater field in a more streamlined way, like a table, while maintaining the ability for the user to make changes to field values of the respective repeater items. The problem with this however if that you must be very careful because if you do not represent a field of that repeater (and represent it correctly with the correct form "name"), then ProcessWire will wipe out the data because it expects it to exist when saving!!! This includes the "native" fields for a repeater item (which are "loaded", "sort" and "publish"). THOSE MUST ALSO BE REPRESENTED! For fields in your repeater that are hidden however, they do not need to be represented, so you can ignore rendering those. You have to be very careful here because you may one day decide to add a new field to a repeater and keep it as "Open", and forget this requirement and not add it to the your custom renderer. Then if you wrote data to the field in some way, and then a user went to edit a page that contains that repeater field and they save, your data will get wiped out!

@Robin S Thank you very much for your work. I was going to write a similar module myself, but yours is even better than I could have imagined.

@horst - there are lots of new theme issues being posted to Github

@Spinbox I'm not sure why that wouldn't be working if the fields are initialized with a translate button. I've never nested RPB fields. I'd like to support whatever features RPB has. I've reached out to @bernhard to see if there's anything that he may know of to help or confirm that nesting is supported. Will come back with more info when I can.

Perhaps give $user->isSuperuser() a shot instead. It's documented as faster and is my go-to since it's a dedicated method.

Thank you, @BrendonKoz. Indeed, my multi-image field is called "images", and, as you see in my code snippets, all the attribute properties are in quotes (some in single ones, others in double quotes). Same in my real use case.

[Update] StripePlMailchimpSync — v0.2.0 Hey, all, a fresh update for anyone using StripePaymentLinks together with Mailchimp! Version 0.2.0 adds proper resync tools, better reporting, and a few smart fixes under the hood. ⸻ 💡 What’s new Resync from the module settings You can now trigger a Mailchimp resync right inside the module config. Pick a date range, filter by buyer email if you like, and choose between dry-run or live mode. Each run generates a detailed report — showing who was synced, skipped, or caused errors. ⸻ Real-world use case: Your client’s been happily selling with StripePaymentLinks for a while — but only now decides to start using Mailchimp. With this update, you can sync all past purchases into Mailchimp in one go, safely and transparently, straight from the module config. Always open for feedback or ideas — if you’re using this in production, let me know how it works for you or what you’d like to see next! 🚀 Cheers, Mike

Has anyone figured out a reliable way to add a namespace to a module without resulting in a very stubborn error like: Class "WireData" not found Seems like the only reliable way is to uninstall and then install again, but this is kinda of impossible to do once you've already updated the files, so you need to know to uninstall beforehand. I have had requests to namespace my modules, but I don't want to break people's admin interfaces (and mine for that matter). Thanks!

Solved! As @matjazp advised in PM, mod_security was the problem. I contacted my host provider (OVH) and changed in .ovhconfig the line: http.firewall=security to http.firewall=none Thank you all for your time.

mod_security was the thing indeed! Solved thank you @matjazp @netcarver!

OK, understood. At the moment, it's being used on a feature which may not actually end up being actively used or by enough people to make it worthwhile fixing those sorts of issues. We'll have to wait and see.

I have fixed the JS bug for displaying the badges on single upload fields: Please replace the JS code with this one: https://github.com/juergenweb/FrontendForms/blob/main/frontendforms.js You can remove this line too, because it is true by default, you only have to use this method if you want to prevent the badges from being displayed. In this case you have to set the parameter to false. You can also try to set the max filesize to 50MB and see what happens. Let me know.

Hi @matjazp By the way, would you update the github repository? Gideon

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

Hello community! We would like to share our new module for ProcessWire: ----------------------------------------------------------------------------------------------------------------------------- Asyntai - AI Chatbot Create and launch AI assistant/chatbot for your ProcessWire website in minutes. It talks to your visitors, helps, explains, never misses a chat and can increase conversion rates! All while knowing your website, customized just for you. Your ProcessWire website can now talk. This plugin embeds the Asyntai chatbot on your ProcessWire site and provides a simple admin page to connect your site to Asyntai. Why choose Asyntai? • Increase conversions: Instant, human like replies keep shoppers engaged and buying. • Never miss a chat: The AI replies day and night, even when your team is offline. • Knows your website: Customized just for you; it follows your instructions. • Works in all languages: Automatically detects and answers in the visitor’s language. • Fast responses (1–3s): Keeps customers from bouncing. Installation Download the module from GitHub or from here Copy the module files to /site/modules/Asyntai/ Go to Modules in your ProcessWire admin Click "Refresh" to detect the new module Click "Install" next to "Asyntai - AI Chatbot" Configuration After installation: Go to Modules → Asyntai Click "Get started" to connect your Asyntai account Sign in or create a free account The module will automatically save your connection The chatbot is now live on your site! Don't have an account yet? Create a free Asyntai account at asyntai.com/auth Managing Your Chatbot Once connected, you can manage your chatbot settings, review chat logs, and customize AI responses at: asyntai.com/dashboard Requirements ProcessWire 3.0.0 or higher PHP 7.2 or higher Have a question? Email us at hello@asyntai.com or try our chatbot directly at asyntai.com/ GitHub: https://github.com/asyntai/processwire-Asyntai