After I wrote the removal script, I realized that it can't happen in a script like this. The removal needs to be logged in the actions table, which means the actual removal needs to happen in wordpress-update.

We also need to handle a few other cases:

• When the last release is removed, the parent page needs to be removed and the plugin needs to be removed from the plugins table so that a new plugin with the same name can be published by anyone.
• If the most recent stable release is removed, a pre-release may need to be listed. I think we're throwing away this information right now, so we might need to write another maintenance script to gather that data again and add it to the existing plugin posts.

The removal is now tracked in the actions table and handled by wordpress-update. Neither of the two cases I mentioned are handled yet. My biggest concern is fixing #141 ASAP, so I'd like to just land this and then work on the other two cases after.

This can't be tested without going through the restore process (to create a full local copy of production). However, the restore process can't recover from a plugin repo no longer being available. That's already the case with at least one plugin. I'm going to change update-server to pull all the data we care about and amend the manifest so that we no longer depend on the repository existing at all during a restore (or even when publishing to WordPress during normal operation). I'll also need to write a script to update all the data in plugins.db and WordPress.

Should we land this scott? Could we use it to help us clean up all the dupes we generated?

There are likely several days of work left to make it possible to even test this.