My initial question has to be what is odd about your website? 

On the second of those – how can your server/browser NOT contain the user agent string? I am unaware of any setup that would allow for this although I will research it.

The first is even more puzzling as it suggests that you are not using the WordPress $wpdb database API. Do you have any ideas on that score?

The website is WordPress 4.1.5 running Karma theme 4.3. It is managed by the membership system Magic Members 1.8.51 collectively running now three years without any major error issues.  Simple:Press was added fourth quarter 2014, version 5.5.6 as of current, including all plugins being up-to-date.  Errors started accumulating mid-March.

The second question about the browser used, I cannot answer. Every browser type and device is being used to access the site, 3,700 members to date. The server is dedicated, which is running CENTOS 6.6 x86_64 standard, WHM 11.48.4 (build 2), Apache Version 2.2.26, PHP Version 5.4.26, MySQL Version 5.5.42-cll, Kernel Version 2.6.32-504.3.3.el6.x86_64.

I do not personally develop the plugins or any aspect of the WordPress architecture; therefore I would not have any idea about the implementation of the ezSQL class call wpdb. Access to the system could be provided if that would assist in locating the problem? Maybe setup a log to capture how the error is generated?

OK – so it turns out that you CAN have an empty user agent. I didn’t know this. I get the impression from reading up that it is rare and unusual but can happen. So – there is a fix in place for the next update to stop that annoyance.

The call to check_connection is a standard public function to the $wpdb EZSQL class so the suggestion seems to be that if this fails then it is because your $wpdb object has failed in some way. Which is unusual in the extreme just as this error is unique. And of course, if $wpdb has failed then it is hard to know what may have caused it because it could be literally anything on your site that interacts with the database.

Trapping such an issue is also hard, –  trapping in a trap in other words. I will need to give this some thouught and see if I can find a reliable way to replicate.

Fix contained in next update will work fine!

The current complication is no greater than the error file bulking up with repetitive entries. 5mb in 30 days is substantial though.  Is there a way with the update to purge the error_log file at the WordPress root? Many users will not have any idea how to delete the error file, or at the minimum, purging only the errors related to the API call and User Agent? A courtesy deletion script to run on update would be a kind gesture beyond the call of duty. Just a thought.

If you need access to our blog to ferret out the problem, let me know.

Thanks for your help!

I think it would be a dangerous and largely unwanted action to delete the log. If it were only for Simple:Press items then maybe but as the general php log it remains an important diagnostic tool for all involved in a website.

There is, sadly, also no way to control the size of the log. There are no php.ini settings that can be used for this – actually something I would love to see.

I do agree that most people running php based websites probably have no idea about the error log file buildup and if anyone reading this knows of any tools that might help then we would welcome the knowledge.

But – at the end of the day – the only answer I am aware of is the delete option!

And as yet I have no ideas about your $wpdb problem – leaving aside whether it is related directly to SP or not…

Thanks. The update to version 5.6 did cease the “Undefined index: HTTP_USER_AGENT” error string. Simple:Press users would do well to delete the error_log at the root directory to recover some space. My error log was filled to over 8MB with 1,000’s of lines of these error strings. No errors reported three days hence the update including all plugins and theme. Have a great day!

but most users wont see this odd one…  and remember, if we delete the error log, other desired info might from wp, plugins or other apps would be removed as well…