Making WordPress.org

Opened 6 years ago

Closed 5 years ago

#4656 closed defect (bug) (fixed)

Plugin Directory: Check for slug conflicts before accepting

Reported by: ipstenu's profile Ipstenu Owned by: dd32's profile dd32
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)

#1 @dd32
6 years ago

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

There's a few shortcomings of the code being used in themes, but for plugins there's an extra few extras including:

  • >= 100 installs, active installs only (ie. installed on 1,000 sites, active on 50 won't block)
  • Search will need to be by Plugin Name rather than slug
  • We can't match based on slug, so slug changes in wp-admin won't be able to catch conflicts, but we can do something like my-awesome-plugin looks up My Awesome Plugin and warns (but not block)
  • The slug changer will override any blocks, so if the original author of a widely used plugin were to submit under a slightly different name it could be 're-allocated' to it's correct slug.
Last edited 6 years ago by dd32 (previous) (diff)

#2 follow-up: @Ipstenu
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 @dd32
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)

Last edited 6 years ago by dd32 (previous) (diff)

#4 @Ipstenu
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.

#5 @dd32
5 years ago

In 9670:

Plugin Directory: Prevent plugin uploads that use existing popular plugin names.

See #4656.

#6 @dd32
5 years ago

In 9671:

Plugin Directory: Add a note to the Plugin Review Tools flags when installs of a plugin exist.

This should flag something when a plugin reviewer changes the slug or title through the admin interface.

See #4656.

#7 @dd32
5 years ago

I think this will work, let's see what happens..

#8 @dd32
5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.