Plugin Admin: Add values for closed plugins

[Ipstenu]

When plugins are closed or disabled, there should be a drop-down selection to list WHY this happened.

• Security Issue
• Author Request
• Guideline Violation
• Licensing/Trademark violations
• Merged into Core

[zuda]

So, I've gone over how this would be the best way done. Since the plugins@… system currently isn't segregated to levels, what could be done is a section of wordpress.org, like admin.plugins.wordpress.org that has all the names of each plugin. You just click the plugin, choose from the dropdown menu what type of issue it is and then a redirect will be put in place informing users what the problem is.

There is a lot of code to be done here, but my company is completely on-board to help.

[Ipstenu]

At this point the privacy of plugins' email has zero bearing on the situation :)

Plugin STATUS is handled via wordpress.org/plugins/wp-admin :D

[zuda]

Then if you are already using WordPress as the framework, it would be a lot easier to handle. All needs to be done is grab the plugin names every day or so and auto-update, then have the drop down that changes what is displayed on the page. No manual typing at all.

[jdgrimes]

2860.diff​ is an initial patch. It's my first meta patch, so any pointers are welcome.

Before patch:

With patch (open plugin):

With patch (closed plugin):

[SergeyBiryukov]

2860.diff​ looks good at a glance.

The only thing I'd like to add is some JS code to show the dropdown when clicking the Close button (instead of submitting the form), so that closing the plugin and specifying the reason could be done in one go.

[jdgrimes]

Replying to SergeyBiryukov:

2860.diff​ looks good at a glance.

The only thing I'd like to add is some JS code to show the dropdown when clicking the Close button (instead of submitting the form), so that closing the plugin and specifying the reason could be done in one go.

JS can be added to refine the flow, but to be clear, it can already be done in one go. The dropdown is currently just shown all the time. So you can select the reason, and then when the Close button is clicked the form will be submitted and the reason will be saved.

[SergeyBiryukov]

Replying to jdgrimes:

The dropdown is currently just shown all the time. So you can select the reason, and then when the Close button is clicked the form will be submitted and the reason will be saved.

Ah, great. I misread that part of the patch and was under an impression that the dropdown is only displayed if the plugin is already closed.

[SergeyBiryukov]

@Ipstenu Is comment:5 what you had in mind? Should the same dropdown be used for disabled plugins as well?

[Ipstenu]

Yes, the same dropdown should be used on disabled and closed. That would work fine for me :)

[jdgrimes]

Also save the reason when disabling a plugin

[jdgrimes]

2860.2.diff​ updates the patch to also save the reason when the Disable button is clicked.

I decided to move the dropdown above the buttons, because it seemed more natural:

Open plugin:

Closed plugin:

Disabled plugin:

I thought of one question: should the close/disable reason be deleted when the plugin is opened again? Currently nothing is done at that point, so the reason will continue to be stored in the post meta.

[SergeyBiryukov]

Replying to jdgrimes:

I decided to move the dropdown above the buttons, because it seemed more natural:

Yeah, that looks better to me as well.

Currently nothing is done at that point, so the reason will continue to be stored in the post meta.

I think it's fine, it might be used for future reference if we ever decide to implement a status change history for a plugin.

[jdgrimes]

Show "Unknown" when close reason is empty

[jdgrimes]

2860.3.diff​ tweaks the previous patch to better handle the case where the close reason isn't known (like if the plugin was closed before the dropdown was added). It will now show "Close Reason: Unknown" instead of just a blank close reason ("Close Reason: ").

[Ipstenu]

#2404 was marked as a duplicate.

[SergeyBiryukov]

2860.3.diff​ looks great, the only thing I'd like to add is the ability to specify a reason for previously closed plugins without reopening (by clicking "Save Changes"). Will handle that on commit.

[SergeyBiryukov]

In 6034:

Plugin Directory: Provide the ability to specify a reason when closing or disabling a plugin.

Props jdgrimes.
See #2860.

[SergeyBiryukov]

Remaining item from Slack discussion: decide whether we should also be logging the reason in the internal notes (which still need a date, see #3001). Perhaps that could be done as a part of #2717.

[SergeyBiryukov]

In 6035:

Plugin Directory: Correct the logic for displaying "Close/Disable Reason" dropdown.

See #2860.

[Ipstenu]

An audit log that combined closures (like the dropdown value selected, the date, and by whom) along side the internal notes would be 'best'.

[Ipstenu]

We must track the time and reason of a closure for this to be viable. Since a plugin could be closed multiple times, we need to account for that.

That does make this very much dependant on figuring out logging, because without logging then there's no way to track time to know when we can reasonably disclose why something was closed.

I feel we can at least make #2717 live and add this in later, because a small win with an iteration later is okay :)

[SergeyBiryukov]

In 6043:

Plugin Directory: Add "Unused" to the list of reasons for closing or disabling a plugin.

Props Ipstenu.
Fixes #3210. See #2860.

[tellyworth]

Can this be closed?

[Ipstenu]

Depends on how you want to handle the open-part.

That is, we track WHY it's closed. We need to also track WHEN it was closed. Should that be a new ticket or in the #2717 for logging? Which we really need now so we can do the whole check of 'if it's be 90 days, tell people WHY a plugin is closed'

[SergeyBiryukov]

comment:20 and comment:21 still need to be addressed, either via #2717 or separately.

[SergeyBiryukov]

In 6129:

Plugin Directory: Record the date when closing or disabling a plugin.

See #2860.

[joostdevalk]

Patch to add plugin close date to a post meta

[Otto42]

In 6204:

Plugins: Add date to postmeta when plugins are closed or disabled. Useful for historical needs. See #2860

[joostdevalk]

Patch to show close date on plugins single for closed and disabled plugins

[Otto42]

In 6212:

Plugins: Add display of closed date on closed plugins. props @joostdevalk. See #2860

[Otto42]

In 6217:

Plugins: General code cleanup, migrate events that happen on transistions to single place, remove duplicated code, add auditing, simplify logic. props @joostdevalk See #2860

[joostdevalk]

I think we've now fixed all the parts of this: we now store the reason and the date of closure as well as who did it. It also is stored as and shows in the internal notes block.

[Otto42]

Yep, an additional audit log type proved to be a bit overkill, so it's just another type of internal note, automatically generated when transitioning a plugin between types.

[SergeyBiryukov]

In 6228:

Plugin Directory: Use pre-existing meta key name for plugin closing date.

See #2860.

[joostdevalk]

I had actually made that public on purpose.

[Otto42]

Agreed, plz revert. We want it to be public information, visible in the custom fields area.

[Otto42]

In 6229:

Plugins: revert [6228]. This information is a different format than the previous meta used, and should also not be a hidden value. See #2860