I agree with one of the previous reviewers that this requires a system cron to truly make WordPress immune to fatal errors. I’ve had plenty of plugin updates cause fatal errors when they shouldn’t, and the code added for rollback in 6.2 for manual updates doesn’t do anything solve it unfortunately.
If you can give me a stringent list of requirements for that cronjob to ensure that fatal errors can be rolled back in the way that user mentioned, I can try to write some code for it. In my opinion, it’s critical for this feature to function correctly, and I’m willing to give it a shot so for my own sake as well as others.
]]>I installed, Activated ‘simulate failure’ for a plugin that needed updating. Hit the update button. As expected it returned a failed message. Went to the directory specified (wp-content/upgrade-temp-backup/plugins) but backup not there. Directory empty. Yes it’s writeable. Tried uninstalling and reinstalling – same result? I’m on WP 6.22 latest version of plugin?
]]>Hello,
This plugin is flagged for not being compatible with 6.1 versions and only 6.2. However v6.2 is not released yet?
Kind Regards
]]>I installed Rollback because Mailpoet updates were failing and the plugin was deactivating instead of rolling back. THIngs seemed to be going swimmingly till this week. A Rollback update failed. Then Mailpoet deactivated itself. These were the reasons I installed Rollback–to prevent this happening.
]]>Hello!
I’ve got a multisite installation of WordPress and I just noticed when I had WP_DEBUG
and WP_DEBUG_DISPLAY
enabled that there’s an error going on. I don’t know if it’s affecting anything but just wanted you to be aware.
Warning: First parameter must either be an object or the name of an existing class in?/[redacted for privacy]/wp-content/plugins/rollback-update-failure/testing/failure-simulator.php?on line?72
The plugin version is 3.3.1 and the WordPress version is 6.6.1. Cheers!
]]>Hello! Really interested in this feature as someone who maintains a couple dozen websites for clients and ensures they are up-to-date.
One thing I was wondering was whether there was an option to tell the plugin to hold onto the backup after an update, possibly with a manual “flush the cache” option for once we’ve verified that the updates have, in fact, not damaged the site in any way.
The reason I ask this is that while certainly a failed update can leave a site in a lurch, my biggest problems as a webmaster have stemmed from updates that worked and then caused problems that needed the update to be reversed after the update (like when Yoast Premium put out a bad update about six-eight months ago). Being able to restore from the backup (even if I have to go into FTP and manually copy the old version back to wp-content/plugins) would be a *really* handy feature.
Thanks!
]]>I’m not sure what to make of this error but I was under the impression that the rollback update failure plugin would prevent this.
So this is what happens:
/wp-admin/plugins.php
on my website, I see the notice: The plugin the-events-calendar/the-events-calendar.php
has been deactivated due to an error: Plugin file does not exist.Of course, between the time it failed and me re-adding it, the plugin is not functional. It might be that I don’t understand how your plugin works, but as I said, I was under the impression that it stores the current version in a temp folder, then on update failure, it restores that version.
I would rather get a notice saying, “A plugin update failed and was rolled back to version X.” when I log into the website. Then I can either update it manually or let it automatically update at it’s next interval. Whichever.
I’m just trying to figure out how to manage all of these automatically updating websites without them going down for hours while I sleep (and preferably not having to manually update them), so any help is appreciated!
]]>Hello,
I have two questions to ask about this feature/plugin that will be included in the core.
The first question is about security. If an update fails and creates a fatal error, this feature will automatically rollback the previous version of the plugin, ok. So it means that a plugin security update cannot be applied if it causes a fatal error, for example because it is incompatible with another plugin. Is it better to have a broken site or a vulnerable site? For me it would be better to have a broken site that needs to be fixed, but maybe for others it isn’t.
The second question is about database.
How can we introduce a rollback procedure, which does not include a possible rollback of the database as well? If a plugin introduces a change to the db, the automatic update fails and the automatic rollback comes into operation, would we have a misalignment situation on the site?
I mean, the rollback can be associated with a restore operation,right? Are we sure that restoring only files is okay 100% of the time?
]]>Is this compatible with plugins that I’ve enabled auto-updates for? Like if those auto-updates fail, will it automatically roll it back to the previously installed version?
This would be incredibly helpful because I noticed a few versions of Wordfence and Yoast would automatically update, but then the next time I logged into my site, it said the plugin was deactivated due to missing files (something in the automatic update failed).
I would like to ensure my sites remain protected and functioning until I can manually get around to sorting out the failures because if those fail while I sleep (I set the automatic updates to be at off-hours so scheduled maintenance times don’t occur during peak traffic), who knows how long it’ll be until I get around to fixing them.
Honestly, that’s the whole reason why the auto-updates is kind of putting me off. I simply can’t trust it to always work. This would be an amazing failsafe for that.
]]>