Opened 6 years ago
Closed 5 years ago
#4656 closed defect (bug) (fixed)
Plugin Directory: Check for slug conflicts before accepting
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | |
Cc: |
Description
This is done in themes, but needs to happen in plugins as well.
If someone uploads a plugin with a proposed slug that is already in use, we need to have the plugin FAIL. This would prevent people from uploading their free plugin with the same name as their pro one and goofing all their users.
The breakpoint should be 50 users.
This would also need a tool on the admin end so we can see what's going on (much like we have for author cards). This WILL NOT fix a problem if we manually rename a slug per their request, but if we have the tool at least we'll be able to see why :/
Change History (8)
#2
follow-up:
↓ 3
@
6 years ago
Not being able to use slug is going to mean we still face the same problem we have for years, which is people don’t realize you cannot have the slug twice... They constantly submit the same slug they use for their premium stuff.
There’s no way to do that? The slug itself is the main issue, after all.
(Yes, I can override it, but if we can stop them at the gate, or have a look up, it would save a lot of drama. Even Automattic has goofed this one)
#3
in reply to:
↑ 2
@
6 years ago
Replying to Ipstenu:
Not being able to use slug is going to mean we still face the same problem we have for years, which is people don’t realize you cannot have the slug twice... They constantly submit the same slug they use for their premium stuff.
There’s no way to do that? The slug itself is the main issue, after all.
The slug is the main issue, but the slug is defined by the name anyway - so it's basically the same check at the end of the day.. just using slightly different sanitization methods.
The only place where checking the slug would be needed is by plugin reviewers, so if we "reverse" slugs to the name for the check for a reviewer, it should at least cover the majority of scenarios..
The reason that it's unable to lookup by slug is due to the significantly higher number of plugin slugs used vs the number of plugin names, I know it might seem odd, but when you exit the WordPress.org-hosted set of plugins you end up with 5-10 different folder names per Plugin Name
header which requires significantly more memory to keep track of the "I saw this in the wild" stat (Also why the stat is >=100 rather than 50 as for themes)
(edit: I should add - I think it's worth trying with the limitations and see how it fairs, if it really doesn't actually help, we can look into the stats process to perhaps keep some slug information or further 'sanitize' plugin titles a bit more to get a closer match)
#4
@
6 years ago
I know it might seem odd, but when you exit the WordPress.org-hosted set of plugins you end up with 5-10 different folder names per Plugin Name header which requires significantly more memory to keep track of the "I saw this in the wild" stat
No, not odd at all. I've seen the wild. It's horrifying!
The only place where checking the slug would be needed is by plugin reviewers, so if we "reverse" slugs to the name for the check for a reviewer, it should at least cover the majority of scenarios..
True. I was just hoping to eventually automate that so it didn't rely on a human going to check if the slug was in-use. I'm still worried about the _high_ number of people who ask for specific slugs and end up shooting themselves in the foot. If that was some sort of auto check, it would lower the risk of stupid moments like a new plugin having 400,000 installs. Right now if I change the slug of a pending plugin to akismet, it barks at me that the post already exists... I wouldn't be opposed to that check in the rename, but memory being an issue, then yeah :/ I really do just care about a true match though.
(Also why the stat is >=100 rather than 50 as for themes)
I didn't know what Themes was and spitballed a guess :D 50 is fine.
There's a few shortcomings of the code being used in themes, but for plugins there's an extra few extras including:
Plugin Name
rather than slugmy-awesome-plugin
looks upMy Awesome Plugin
and warns (but not block)