WordPress.org

Making WordPress.org

Opened 6 months ago

Closed 12 days ago

Last modified 12 days ago

#2860 closed enhancement (fixed)

Plugin Admin: Add values for closed plugins

Reported by: Ipstenu Owned by: SergeyBiryukov
Milestone: Plugin Directory v3.0 Priority: normal
Component: Plugin Directory Keywords: has-patch has-screenshots dev-feedback reporter-feedback
Cc:

Description

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

Attachments (5)

2860.diff (3.7 KB) - added by jdgrimes 3 months ago.
2860.2.diff (4.1 KB) - added by jdgrimes 3 months ago.
Also save the reason when disabling a plugin
2860.3.diff (4.5 KB) - added by jdgrimes 3 months ago.
Show "Unknown" when close reason is empty
plugin-dir-plugin-closed-date.patch (1.5 KB) - added by joostdevalk 13 days ago.
Patch to add plugin close date to a post meta
show-close-date.patch (1.2 KB) - added by joostdevalk 12 days ago.
Patch to show close date on plugins single for closed and disabled plugins

Download all attachments as: .zip

Change History (43)

This ticket was mentioned in Slack in #meta by ipstenu. View the logs.


5 months ago

#2 @zuda
4 months ago

  • Keywords 2nd-opinion added
  • Type changed from defect to enhancement

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.

#3 @Ipstenu
4 months ago

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

#4 @zuda
4 months ago

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
3 months ago

#5 @jdgrimes
3 months ago

  • Keywords has-patch has-screenshots dev-feedback added; 2nd-opinion removed

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

Before patch:

https://cldup.com/mhLFUaQ3f4.png

With patch (open plugin):

https://cldup.com/KKQgPGegP5.png

With patch (closed plugin):

https://cldup.com/MW1mNa-3zS.png

#6 follow-up: @SergeyBiryukov
3 months ago

  • Milestone set to Plugin Directory v3.0

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.

#7 in reply to: ↑ 6 ; follow-up: @jdgrimes
3 months ago

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.

#8 in reply to: ↑ 7 @SergeyBiryukov
3 months ago

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.

#9 @SergeyBiryukov
3 months ago

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

#10 @Ipstenu
3 months ago

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

@jdgrimes
3 months ago

Also save the reason when disabling a plugin

#11 follow-up: @jdgrimes
3 months ago

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:

https://cldup.com/zOhwa6cwYe-2000x2000.png

Closed plugin:

https://cldup.com/F_8rFcSrRg.png

Disabled plugin:

https://cldup.com/XvTCzx-tup-2000x2000.png

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.

#12 in reply to: ↑ 11 @SergeyBiryukov
3 months ago

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
3 months ago

Show "Unknown" when close reason is empty

#13 @jdgrimes
3 months ago

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

https://cldup.com/ZZhgRfwGU2.png

This ticket was mentioned in Slack in #meta by sergey. View the logs.


2 months ago

#15 @Ipstenu
2 months ago

#2404 was marked as a duplicate.

#16 @SergeyBiryukov
2 months ago

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.

#17 @SergeyBiryukov
2 months ago

In 6034:

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

Props jdgrimes.
See #2860.

#18 @SergeyBiryukov
2 months ago

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 in #2717.

Version 0, edited 2 months ago by SergeyBiryukov (next)

#19 @SergeyBiryukov
2 months ago

In 6035:

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

See #2860.

#20 @Ipstenu
2 months ago

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

#21 @Ipstenu
2 months ago

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

#22 @SergeyBiryukov
2 months ago

In 6043:

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

Props Ipstenu.
Fixes #3210. See #2860.

#23 @tellyworth
6 weeks ago

  • Keywords reporter-feedback added

Can this be closed?

#24 @Ipstenu
6 weeks ago

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'

#25 @SergeyBiryukov
6 weeks ago

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

#26 @SergeyBiryukov
6 weeks ago

  • Owner set to SergeyBiryukov
  • Status changed from new to accepted

#27 @SergeyBiryukov
4 weeks ago

In 6129:

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

See #2860.

This ticket was mentioned in Slack in #meta by ipstenu. View the logs.


3 weeks ago

@joostdevalk
13 days ago

Patch to add plugin close date to a post meta

#29 @Otto42
13 days ago

In 6204:

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

@joostdevalk
12 days ago

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

This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.


12 days ago

#31 @Otto42
12 days ago

In 6212:

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

#32 @Otto42
12 days ago

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

#33 @joostdevalk
12 days ago

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.

#34 @Otto42
12 days ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#35 @SergeyBiryukov
12 days ago

In 6228:

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

See #2860.

#36 @joostdevalk
12 days ago

I had actually made that public on purpose.

#37 @Otto42
12 days ago

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

#38 @Otto42
12 days ago

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

Note: See TracTickets for help on using tickets.