Codex says about deleting options on uninstal

//note in multisite looping through blogs to delete options on each blog does not scale. You'll just have to leave them.

I am not very hopeful, but is there any established scalable way to do that? In theory you can have an uninstall utility plugin but I never heard of anyone actually doing that so is it just a bad idea, or is it just a case of no one actually caring enough about the garbage left in the DB?

  • 1
    I wonder how they do it on wordpress.com, where the number of sites is huge? – birgire Mar 16 '16 at 14:31
  • 1
    @birgire Maybe tom will pass by and will shed some light on it. I assume that they just never uninstall – Mark Kaplun Mar 16 '16 at 14:39

Because it is a wiki, the codex is a notoriously unreliable source of information (but you probably already knew that). However, it is probably true that uninstalling on huge networks will not scale.

What I do in one of my plugins is run the plugin's uninstall routine on all sites, unless wp_is_large_network() is true. On a large network the plugin just assumes that it wouldn't be able to run the uninstall properly, and so it doesn't attempt it.

Another thing that I do is have the plugin keep track of which sites it is actually installed on (when it isn't network active), that way it will uninstall on each of those sites, regardless of the size of the network. So if there are 20000 sites on the network but the plugin was only installed on 3, it will uninstall itself from those 3 sites.

I think it is also important to keep in mind that people that are running huge networks are going to be dealing with this sort of thing all of the time (each time they update WordPress, for example). They understand that install/update/uninstall won't scale in most cases, so they have to write their own scripts for that a lot of times anyway.

So in my plugins I basically just focus on providing the basic uninstall routine, running it when it should scale, and showing the admins a notice when it probably won't scale and so the plugin doesn't attempt it on its own.

Update (2015-03-16): I just remembered that there is a trac ticket related to this discussion: #14170, especially from this comment on is very informative as to why it was decided that core itself wouldn't provide an API for this. The ticket also contains some good advice on optimizing for multisite:

The reason why I am against this in core is demonstrated precisely by your plugin. Looking through it, you're creating an awful lot of tables. You are creating six tables per blog. That can't scale in any reasonable fashion.

No network administrator would let that on their site, given plenty of other plugins with far less footprint. I'm weary of plugins having an official API to do things like this. If someone wants your plugin on their network, they're going to look to disable all of that so they can generate those tables on their own. (It took something like two weeks to generate commentmeta tables for every site on WordPress.com.)

Sidenote - A lot of those are lookup tables and should probably be global tables. The ones that aren't can be post types. Then you won't need to do this at all.

  • sounds like a great answer, wasn't expecting any at all :) will see what other people might have to say first but it sounds like a winner :) – Mark Kaplun Mar 16 '16 at 15:40
  • @MarkKaplun I'm also curious to see if anybody else has some input. BTW, I've added an update that includes some info from a related trac ticket. – J.D. Mar 16 '16 at 19:50
  • looks like no one has a better idea.... – Mark Kaplun Mar 17 '16 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.