Sometimes plugins and themes are managed by the host, and the WordPress install doesn't have the permissions to install them. When this happens, the Rollback can attempt to disable the plugins (which can result in the deletion of theme/plugin settings on a deactivation hook), and then break when it can't upgrade anyway -- leaving the site in a worse state than it began in.
Current Behavior
On Pressable, Jetpack and WooCommerce and some core themes (and likely a couple other plugins) are managed by the host and symlinked into sites that don't have write access to the files. This will break when someone tries to rollback Jetpack, and can result in data loss.
Expected Behavior
I would expect some variety of preflight checks before a rollback is attempted to ensure that WordPress has file permissions to modify the theme or plugin in question.
Bug Type
This bug describes functionality that never worked as expected.
Steps to Reproduce
Set a plugin's folder as root to not have write permissions.
Try to rollback.
See that not only does it fail but plugin settings may be lost as well as the plugin not reactivating.
Possible Solution
Add a pre-flight check before attempting a rollback to check for file permissions, potentially using wp_is_writable()
Acceptance Criteria
[ ] e.g. Something happens when an action is taken.
[x] e.g. Something does not happen when an action is taken.
[ ] e.g. Fixing behavior in Component A does not affect existing behavior in Component B.
Environment
Irrelevant.
Operating System
Platform: Mac OS X | Microsoft Windows | Linux | Android | iOS
Bug Report
User Story
Sometimes plugins and themes are managed by the host, and the WordPress install doesn't have the permissions to install them. When this happens, the Rollback can attempt to disable the plugins (which can result in the deletion of theme/plugin settings on a deactivation hook), and then break when it can't upgrade anyway -- leaving the site in a worse state than it began in.
Current Behavior
On Pressable, Jetpack and WooCommerce and some core themes (and likely a couple other plugins) are managed by the host and symlinked into sites that don't have write access to the files. This will break when someone tries to rollback Jetpack, and can result in data loss.
Expected Behavior
I would expect some variety of preflight checks before a rollback is attempted to ensure that WordPress has file permissions to modify the theme or plugin in question.
Bug Type
This bug describes functionality that never worked as expected.
Steps to Reproduce
Possible Solution
Add a pre-flight check before attempting a rollback to check for file permissions, potentially using
wp_is_writable()Acceptance Criteria
Environment
Irrelevant.
Operating System
Browser
WordPress System Info