WordPress.org

Making WordPress.org

Opened 8 months ago

Closed 8 months ago

#2742 closed defect (fixed)

Plugin Directory: Admin tool Author Card doesn't show plugins that weren't approved

Reported by: Ipstenu Owned by: coffee2code
Milestone: Plugin Directory v3.0 Priority: high
Component: Plugin Directory Keywords: has-patch
Cc:

Description

As the subject says.

If a dev has a plugin in "pending initial review" or "pending" it doesn't show up as a plugin on their list. This can cause issues as if you don't KNOW someone submitted the same plugin, twice, you may accidentally approve it twice.

cc @coffee2code

Attachments (1)

2742.patch (759 bytes) - added by SergeyBiryukov 8 months ago.

Download all attachments as: .zip

Change History (6)

#1 @Ipstenu
8 months ago

  • Summary changed from Plugin Directory: Admin tool Author Card doesn't show pending plugins to Plugin Directory: Admin tool Author Card doesn't show plugins that weren't approved

Correction.

It doesn't show anything that wasn't approved. No pending, no rejections :(

#2 @coffee2code
8 months ago

  • Owner set to coffee2code
  • Resolution set to fixed
  • Status changed from new to closed

In 5332:

Plugin Directory, Author Card: Search for author plugins according to known post statuses, not just published.

Fixes #2742.

#3 @coffee2code
8 months ago

  • Milestone set to Plugin Directory v3.0

#4 @SergeyBiryukov
8 months ago

  • Keywords has-patch added; needs-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

The query for user IPs a few lines below just uses 'post_status' => 'any'. Can't we use the same here instead of a hardcoded list? Seems more consistent and future-proof.

#5 @coffee2code
8 months ago

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

The check for user IPs can take into account any post status because all it cares about is getting all known IP addresses associated with the user. However, the check for author plugins is for a section that isn't future-proof for unknown post statuses. Of course that section could be reworked, but I don't feel the flexibility for supporting unknown post statuses was warranted since it would lead to them being displayed in the author's plugins list with no attributable meaning (is it in some sort of open state? some sort of closed state?).

If new statuses get added in the future (as talked about), I think it's reasonable to explicitly account for them (which includes adding a custom explanatory tooltip, class, styling, and perhaps handling for each).

Note: See TracTickets for help on using tickets.