NIGHTMARE: Disables ALL other plugins on deactivatioin

Hey @brianhenryie

Our plugin cannot deactivates other plugins.

Please provide your site URL and we will check the issue.

Regards,
Stanimir

OK, I’ve a support ticket open with SiteGround for an issue: “failed to open stream: Too many open files”. I’m working to get more information for support now (trying to get a debug backtrace).

It was certainly the page load when I clicked deactivate on SiteGround Optimizer when all the plugins deactivated. We’ve activated/deactivated other plugins without issue since then. My guess right now is deactivate function runs early on WordPress load (I presume – makes sense) and the clearing of the cache by you resulted in too many file handles being used before any plugins were loaded. Then as WordPress tried to load the active plugins, and each returned an error rather than the file, it proceeded to disable each.

PHP Warning: fopen(/home/customer/www/domain.com/public_html/wp-content/plugins/woocommerce/woocommerce.php): failed to open stream: Too many open files in /home/customer/www/domain.com/public_html/wp-includes/functions.php on line 6109

This also leads me to believe the issue is unrelated to any plugins I have installed.

I think WordPress could mitigate against this by doing a test fopen on a known file before loading plugins. I might open an issue when I understand more.

You could mitigate against it by finishing your deactivate code with a check on a known file and run die() if you encounter an error.

This has nothing to do with our plugin. We do not disable other plugins in ANY case. Please, contact a develoepr or the hosting support if you need further assistance.

> We do not disable other plugins in ANY case.

You don’t mean to. But you definitely do.

I don’t want to get further into this argument but we most certainly do not. Please, contact the hosting support to get additional assistance on this problem.

Add this to the beginning of your deactivator:

$fopen_error_handler = function ( $errno, $errstr, $errfile, $errline ) {
	if ( false !== strpos( $errstr, "failed to open stream: Too many open files" ) ) {
		die();
	}
	return false;
};
set_error_handler( $fopen_error_handler, E_ALL );

And add this to its end:

restore_error_handler();

And YOU can help users avoid the issues your plugin is documented as causing.

“we didn’t design the car to do that, it was the road’s fault. We don’t need to add seatbelts.”

• This reply was modified 3 years, 9 months ago by Brian Henry.

We are definitely not adding this to our code. We can’t add checks for every other plugin that causes critical errors. That’s one of the reasons for the existence of critical errors, to stop the execution of a badly written code.

Again, I would recommend consulting a developer to get help with your plugin throwing errors and causing others to malfunction. Much easier than asking every other plugin out there to ignore the bad code.

If you want to learn more about the actual problem, please check out this link:
https://stackoverflow.com/questions/14748499/fatal-error-too-many-open-files

An error handler surrounding your own code, as suggested above, only checks for errors that occur while your own code is executing.

It would be but hubris to leave it out, knowing now what problems can occur.

I will not add unnecessary checks and bloat to million+ users just because of a fatal error thrown by a piece of bad code. That would be hubris. If you have any other comments please provide POC that we are actualy causing any issue, otherwise I consider this thread as closed.

Marking as resolved