Add "Delete this plugin" button on Admin page

[Ipstenu]

Example: ​https://wordpress.org/plugins/akismet/admin/

On that page, below committers have a button only the PRIMARY admin can see that emails plugins@ with a deletion request.

Optionally anyone with commit access, though in some cases that strikes me as ... iffy?

[DrewAPicture]

Replying to Ipstenu:

Example: ​https://wordpress.org/plugins/akismet/admin/

On that page, below committers have a button only the PRIMARY admin can see that emails plugins@ with a deletion request.

Optionally anyone with commit access, though in some cases that strikes me as ... iffy?

Good idea!

I agree on only giving the primary admin the button. Often times collaborating committers are just that, I don't think I'd want every committer to have the option to delete a group plugin.

[Ipstenu]

The only real change it makes to us as plugin repo mods is that there's a hidden 'primary owner' value we can see that they can't, and we'll need to remember to change it when a plugin's handed over. Small price to pay for easier abandons.

[coffee2code]

I don't see a problem with giving the ability to close a plugin to any plugin committer. After all, each committer could delete all plugin files and pretty much do whatever is allowed by plugin owners if they wanted. Closing isn't any more dangerous of a capability for committers.

Also, as @Ipstenu notes, the primary owner of the plugin is not an actively maintained field and may not accurately reflect the current owner (or even a committer). Singling out a sole owner runs counter to our desire to promote a more collaborative development culture around plugins. And it adds some unnecessary support for Plugin Directory admins in having to update and manage the primary owner field, answering why certain committers can't close the plugin, etc.

In practice, yeah, it can be a little iffy because we don't currently have a functional role for plugins between no role and committers. Such an in-between role would accommodate those who have elevated privileges but not commit (as would be used to grant support forums privs for the plugin). See #1413. So some plugins do currently give commit access to their support forum staff. But that's never been an approach we've advocated, and what I propose below (and definitely if in conjunction with #1413, if we're too worried it'd be too easy to close a plugin) would address this use case.

Here's what I'd suggest:

