Leaderboard

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

🙂

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

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

@BFD Calendar You can usually downgrade PW as easily as upgrading it, so I would probably just replace the /wire/ with the 3.0.123 version that was working well before. But I think it's unlikely that the version change is the issue, as newer versions are generally more efficient and reliable than older versions. For most sites a version upgrade like this would help the situation. Though there could be something unique in this case, who knows. I would guess you got hit by an AI bot (or a bunch of them) that went nuts and used up the resource limits. If you are hitting this query limit regularly, then your web host would need to increase the resources for your site, or you'd want to upgrade to a plan with more resources. An alternative would be to use WireRequestBlocker to keep the bots from consuming all the resources, and/or using ProCache so that most output can be cached and not hit the database. The most recent error that you posted sounds like something is missing on the file system (per what Matjaz mentioned), or that PHP's opcache needs to be cleared, perhaps a call to opcache_reset() could help matters.