You have updated one of our plugins or it was updated automatically and suddenly the plugin was deactivated due to a fatal error and can no longer be activated? This is a bug in WordPress Core and in this article we will explain you why this happens and how you can probably solve it.
Identify issue
Most of the time, after a faulty update, you will receive an email directly from your WordPress instance informing you that a plugin has been disabled due to a fatal error. You might find the following error message:
Warning: require_once(/wp-content/plugins/real-cookie-banner-pro/inc/base/others/start.php): Failed to open stream: No such file or directory in /wp-content/plugins/real-cookie-banner-pro/index.php on line 48
Warning: include(..\wp-content\plugins\real-thumbnail-generator-lite\vendor\composer/../devowl-wp/real-product-manager-wp-client/src/client/ClientUtils.php): Failed to open stream: No such file or directory in ..\wp-content\plugins\cloudflare\vendor\composer\ClassLoader.php on line 444
Ein Fehler vom Typ E_COMPILE_ERROR wurde in der Zeile 48 der Datei /wp-content/plugins/real-cookie-banner/index.php Fehlermeldung: require_once(): Failed opening required '/wp-content/plugins/real-cookie-banner/inc/base/others/start.php' (include_path='.:/usr/lib/php7.4')
Besides these examples, the error message can show up for any file name.
The error message Failed to open stream means that WordPress or your PHP server tries to open a file which does not exist. In our case these are plugin files which could not be moved during the update process. As you can see in the screenshot below, you will probably find only a part of the plugin files of e.g. Real Cookie Banner if you check the plugin folder via FTP. Normally you should find more folders like inc.
Solution to re-enable the plugin
As mentioned above, WordPress has completely disabled the plugin for security reasons, so your website is still accessible. You should now follow these steps to be able to use our plugin again as before:
- Log in to your WordPress instance.
- Navigate to your installed plugins.
- Scroll to the plugin which has been deactivated.
- Uninstall it completely (don’t worry, during the uninstall we don’t delete any data like folders in Real Media Library or your settings for Real Cookie Banner!).
- Download and install the plugin again.
- If it is a free version of our plugin, you can reinstall it by choosing
Plugins > Install. - If it is a purchased product, log in to our Customer Center and download the plugin again. Afterwards upload the plugin via
Plugins > Install > Upload. - If it’s a purchased product on CodeCanyon.net, navigate to codecanyon.net/downloads and download the plugin there again. Afterwards upload the plugin via
Plugins > Install > Upload.
- If it is a free version of our plugin, you can reinstall it by choosing
Avoid failed plugin updates in the future
As mentioned in the introductory text, this type of failed update is an issue with the WordPress core, meaning this can occur for any of your plugins (depending on the size of the plugin). WordPress itself is already aware of this problem, but is still “testing” and researching a solution. A temporary solution can be found by using the Rollback Update Failure plugin provided by the WordPress Core Team. Install this plugin and check if the problem occurs again.
If the problem still occurs, please post the issue directly to the WordPress Core Team, as this user did. Since we understand that the problem only occurs with automatic updates, but not with updates via a click on “Update” (the UI has a rollback mode already implemented), you can additionally disable automatic updates for the respective plugin.
Technical cause
You want to know why this problem occurs in the first place? We’ll try to summarize this in a short and understandable, but also technical way. A WordPress developer in a public ticket has attributed this to the following cause:
After […] there is an error when updating large plugins such as Gutenberg or WooCommerce. After debugging the issue, it seems to be due to a PHP timeout and depends on the server’s configuration (which is why the failure only occurs for large plugins). The way we delete a directory in PHP is by going through all files in that directory and deleting them one by one (as far as I know this is the only way). As a result, deleting or restoring a backup of a large plugin takes more time than expected.
This means, your server or the implementation, how WordPress updates, is simply too slow. If a plugin consists of many individual files, this can lead to problems. During the whole process, starting with zipping the old plugin folder, deleting the old plugin folder, unpacking the new version into a temporary folder and finally copying the new files into the destination folder, this can lead to a PHP timeout of your server (PHP only allows a certain amount of running time depending on the configuration). If the timeout occurs in the last step (when copying the new files), the process is aborted and the remaining files were not copied.
The WordPress team knows a potential solution and has documented it under a public ticket as well. WordPress would like to introduce a mechanism to automatically restore failed plugin / theme updates from a backup and generally speed up the copying of the new files. Since this is an experimental solution so far, it has been outsourced to a plugin: Rollback Update Failure (you can find the code location in the WordPress core of the outsourcing here).