Attempt to read property 'title' of non-object

[BFD Calendar]

Updated to ProcessWire from 3.0123 to 3.0.246 with PHP from 7.3 to 8.4 and getting plenty of errors "Trying to get property 'title' of non-object" and more on https://www.birthfactdeathcalendar.net. Where did it go wrong and/or how to solve it? 

[BFD Calendar]

Apart from plenty of '500 Internal Server' errors, I'm also getting a bunch of these ones:

Error: Exception: SQLSTATE[HY000] [1203] User [database-name] already has more than 'max_user_connections' active connections 
In /wire/core/WireDatabasePDO.php line 549

[BrendonKoz]

Did your upgrade of PHP perhaps change from CGI to FastCGI, or even FPM? There might be a resource utilization difference there, as I don't believe the upgrade of ProcessWire would cause SQL error states like that.

I'm not sure if ProcessWire is fully PHP v8.4 compliant yet. You should be pretty safe with PHP 8.2, and maybe PHP 8.3. The errors should be, if I'm not mistaken, warnings, however, not actual errors.

[BFD Calendar]

Same happens with PHP 8.2, and even PHP 7.3 on another website with same provider (OVH.com). It has been FPM/FastCGI all the time (https://www.birthfactdeathcalendar.net/phpinfo.php). It shows up in the logs as errors but doesn't interfere much with the site itself. The site often loads slow and has many '500 Internal Server' errors that I'm trying to resolve, hence my upgrade of ProcessWire and PHP.

[BrendonKoz]

When I load up your site, although I'm seeing JavaScript errors, I'm not currently seeing any 500 errors in the browser console for loading up any assets. Have you identified and fixed all of the issues, or are the problem(s) you're experiencing not 100% repeatable? Database errors sound like a resource issue. If the 500 errors are related to a database issue, are there particular pages that show the errors more often than others? Do those pages have a lot of requests to pull in data for display of content? Can things be cached to alleviate database resources and PHP processing? Have queries made through the ProcessWire API been reviewed for efficiency?

Since I'm not seeing the errors myself (or any errors that point to specific files), I'm only speculating. It's hard to know what to suggest. Do you have any further specifics? Any non-core modules installed? Any hooks being run?

[BFD Calendar]

I'm monitoring the ProcessWire logs to find eventual PHP errors that needed a change by upgrading ProcessWire and PHP. Some old PHP was not recognised anymore, but most of that is done now. Most pages get some content (images) from external websites, usually just one per 'person'/page, and several on queried pages, like ' $features = $pages->find("parent=/events/|/the-eyes/, bfd_day.name=$todayday, bfd_month.name=$todaymonth, sort=bfd_year"); ', giving a list of events for 'today' with an average of 30-40 features. It all went well for over 10 years and without any notable changes the problem occurred and got worse.

The problem affects the whole website, same when I call the home page or any other page including admin pages, even the Matomo statistics sometimes give a 500 error.

From the hosting error logs I get many '[Wed Sep 24 00:08:51 2025] [X-OVHRequest-Id: 1d8b279cbdb0de4b3c5dad4c408a1f98] [error] [client 34.174.60.244:0] [host www.birthfactdeathcalendar.net] AH10141: FastCGI: comm with server "/homez.863/birthfac/www/index.php" aborted: idle timeout (160 sec)' errors. I filed an error report with them and wait for reply.

There are no hooks used anywhere, site modules are up to date and give no errors at all in the logs. With an average of 30 visitors a day it's not extremely busy either. There are however over 33.000 pages.

[BrendonKoz]

Could the idle timeout be caused by FastCGI waiting for an available PHP process due to too many active requests? Our site has been having outages within the last couple months, seemingly due to an increase in requests/visits by bots (crawlers for AI-specific data harvesters). Although I believe the server should be able to handle these requests perfectly fine, our host has said that seems to be our issue. I only bring it up since you seem to have mentioned it started somewhat recently (coincides similarly to our timeframe).

If that is the case, the solution(s) would be upgrading to a beefier server, implementing caching solutions, attempting to block bots (ex: robots.txt, htaccess rules, etc.) and/or using Ryan's new [updated] Pro module (Request Blocker + Throttler), and examining all PW find requests to see if the raw versions of those API requests might be faster/more efficient...but yeah, caching mostly.

Hopefully your host can give you some more insight. Our server log errors are a little different (webhost: Dreamhost):

[Tue Sep 16 05:29:37 2025] [example.com] [warn] [client xxx.xxx.xxx.xxx] [pid 13103] fcgid_bridge.c(481): mod_fcgid: can't apply process slot for /dh/cgi-system/php82.cgi

Once FastCGI hits a limit, it affects all rendering of the entirety of the website since it's linked to the webserver itself.

Since removing some AJAX loading calls (that rendered PHP and made database calls) that were loaded on every page, a CSP report functionality, and adding Ryan's Request Blocker + Throttler, our site's total traffic (requests) has reduced 21% (from an average of 120k+ hits/mo), and stability has been better. I cannot say this is the same issue, I simply see comparisons, and since not much else has changed with your site, and PW is fairly stable overall through updates, I don't know what else it might be right now.

[BFD Calendar]

Thanks! I'll see what our host (OVH) says and keep you posted.