Making WordPress.org

Opened 14 months ago

Last modified 13 months ago

#6957 new feature request

Plugin Directory: Close plugins with no data

Reported by: ipstenu's profile Ipstenu Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

When we migrated everything to the 'new' plugin system a few years ago, we did a decent job of catching everything _without_ code.

Looks like we missed some.

We should have some _AUTOMATED_ way to

  1. Find all plugins without anything in trunk
  2. Auto-close as 'by author request' if 1 is true

Change History (3)

#1 @dd32
13 months ago

Something that was supported, because some plugins in the past used this format, is that they don't have anything in trunk, but tag new releases.

This is supported here:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/class-import.php?marks=509-518#L500

Effectively, if trunk/ is empty, we treat it as having a readme.txt that contains only Stable Tag: $highest_tagged_version.

We could deprecate this going forward, but plugins that have nothing in trunk/ AND nothing in tags/ should indeed be closed.. although it's pretty hard for us to query for, without checking every plugin SVN individually through a CLI script.

In the past month, the following plugins have hit the Plugin has no files in trunk, nor tags. exception:

  • clear-divi-cache-button
  • shipments-with-pulpo
  • talkee
  • eacsoftwareregistry-software-taxonomy
  • g-ffl-cockpit
  • add-on-for-sendinblue-on-wpforms
  • wpavatar
  • gobuddy-the-smart-delivery-solution
  • contlo-for-woocommerce
  • wise-kpis
  • leaf-crm
  • cryptopay-wc-lite
  • block-common-crawl-via-robots-txt
  • visual-slider
  • riovizual
  • add-internal-links-lite
  • saoshyant-page-builder
  • bayarcash-givewp
  • flamix-bitrix24-and-wpforms-integration
  • hippoo
  • houzez-property-feed
  • wpsso-merchant-return-policy

Looking at these plugins, it appears that a few of them triggered it on their first commit, as they made a commit but failed to actually add any files. A few others triggered it because they deleted everything in trunk and had no tags. Some just don't seem to understand how SVN works and they've been highly confused.

#2 follow-up: @Ipstenu
13 months ago

@dd32 I think that check is wrong. I looked at flamix-bitrix24-and-wpforms-integration and that's a real plugin with code. Is it possible you're seeing the first 'initial commit' by plugin-master?

Realistically, we're only on the hunt for plugins pre 2018 that are like this. Everyone after that is a different situation.

Effectively, if trunk/ is empty, we treat it as having a readme.txt that contains only Stable Tag: $highest_tagged_version.

Yeah, we shouldn't do that. It makes it a metric pain to compare changes. If people properly use trunk, then we can just use the change log to know.

#3 in reply to: ↑ 2 @dd32
13 months ago

Replying to Ipstenu:

dd32 I think that check is wrong. I looked at flamix-bitrix24-and-wpforms-integration and that's a real plugin with code.

Between 06/03/2023 05:25:19 PM and 06/03/2023 05:30:20 PM that was the case as they rm -rf'd the lot: https://plugins.trac.wordpress.org/changeset/2921053/flamix-bitrix24-and-wpforms-integration

Sure, it was only 5 minutes, but I didn't at all intend on that list being a "These plugins are ones that have no data" but rather "These plugins are the ones we've processed this month which had no data when we looked at some point".

Effectively, if trunk/ is empty, we treat it as having a readme.txt that contains only Stable Tag: $highest_tagged_version.

Yeah, we shouldn't do that. It makes it a metric pain to compare changes. If people properly use trunk, then we can just use the change log to know.

If they only use tags and never use trunk, it's actually easier, as you can do svn cp tags/1 tags/2; make-changes-to-tags/2; svn ci which results in a single commit, That's effectively how themes.svn works.

The Trac compare-changes functionality is often better than reviewing the trunk changes alone too, as it's a combined diff rather than 10 individual commits, I'll admit however, that Trac (well, SVN) gets it wrong sometimes and thinks it's a 80MB diff when it's actually only 200K.

But I agree, we should ideally cease with that back-compat check here. We'll need to figure out which plugins are relying upon it.

Note: See TracTickets for help on using tickets.