1 to 100 of 687951 (estimate) errors and website gone

[BFD Calendar]

My provider shut down my website www.birthfactdeathcalendar.net because my database is getting more requests than the Web Hosting plan can handle.

Matomo statistics tell me I have an average of 60 visitors a day.

But I'm getting plenty of errors - like 100 in one minute - in the ProcessWire log for all kinds of page requests:

• Error: Exception: SQLSTATE[42000] [1226] User 'birthfacbfdcal' has exceeded the 'max_questions' resource (current value: 8780)
  In /wire/core/WireDatabasePDO.php line 549

This started after upgrading from ProcessWire 3.0.123 to ProcessWire 3.0.246.

How can I solve this problem? I'm trying to go back to a provider backup from two weeks ago, before the ProcessWire upgrade, hoping to get my website back. For now I can still get into the ProcessWire 3.0.246 admin pages but I don't know for how long. I have several sql backups of my site and made a site profile today. Again I'm not sure how safe it will be to use them without running into the same problem — as long as I don't know what's causing them and how to solve them.

If anybody can help....

[BFD Calendar]

Update. I restored to a backup from two weeks ago provided by my provider. Now I'm getting an error on both front and back end:

Fatal Error: Uncaught Error: Class 'ProcessWire\InputfieldText' not found in /home/birthfac/www/wire/modules/Inputfield/InputfieldName.module:7
Stack trace:
#0 /home/birthfac/www/wire/core/Modules.php(1545): include_once()
#1 /home/birthfac/www/wire/core/Modules.php(1502): ProcessWire\Modules->includeModuleFile('/home/birthfac/...', 'InputfieldName')
#2 /home/birthfac/www/wire/core/WireClassLoader.php(202): ProcessWire\Modules->includeModule(Object(ProcessWire\ModulePlaceholder))
#3 [internal function]: ProcessWire\WireClassLoader->loadClass('ProcessWire\\Inp...')
#4 /home/birthfac/www/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module(20): spl_autoload_call('ProcessWire\\Inp...')
#5 /home/birthfac/www/wire/core/Modules.php(1545): include_once('/home/birthfac/...')
#6 /home/birthfac/www/wire/core/Modules.php(1502): ProcessWire\Modules->includeModuleFile('/home/birthfac/...', 'InputfieldPageN...')
#7 /home/birthfac/www/wire/core/WireClassLoader.php(202): ProcessWire\Modules->includeModule(Object(ProcessWi (line 7 of /home/birthfac/www/wire/modules/Inputfield/InputfieldName.module)

This error message was shown because: you are logged in as a Superuser. Error has been logged.

How to solve this?

[matjazp]

I suspect that restore was not complete, maybe some files are missing or permissions are not correct? Can you roll back to PW 3.0.123?

[ryan]

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

[BFD Calendar]

@ryan Well there were quite a few errors that occured after the upgrade from PW 3.0.123 and PHP 7.x to 8.2. Like in all templates "$feature->template==bfd_events" didn't work and needed change to "$feature->template=='bfd_events'".  Or "$webimage = $page->images->random()->url;" no longer worked. I managed to find out everything and got the site back working, when the above mentioned errors started appearing and my provider shut down the site. I went back two weeks in time with a backup option from my provider to make sure I'd get it all as it was before upgrading anything. But now I only see the first lines of the site, and the admin site is no longer reachable: internal error or misconfiguration. Even downgrading to PW 3.0.98 doesn't make any difference and of course now I can't even see any error logs as admin.

Other pages like https://www.birthfactdeathcalendar.net/phpinfo.php load normal. With my provider I upgraded my hosting to allow more resources.

The AI bot option might be the culprit, could it be Google trying to crawl/index the whole site? There are over 30.000 pages.... Report from Google Search Console: https://search.google.com/search-console/index/drilldown?resource_id=sc-domain%3Abirthfactdeathcalendar.net&pages=ALL_URLS&hl=en&sharing_key=N-nvEOUPuUWWfngX3zI85w.

[psy]

13 hours ago, matjazp said:

I suspect that restore was not complete, maybe some files are missing or permissions are not correct? Can you roll back to PW 3.0.123?

Had a similar nightmare today. Nothing to do with PW itself. Some files were corrupted during upload to the site.

Fix was to do a manual PW upgrade, ie:

1. rename wire dir to .wire-3.0.xxx (whatever version) and do the same for index.php
2. upload clean wire directory and index.php
3. To be on the safe side, I also re-uploaded site files I knew were clean

Everything then worked 100% as expected.

Hope this helps

 

[BFD Calendar]

@psy That's an option indeed. First I'll ask my provider why the backup version was restored corrupted. I do have older PW wire versions on my site, but none of them managed to get anything back. While I usually only add/edit pages and change almost nothing to modules or other PW settings.

[psy]

17 minutes ago, BFD Calendar said:

I do have older PW wire versions on my site

I didn't have the same version of PW locally either. I went to PW github and downloaded the next release version from what was on the site.

[matjazp]

active_connections

18446744073709551581

That's a high number. Can you limit access to your website to your IP address, so that you can login to PW? Can you put robots.txt with the

User-agent: *
Disallow: /

to the root of your website?

 

[BFD Calendar]

@psy Where did you find the older versions of PW on github? I'm looking for 3.0.123 as this was working fine for me.

@matjazp I uploaded that file but still can't login. As mentioned, I want to get my latest working version back working.

[matjazp]

https://github.com/processwire/processwire/archive/refs/tags/3.0.123.zip

[BFD Calendar]

Update once more.... I uploaded the last PW wire version and it worked, but the error logs showed problems with FieldtypeMapMarker, TextformatterHannaCode, Pages2Pdf. I replaced those manually with the lasted versions. Then everything worked perfect - for two hours. Now without any further changes the PW site is gone again due to internal server error. 

The overdrive in connections was due to an Amazon bot. So in the .htaccess I added 

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_USER_AGENT} (Amazonbot) [NC]
  RewriteRule (.*) - [F,L]
</IfModule>

and in the robots.txt I added

User-agent: Amazonbot
Disallow: /

In the provider error log for today there's only 

[Mon Oct 06 00:43:11 2025] [X-OVHRequest-Id: c27eb4c65e400e7a0437243896ebb722] [error] [client 72.14.199.130:0] [host www.birthfactdeathcalendar.net] AH01630: client denied by server configuration: /homez.863/birthfac/www/.well-known
[Mon Oct 06 07:40:25 2025] [X-OVHRequest-Id: 4f22632b5d87972a361b0b0f8841a1fb] [error] [client 51.57.57.231:0] [host birthfactdeathcalendar.net] AH01264: script not found or unable to stat: /homez.863/birthfac/cgi-bin

but the last entry is from 6 hours ago, after that everything worked fine for at least two hours.

I'm getting desperate, even more because everything worked perfect for two hours and then went dead just like that.

[ryan]

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

[ryan]

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