All Activity

Hmm... Looking to give DDEV a try. Like Jonathan, I've had a setup that primarily runs multiple hosts from the same webserver, PHP, and SQL instance(s). Although it was Docker-based, it didn't require project isolation. Because of that, I've kept my files in a Dropbox folder, using the Dropbox client, so all of my local host machine's development files are automatically backed up and (minimally) versioned (Dropbox provides some level of version history). I'm using Windows Subsystem for Linux with DDEV, which automatically creates mounts for logical drives. Moving to DDEV, I spun up a config with the PHP, MySQL versions and web-server of choice (Apache) to mimic my production server. I also set the docroot to a folder, thinking that I might be able to create a symlink (as the /mnt/c/ contains access to the host filesystem, and therefore the Dropbox files) and overwrite the DDEV-generated docroot directory with a Dropbox symlinked project folder. After the DDEV config finished, I tested the project with a simple HTML file to make sure everything was working. (It was.) I then deleted the generated htdocs folder, and created a symlink from my mounted Dropbox's project folder to "htdocs" (the name of the chosen docroot). I am getting a Forbidden error. The file permissions seem to be set to 777 however, and the group and user match that of files generated within the DDEV container manually. I looked at the provider integration example where Dropbox is mentioned as part of the project's /.ddev/providers/ YAML folder, but I'm not using archived files, nor do I really want to have to pull/push/rsync any/all changes (I'd rather they were live since I'm editing them on the host OS, which the DDEV project can see thanks to the mount). ddev config --webserver-type=apache-fpm --php-version=8.2 --project-tld=loc --database=mysql:8.0 --docroot=htdocs From the project root, the symlink I used (for the first project as a test; my Dropbox "htdocs" folder is where I test random bits of code) was: ln -s /mnt/c/Users/brendonkoz/Dropbox/development/htdocs htdocs Does anyone have any thoughts?

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

Thank you for this last tip @BrendonKoz, unfortunately, changing the admin URL didn’t solve that neither.

Yes, mod_security would be my first suggestion as well.

As I already told you in a private conversation, you should contact your host provider or turn of mod_security.

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.

You'll need to do more than that to make it reliable - have a read through some of the issues - these two are key. One is simple to fix, but the other requires a fair bit of work. https://github.com/ryancramerdesign/LoginRegister/issues/2 https://github.com/ryancramerdesign/LoginRegister/issues/9

Yeah, that's what I ended up doing, removed the restriction on the page-create roles.

Hey @rooofl, I saw your request for help. I unfortunately don't do client work, but would still like to offer at least one additional chance for fixing this issue. It doesn't seem like this client is a Dreamhost customer, but it's entirely possible that the host may have similar configurations for security on their server. You may want to reach out to, or have the client reach out to, the webhost support team and ask if the URL as provided in the network devtools that you screenshotted would cause their server security to prevent the request. For Dreamhost, the solution was simply to change the custom URL for the administrative panel from whatever custom option (ex: "admin" in your screenshot's case) back to the default of "processwire". This is due to their custom mod_security rules. They can update their rules for one-off requests, but the next time they update the server software it'll break again. Here's where I mention it: It's worth a shot to, at least, try changing the admin panel URL from "admin" to "processwire" and then testing an upload to see if it fixes things. Otherwise a support ticket to the webhost would be my next suggestion.

@FireWire Thank you for this amazing module! I'm using RockPageBuilder (6.7.0) and the latest dev version of Fluency. In some cases I use nested Rockpagebuilder fields (So a Rockpagebuilder field inside a Rockpagebuilder field). In this specific case the translated values aren't saved (unless you edit the fields after translating, as you mentioned earlier).

@Tyssen - unfortunately, that module is pretty broken. Either buy LoginRegisterPro, or use LoginRegister as a base (fixing the key Issues yourself), or as inspiration for how to implement your own login form and logic.

My client’s PW installation needs help: this bug is currently affecting all the upload fields of the installation. I can’t spend more time on that bug unfortunately, and I am looking for estimates to solve that. Anybody interested? Send it to raphaelbastide at pm.me and CC daniela at rinomina.com. thank you !

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.

Good morning @da² Remove this line to show the badge, but anyway: it works properly on my side on single and multi file upload fields. You are right, I will check this!! BTW: You do not have to write the filesize like "524288000" -> you can write "500 MB" instead and it will be converted to "524288000" automatically. I have never tried it with such a high upload max size - please try it with a lower size (fe. set it to 50 MB) and take a look what happens). Another aspect could be that there are 2 different max size config settings: Max upload file size (the max size for an individual file) Max post size (the max size for all uploaded data via a POST request The validator only checks for the max file size, not the max post size. So for testing purposes please set the max file size to 50 MB, remove the showClearLink() and take a look what happens.

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

It works only if I set multiple to true, but this is a single file upload: $zipUpload = new InputFile("zipFile"); $zipUpload->setMultiple(false); // Rule 'allowedFileSize' not working with "false" $zipUpload->showClearLink(true); // No link displayed too $zipUpload->setLabel("label"); $zipUpload->setRule('allowedFileSize', '524288000'); // Not taken into account except with multiple files $zipUpload->setRule('allowedFileExt', ['zip']); $zipUpload->setRule('required'); Oh, this works if I fill the english title of french language! Is it expected? Usually in ProcessWire the field first language value is used as default if second one is empty, like here: In my language selector for example, it works like this, all languages are found and usable. But at least I know how to fix this on my side. 😉

I'm working on a site where I want people to be able to create listings but to do so they need to create accounts first. For the login/register forms, I'm using https://github.com/ryancramerdesign/LoginRegister but it says in the module settings "Roles with page-edit permission are not shown." But I want my new users to be added to a role with page-create/edit permissions for the template in question, so how do I assign that role to the module? Or is there another way I should be doing this?

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

Hi @matjazp Thanks for quick response. I guess the same.😊 Gideon

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

Please replace self::getDirContents($path); with self::_getDirContents($path); (underline is missing).

Hi @ I have just installed the forked version of this module. I get the below whenever I try to clear cache in the module setting page. Any hints? Fatal Error: Uncaught Error: Call to undefined method AllInOneMinify::getDirContents() in site/modules/AllInOneMinify/AllInOneMinify.module:1216 Fatal Error: Uncaught Error: Call to undefined method AllInOneMinify::getDirContents() in site/modules/AllInOneMinify/AllInOneMinify.module:1216 Thanks. Gideon