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. 

[BFD Calendar]

@ryan The $config->debug is set to true. The errors.txt is a hefty 257,8MB file.... The last lines are 

2025-10-06 22:26:49    ?   https://www.birthfactdeathcalendar.net/places/hobart-tasmania-australia/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)
2025-10-06 22:26:55    ?   http://birthfactdeathcalendar.net/events/18-june-2024/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)
2025-10-06 22:27:03    ?   http://birthfactdeathcalendar.net/people/van-zon-hans/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)
2025-10-06 22:27:08    ?   https://www.birthfactdeathcalendar.net/places/holmby-hills-california-united-states-232-mapleton-drive/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)
2025-10-06 22:27:11    ?   http://birthfactdeathcalendar.net/events/31-august-1986-b/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)
2025-10-06 22:27:19    ?   https://birthfactdeathcalendar.net/events/dates/november/4-november/  Fatal Error:  Class ProcessWire\FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ProcessWire\FieldtypeHasFiles::hasFiles, ProcessWire\FieldtypeHasFiles::getFilesPath) (line 18 of /home/birthfac/www/wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)

The wire is now 3.0.246, uploaded from processwire-30246-master. It's now visible if you go to the site.

In this log there are still 11 or 12 errors per minute, so I presume there are still bots targeting the site. Apart from the Amazon bot mentioned earlier I also stopped Google Search Console, so it's hard to tell where they keep coming from.

[BrendonKoz]

I would recommend deleting the errors.txt file (if/when you have access to the PW admin, it's under Logs -> Burn [while viewing that log; expand "Helpers" at the top, and then "Actions"]), or if not deleting, pruning it. I suspect that log has lived since the website has been running. It's unlikely you care about errors from 2 months ago or more - just the recent issues. I leave that decision up to you, but having an error log that large is unlikely to be useful (at least for me).

I think it would be good to fix the errors that are popping up first. Your upgrade of the /wire/ directory is the first step; making sure the modules you have installed and enabled are up-to-date is another (and maybe you have some that aren't fully compatible?). Then making sure each template no longer has any problems (since we're working on a newer version of the core, it's unlikely but entirely possible).

If you don't yet want to invest in additional development time to implement ProCache, you could try the built-in template cache as a quick test to see how your website would behave with that enabled. This would be good for pages (URLs) where the content doesn't change often. The cache is rebuilt after a set period of time, or when changes are made to the page, or its template. To enable template caching, go to the template you might want to try this on, head to the "Cache" tab, then enable it and choose the settings you think would best suit your site's template.

[BFD Calendar]

@BrendonKoz As said above I can't get into the PW admin interface anymore. No matter what page is called, everything gets stuck at

Uff da… Fatal Error: Class FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (FieldtypeHasFiles::hasFiles, FieldtypeHasFiles::getFilesPath) (line 18 of wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module)

This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged.

I can access the errors.txt file via ftp. For today (2025-10-07) only there are 19092 errors as above. In my provider's error log I can see plenty of 

[Mon Oct 06 20:26:03 2025] [X-OVHRequest-Id: 0b8c2f578748d1061d5e670a11218ce2] [error] [client 54.161.50.125:0] [host birthfactdeathcalendar.net] AH10157: FastCGI: An error happened during Fastcgi processing, fallback to CGI
[Mon Oct 06 23:52:49 2025] [X-OVHRequest-Id: da62e0ad0f08ee270e46e69c4cdbb0b7] [error] [client 51.57.57.231:0] [host birthfactdeathcalendar.net] AH01264: script not found or unable to stat: /homez.863/birthfac/cgi-bin

All those are Amazon and Microsoft ip addresses. Apparently the robots.txt file doesn't keep those away.

I manually replaced the latest wire and all site modules are up to date. Template errors that showed up earlier are all fixed. But as long as I can't get past the Fatal Error there's not much more to do or try I presume. And the most baffling thing is that everything worked fine yesterday for about two hours, without any further change the Fatal Error just popped up.

[BrendonKoz]

Sorry, you've said you could, and couldn't a few times, I wasn't sure what was currently accessible anymore.

Are you able to develop this website locally, off of the live production server, in an environment that you control? Due to the restoration process from your host seemingly not working as expected, it would be nice to get the filesystem to a properly restored and working point, and developing locally might be the simplest option.

[BFD Calendar]

@BrendonKoz No, I do everything on the site hosted by OVH provider. I've done it for 12 years now and it has over 30.000 pages. You can see how it actually looked like on 24 June 2025 here: https://web.archive.org/web/20250624203839/https://www.birthfactdeathcalendar.net/.

I have a database backup from the PW module 'bfd_20251003_processwire.sql'. So do you mean installing a fresh PW site on a local computer, install all the site modules and templates, and import the sql database? That simple? I'm an artist (https://www.performan.org/exhibitions/), and not really a coder....