• Add 'Close this plugin' button to the admin page as proposed ('Delete this plugin' is a bit misleading since we don't actually delete anything).
• Above the button, add a descriptive paragraph/list explaining what happens when they click the button. (What "closing" a plugin means, reasons to close (and not to), the process involved for un-closing a plugin.)
• When clicked:
  • Email all committers to let them know the plugin was closed by X user. (That way, like commits, they would get notified.)
  • Email plugins@ with a message indicating the plugin was closed by X user.
  • Directly close the plugin rather than it being a request submission. If we have adequate prefatory text, the author will just have to deal with any ramifications of doing so (e.g. having to submit a request to re-open with an explanation of why they want to have it re-opened, having to wait for a full review of the plugin, etc). And it saves Plugin Directory admins some effort.
• For plugins that are already closed, replace the 'Close this plugin' button and text with an explanation about the plugin being closed and information about how to request re-opening the plugin (even if it's largely a link to plugin developers handbook).
• (Possibly:) Provide a textarea for the user to supply a reason for closing the plugin. This would be included in the emails to all plugin committers, plugins@, and possibly logged as part of the plugin.

Just to be clear, other than the button label change and allowing the use of the button by any committer, this list only differs from @Ipstenu's request in that the plugin would get immediately closed without needing Plugin Directory admin intervention. The other tasks outlined are simply laying out the implied and sensible requisite components of the request.

[Ipstenu]

I like this. I like this a lot!

For plugins that are already closed, replace the 'Close this plugin' button and text with an explanation about the plugin being closed and information about how to request re-opening the plugin (even if it's largely a link to plugin developers handbook).

Only problem there is that we may have closed it for some reason or another. Security, attitude, etc.

If plugin was closed by admin: This plugin is closed. if you don't know why, please contact...

Else: This plugin was closed by X...

We could change the red alert bar to reflect that instead, so they don't have to trawl for it?

[coffee2code]

We can add some sort of flag or cue to differentiate between user-invoked plugin closure and admin-invoked and then act accordingly in various places where that difference may matter.

We could change the red alert bar to reflect that instead, so they don't have to trawl for it?

Agreed, the alert notice could be amended with an additional message that says something to the effect of This plugin was closed by one of its committers. Please see the <a href="%s">plugin handbook</a> if you wish to request that it be reopened. The alert notice is already displayed prominently on every page of a closed plugin (which is only accessible to the plugin's committers) and foregoes the need to do anything more than removing/disabling the "Close this plugin" button on the admin tab.

---

We could also consider allowing committers to reopen a user-initiated plugin closure. Since they weren't closed by an admin for any reason we have concern about (security, guideline violation, etc) there's no real need for a review or admin intervention.

---

We should also be certain to allow admins to change a user-initiated closure to an admin-initiated closure, for cases where a user-closed plugin needs to stay closed and not reopened without a review.

[Ipstenu]

I'm on the fence about letting them close and reopen. It's usually a reason for one of us to step in and ask them WHY they keep closing and reopening. I can only imagine the system abuse since doesn't reopening rebuild the zips?

[Ipstenu]

After a lot of thought, I'm fine with people being able to close their own plugins, but not reopening. If they want to reopen, I want the review team to re-review and make sure they're up to today's security standards. This is for the safety of users.

A 'reopen' button should just be an email link (or feedback?) to the plugins team and prompt them to explain why they closed it and why they're reopening it. This will also let us have a talk with people who want to press fun buttons.

That does mean any close button should be clear that it's a one-way street. "Warning: Closing your plugin is intended to be a permanent action. You will not be able to reopen it without contacting the plugin team."

[dd32]

In 9672:

Plugin Directory: Allow plugin committers to self-close plugins.

See #1560.

[dd32]

In 9673:

Plugin Directory: Update the function description missed in [9672].

See #1560.

[dd32]

In 9674:

Plugin Directory: Switch the capability used for self-closing plugins.

These caps are exactly the same, but this makes more sense in the context.

See #1560.

[dd32]

This part from @coffee2code above still needs adding:

Above the button, add a descriptive paragraph/list explaining what happens when they click the button. (What "closing" a plugin means, reasons to close (and not to), the process involved for un-closing a plugin.)

And hopefully @Ipstenu still agrees that any committer should be able to close them still :)

I had an additional thought, that perhaps plugins over a certain active installs limit shouldn't be able to self-close, but I committers once again can do far worse things.

[Ipstenu]

And hopefully @Ipstenu still agrees that any committer should be able to close them still :)

I do :) Got our first "Oh hey! I can do that!"

perhaps plugins over a certain active installs limit shouldn't be able to self-close, but I committers once again can do far worse things.

Let's wait and see if that becomes a problem. People rage-quitting and nuking their plugins would happen anyway, and this saves me an argument of "Dude, are you SURE?"

Note: It's been 9 hours and we already have one person freaking out that he CAN do it, and one person who 'accidentally' clicked the button.

[Ipstenu]

Suggestion from a dev "Or like how you delete a repo in Github. Once you click on delete, you get a popover to type the slug of the repo to confirm."

That may not be a bad idea to make SURE people wanted to do this. However I'd like to let this bake a bit before we jump in any direction. Much like preventing admins from deleting the last person with commit access, it's like to be a pretty rare situation.

[dd32]

In 9677:

Plugin Directory: lowercase_p_dangit() Grammer tweak, this should be a lowercase p.

Props Ipstenu.
See #1560.

[Ipstenu]

Updates for sanity

[Ipstenu]

Re 1560.combo.diff:

After a notable number of confused users, I've given the whole page a cleanup. Fixes included:

• Altering language to be less terrifying (i.e. This plugin is OPEN)
• Clearly defining sections with HR breaks
• Warning notes in sections as needed (to make sure people understand why we don't want them using old versions of things)
• Correcting headers to actually make SEO sense (h4 and h5 were used pretty arbitrarily and didn't have enough visual difference that allowed people to understand what was what)
• Matching formatting for the rest of the code (we're using echo all around so let's be consistent)
• Limiting who can close a plugin (20,000+ users of a plugin CANNOT be closed by the developers - I call it the Jetpack Protection Clause)

[dd32]

In 9698:

Plugin Directory: Make the Advanced view a bit more friendly.

This adds more descriptive text to the "Close this plugin" button and makes it clearer that these operations aren't available to everyone (and are potentially destructive).

Props Ipstenu.
Fixes #1560.

[dd32]

In 9707:

Plugin Directory: Require confirmation before transferring and closing a plugin.

This also requires specifically selecting a new owner of the plugin.

See #5131, #1560.