What happens to mod data when a mod is uninstalled ?

Started by Arantor, November 14, 2009, 07:55:40 PM

Previous topic - Next topic

Arantor

The question came up earlier on what happens to the database when a mod is uninstalled, and I wanted to share what happens, plus also how to remove the data left behind.

As a general rule, nothing is done with the data when a mod is uninstalled. Whatever a mod author adds will invariably left behind, untouched.

While this does of course take up space on your database, it does mean should you reinstall the mod later, the settings and related information are still available.

The mod's author generally has to specifically add code to clear out changes to the database in the mod's uninstall script. Let me clarify one point: there is no requirement in the mod approval guidelines for them to do so.


2.0 does make some move towards resolving this. If the mod author codes the install script to use <database> instead of <code>, the uninstaller will offer the forum admin the choice of removing data. This is generally limited to new tables and new columns added by the mod only, not every possible thing. Indeed, it would be virtually impossible to guarantee no trace is left behind, unless each mod had an uninstall script.

So, what about other things? And what for 1.1 ?

Well, there are four places data is likely to be stored by a mod, which can be cleared up after it has been removed.

1. New tables
You'll notice these because you will have more tables than you started with, and invariably the table(s) are named in relation to the mod in question. E.g. for a mod called Favourite Boards, a table called favourite_boards is a likely prospect.

Identifying them: In the package-info.xml file, you'll see 1+ <install> blocks which refer to different versions. In there will be a <code> or <database> entry referring to a PHP file. That PHP file makes the database changes, and will contain one or more lines like CREATE TABLE, or $smcFunc['create_table'].

You can use those to determine which tables were added. If you have removed the mod and you are sure you have removed it, you can safely use phpMyAdmin to 'drop' those tables after you take a backup - just in case.


2. New columns
Sometimes it makes sense to push the new data into new columns against one of the tables already in place, for example a new setting for membergroups will likely fit in well in the membergroups table.

Again, the install PHP file will tell you where to look, you'll see ALTER TABLE ... ADD COLUMN, or $smcFunc['db_add_column']. You can use phpMyAdmin to remove the column but PLEASE take a backup first.


3. Settings table
Many mods add their own settings into the settings table, normally smf_settings. Unfortunately picking these out is a lot harder since you will need to examine the mod's code to work out which values were added, and that can be safely removed from the settings table - one row at a time.

There is a list of almost 200 settings in a default install, so it's quite hard to tell whether you can remove settings or not, though it's good practice for mod authors to prefix mod settings with something relating to their mod. For example, if you're removing a mod called Auto Lock Old Topics, you'll find a number of settings whose name begins with autoLock, and the mod's code will refer to settings through $modSettings['autoLock...'].

As ever, backup before removing.


4. The themes table
Daft as it sounds, the themes table stores some user details, typically when there are multiple rows per user to store. Most profile modifications store them in here, for example. Again, you'll have to look through the mod itself, especially to mentions of default_options as that's often where the settings will end up.


If in any doubt over whether it's safe to remove anything from uninstalling a mod, please do ask in the mod's support topic, and failing that please ask in this board, and we'll see what we can do about it.

Kenny01

That's a great write up from Arantor, Thanks.
With this info, it doesn't worth it installing mods as you can't completely remove it.

It's better smf make the vitals mods as core, just done aleady in SMF 2.

Kays

Very interesting. Thanks for posting that. :)

Quote
2.0 does make some move towards resolving this. If the mod author codes the install script to use <database> instead of <code>, the uninstaller will offer the forum admin the choice of removing data. This is generally limited to new tables and new columns added by the mod only, not every possible thing. Indeed, it would be virtually impossible to guarantee no trace is left behind, unless each mod had an uninstall script.

Does <database> also remove anything added to the settings table if it was added by the install scrict?

Or is there a way to make an uninstall script optional?


If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

kingkingston


Arantor

Quote from: Kays on November 15, 2009, 07:49:49 AM
Does <database> also remove anything added to the settings table if it was added by the install scrict?

No, it doesn't as far as I know. It also - as far as I know - doesn't remove rows inserted into regular tables. I was having trouble with this in a mod to create scheduled tasks, actually, where <database> would remove the extra tables but wouldn't remove the extra row in the scheduled_tasks table.

As for making it optional... good question. I haven't tried a <database> entry for 2.0 to see if it gives the option or not.

Advertisement: