This is primarily an attempt to fix #141 (accidental overwriting of a plugin) which was caused by a case sensitive check for plugin owners.
However, fixing this requires the ability to remove the offending plugin. Which means that #88 needs to be solved at least through an admin action. This is the harder part, and this PR really exists as a review for the code involved in this portion.
Once this lands, we can also fix #138 (spam plugins).
Make plugin names case insensitive in the plugins table.
Added maintenance script to update collation of plugins table.
Moved post utility methods from wordprss-update script to wordpress m…
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:
Added script to remove a plugin release.
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.