Case insensitive names & ability to remove a release

jquery-archive / plugins.jquery.com

The jQuery Plugins site

plugins.jquery.com

Other

1.24k stars 243 forks source link

Case insensitive names & ability to remove a release #142

Closed scottgonzalez closed 8 years ago

scottgonzalez commented 11 years ago

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).

scottgonzalez commented 11 years ago

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.

scottgonzalez commented 11 years ago

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.

scottgonzalez commented 11 years ago

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.

gnarf commented 9 years ago

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

scottgonzalez commented 9 years ago

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