Opened 18 months ago
Last modified 16 months ago
#6957 new feature request
Plugin Directory: Close plugins with no data
| Reported by: |
|
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
- Find all plugins without anything in trunk
- Auto-close as 'by author request' if 1 is true
Change History (3)
#2
follow-up:
↓ 3
@
16 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
@
16 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.
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 areadme.txtthat contains onlyStable Tag: $highest_tagged_version.We could deprecate this going forward, but plugins that have nothing in
trunk/AND nothing intags/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: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.