ryan

Today there’s a new version of ProCache (4.0.7) available for download in the ProCache support/upgrades board. Here’s what’s new in this version of ProCache: ProCache has been updated throughout for PHP 8.4 support. Upgraded the SCSS compiler to the latest Leafo SCSSPHP 2.0.1. This version requires PHP 8.2, so ProCache also lets you choose from two older versions if you prefer. Upgraded the LESS compiler to the latest Wikimedia LESS 5.4.1. Past versions can also be selected, including Wikimedia 3.0.0 and Leafo LESS 0.5.0. Upgraded the CSS/JS minifier to the latest available version (1.3.75 latest). Because we had customized the CSS/JS minification quite a bit, the older version (1.0 stable) also remains selectable, just in case there’s anything the older version handles that the new one doesn’t yet. LESS, SCSS and Minifier versions can be selected and changed in the ProCache configuration: Setup > ProCache > JS/CSS. Likewise the ProcessProCache module has a new JS/CSS tab for configuring the settings mentioned above. ProCache now logs LESS/SCSS and Minify status and errors to the JS console (when in debug mode or for a logged-in superuser). ProCache now has a proper API reference page available here: https://processwire.com/api/ref/pro-cache/ Because this is a brand new version with several upgraded libraries, it should be considered beta until it's been out a couple of weeks. Thanks for reading and have a great weekend!

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

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

Last week I was on a boat, far from any computer, so that’s why there weren’t any updates. This week I’m back in the office and back to work on the core. The focus has been primarily on optimizations and issue fixes (see dev branch commit log). There were also a couple commits related to PHP 8.4 support. Issue fixes and optimizations will likely continue to get more focus as we get closer to our next main/master version.There are also some Pro module updates in the works as well. Have a great weekend!

This week we've got several updates to the core on the dev branch. It's primarily focused on small issue fixes and optimizations. Though there's enough since 3.0.251 that I'm bumping the dev branch version to 3.0.252. Next week there won't be any new updates this time next week because I'll be traveling, but will be back right working on the core right after that. Thanks for reading and have a great weekend!

@Robin S I didn't intend for it to require PHP 8. I mistakenly was thinking str_contains and str_starts_with came in PHP 7.x. I've updated the download so that it replaces those function usages with strpos().

@BrendonKoz it should just be a matter of replacing the module files with the new ones. Then do a modules refresh. Then go to the module config page to setup throttling features. It should install the new ProcessRequestBlocker module automatically, which will appear on the Setup top nav menu.

@BrendonKoz I've got all those buts in our list as well, except for Bingbot. As far as I can tell, Bingbot follows the crawl delay, so is one of the good ones.

@BrendonKoz Great! Please let me know how it works for you. Any sense of which bots are causing the most trouble? The next thing I plan to build for WireRequestBlocker is a user agent counter/profiler, so that it's easier to identify problematic bots. That way you can throttle them specifically rather than throttling as general traffic.

@gebeer Throttling is what enables us to allow the AI bots, rather than having to block them for taking over the sites resources. So long as the bots adhere to the rules established in the robots.txt they'll never get throttled. But if they ignore the crawl delay, then those requests get throttled with a 429 error. We even include a retry-after header telling them when they can try again. I used to have to block these bots outright in order to preserve the resources for you and me. Now they can crawl as much as they like, so long as they follow the speed limit. The throttle feature provides a way to enforce the speed limit.

@bernhard I'm always interested in making updates to the modules directory, but over time as bandwidth is available to do so. So currently the modules directory does require a populated README.md in your GitHub repo. I'm definitely open to supporting more options, but short term you'd want to make use of what the modules directory currently supports. Any module missing a populated readme shows that message. For paid modules, that's a category called "premium modules", so if you add your module to that category it should show up as a paid module. The "since" date is the date it was added to the direcgtory.

Many websites these days are the feeding ground for AI bots. Especially this site! In this post we look at a tool for taming all the hungry crawlers and bots… https://processwire.com/blog/posts/throttling-ai-bot-traffic-in-processwire/

This week in the blog, we’ve got a new version of FormBuilder released, version 57. This new version of FormBuilder adds a lot, including… https://processwire.com/blog/posts/formbuilder-v57/

@bernhard Good find! I'm not sure I'd have ever found that. I'm still not sure what in that webmanifest file is responsible for it asking to install, or how it would even know where to get the files to install, but I'll read that link you included which I'm sure will answer it. Thanks!