-
Notifications
You must be signed in to change notification settings - Fork 645
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backup database before uninstalling a plugin #2672
Comments
I would fall strongly on the side of a plugin should clean up after itself. It is my opinion that if a plugin creates data, the plugin should remove data (tables etc.). But I strongly sympathize with the data-loss side of things. A database backup before a plugin is uninstalled could potentially have a huge benefit. It's a fact of life that people will blindly click on buttons without reading warnings (I've certainly done it many times). Having a database backup could potentially save people from irrevocable data loss. |
Guys, not involved with any emojis on messages here, but let's be thoughtful about the situation of the release -- both ways.
Let's help the release be smooth, with full confidence because of our long experience with the Bend (and further...) persons. |
I could have the FR wrong, but I don't think he's saying this has to be a thing "before" the launch. I took his mention of it as humor. I certainly would be in favor of this feature being after the launch. |
Yeah, I don't think @putyourlightson intends for this to be urgent. He's only apologizing because it's pretty safe to say that P&T would prefer to have zero tickets come in today. This FR is a strong "nice to have", but by no means a dealbreaker for tomorrow's 4/4 release. |
Do we need the same before any of these actions?
|
You could make a case for a site, but not likely for users, sections and fields. Either way, I think this feature request should remain just about uninstalling plugins. |
@putyourlightson I should have added a sentence or two to my comment, it was only meant to provide food for thought. I’m undecided whether or not automated backups triggered before plugin uninstall (or any of the actions I mentioned) is the right answer to guard against data loss, as it comes with a cost. Backups consume time and storage space, which can be annoying when you either know what you’re currently doing or when you know a backup was made shortly before, e.g., uninstall multiple plugins in a row. The most common data loss in Craft installs is most likely caused by deleting users (from what I’ve heard). There are a couple of good alternative suggestions in #875, from clearer warning to the idea to let users enter their password again. Please don’t understand me wrong, I’m not against this FR per se. |
Yeah I totally agree that this is part of a bigger issue, which likely has nothing to do with software, but with a lack of awareness (or implementation) of regular scheduled backups. There are options (Enupal Backup), so I wonder what if any precautions devs are putting in place. Maybe it's time to port the Dump plugin to Craft 3. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
With Craft 3, a plugin's tables are not automatically deleted when the plugin is uninstalled, so it is left up to the developer to manually do this in the
Install.php
file. After some discussion in Slack, it seems that some plugin devs (me included) believe that a plugin should always clean up after itself, in other words leave no trace after it is uninstalled. Other devs seem to be fine with leaving data around, with the argument that data can potentially be accidentally lost in the uninstall process.Please excuse the timing of this (the eve of 4/4), but this is a feature request for a database backup to be made before a plugin is uninstalled. That way devs can ensure that their plugins leave no data in the database, and users can be users (and make mistakes).
I'll understand if you prefer this to be implemented as a plugin, as it should be easy to do using the
beforeUninstallPlugin
event.The text was updated successfully, but these errors were encountered: