Plugin deactivated after update

[stefanschulz]

Hi,

So I have the Panopticon Connector installed on several Wordpress sites. When I update a plugin via the Panopticon extension dashboard, the plugin does get updated. But afterwards, that same plugin is no longer active. I just tested this with current updates. This happens regardless what plugin gets updated, even Akeeba's very own Backup for Wordpress.

Am I missing a setting or something? Or is this on purpose?

Thanks and best regards,
Stefam

[nikosdion]

This is neither on purpose, nor something WordPress is normally doing. Since WordPress 6.3 plugin updates work like this:

• The update ZIP file is downloaded into a temporary directory
• The update ZIP file is extracted into a temporary directory
• The plugin's directory is moved into wp-content/upgrade-temp-backup under a temporary name
• WordPress tries to copy the temporary directory with the extracted update's files into the wp-content/plugins directory, and rename it to whatever the plugin's original directory was on your site.
  • If this succeeds: the wp-content/upgrade-temp-backup subdirectory with the copy of the pre-update files is deleted.
  • If this fails: the wp-content/upgrade-temp-backup subdirectory with the copy of the pre-update files is moved back where it was.

At no point does WordPress itself change the wp_options database record which contains the list of active plugins.

The only way an updated plugin would be disabled after update would be either if the plugin experienced a PHP error, or if a third party plugin has a hook or filter which gets called during the plugin update process (it's a thing!) and either does something stupid, or crashes. In the latter case, WordPress cannot tell the difference between the updated plugin crashing, or the third party plugin's hook/filter crashing, so it will end up disabling the updated plugin.

I know that our plugins update cleanly, without causing a PHP error, across all supported PHP and WordPress versions, so this leaves us with either a third party plugin doing something stupid, or something breaking on your host for another reason. In any case, this is not something I can help you with, as I don't have control over your hosting or third party code.

To make things difficult to debug, to an infuriating degree, WordPress has decided to mask all error messages which could point a developer to the source of the problem – not just from the browser output, but also from the server error log files. They do that by installing an idiotic exceptions handler which won't log most of these update errors even if you tell it to do so.

My solution to WordPress' dog breakfast of an exceptions handler is to install the file wp-content/mu-plugins/debug.php with the following contents:

add_filter(
        'wp_php_error_message', function ($message, $error) {
        if (!defined('MY_CUSTOM_ERROR_HANDLER') || !MY_CUSTOM_ERROR_HANDLER)
        {
                return $message;
        }

        $theMessage = $error['message'] ?? '(no message)';
        $file       = $error['file'] ?? '(no file)';
        $line       = $error['line'] ?? '(no line)';
        $context    = <<< HTML

<div style="border: thick solid red; border-radius: 1em; padding: 1em; margin: 1em 0;">
        <h4 style="margin: 0 0 0.75em">$theMessage</h4>
        <p style="margin: 0">$file:$line</p>
</div>

HTML;

        return $context . $message;
}, 10, 2
);

then edit wp-config.php to add

define('MY_CUSTOM_ERROR_HANDLER', true);

just above the /* That's all, stop editing! Happy blogging. */ line. This file and this constant install an alternative error handler which preempts WordPress' asinine code, outputting the error message, so I can troubleshoot the problem at hand. I suggest you do the same.

[stefanschulz]

Ok, interesting. This happens to me on multiple sites, which are hosted with three different providers. I will set up one of them with the code you suggested and see, if I get lucky.
I'll report back.

Thanks for the advice,
Stefan