Ambyomoron

My hosting provider has come back with the following remarks:

This type of error often comes from keeping a mysql connection open without making any requests after a certain time, after which the connection is shut down: https://dev.mysql.com/doc/refman/5.7/en/gone-away.html

The variables wait_timeout and interactive_timeout which control this disconnection are set for 30 seconds: https://dev.mysql.com/doc/refman/5.0/en/communication-errors.html

>It’s enough if the script does a “ping” regularly to avoid this problem; better still, before sending a request, test to see if the connection is still live and if not, restart it.

Can someone tell me if:
1) the 30 sec timeout corresponds to something recommended by WordPress; and
2) whether the wordpress code performs the suggested check, namely, it does not assume that a Mysql connection is alive before using it; rather, it checks first and reconnects if necessary.

Brett,
Are you referring to WP_MAX_MEMORY_LIMIT or to WP_MEMORY_LIMIT or to both?

It’s a shared host.
So what you’re suggesting is that the database server is undersized relative to certain peak loads put on it, is that right?
Why would this happen only when updating a plugin and not during other transactions, such as saving a blog, or something else?

Thanks for that clarion explanation. So, if I add authentication to the wp-admin folder, what will no longer work?

Yes, that was it. Thanks for your help.

Thank you. I will alert the plugin author and then decide if the plugin author is the dupe or the villain.

It’s a plugin. A prefer not posting in a public place information about what might be installed in my system, together with its putative vulnerabilities. I would be happy to send the file to a private address at wordfence.

Once your fix is deployed for this, it would be nice to know if there is a way to force whatever it is the wordfence is doing, so as to check whether the problem has been fixed.

BTAIM, I don’t really understand why wordfence should be moving my redirect commands, which were outside of any blocks created by and managed by wordfence. This seems to me to be a very dubious thing to do.

Thanks for confirming that, Matt. It saves a lot of time. “r” is a very unfortunate letter in .htaccess, what with all the redirects, etc.

Well, that was my question. The standard WordPress admin interface does not, to my knowledge, offer a “clear the cache” function. So I wanted to know if I could simply delete the offending files. I am not, by the way, using the caching functionality of Wordfence, nor am I using any generic caching plugin (although certain plugins are maintaining their own caches).

I presume you mean “visits” and “visitors”. They are both unchecked.

I checked the database and there are no rows in the table with the page definitions where the ID is null. The particular posts mentioned in the error messages all exist and the page id is correct for the post. It’s fine to handle null values, but whyever should there be a null value in the first place’

Thanks for the tip about plugins that look for changes, presumably unauthorized. I was hoping to be a little more proactive than that. If someone is monkeying around, making requests they have no business making, I am thinking about blocking access via .htaccess. I know there are limits to that approach, though. By the way, if an ip address is blocked in .htaccess, does the access attempt even appear in the web access log? If so, with what error code?

I have additional information from my hosting company. There is indeed an issue with the definitions of the groups. The owner of the wp-config.php file (that is to say, the account of the person who uploads it to the server) does not belong to the same group as the Apache httpd account, which is the account that runs the php file. If the public is not given read permission to the file, then Apache cannot see it and run it.

It is clear that the ftp and the httpd accounts can simply not be the same in such environments. I suppose the hosting company feels that it must harden access to Apache by making sure that customer accounts cannot be in the same group as the Apache account. The tradeoff is that access to the personal or company data in the WP database and access to the WP scripts are somewhat less hardened.

I would be interested in hearing views on the pros and cons of this tradeoff.