Feature request: Ability to edit plugin slug

[henry.wright]

I'd like to update my plugin's slug to remove a copyright-protected word. I realise slugs aren't currently editable.

Ref: ​https://en-gb.wordpress.org/plugins/buddypress-identicons/

[obenland]

A plugin's slug currently serves as a unique identifier in a lot of places. Places like stats, updates, etc. It's currently just not possible to do that without breaking a lot of things I'm afraid.

[Cybr]

It's currently just not possible to do that without breaking a lot of things I'm afraid.

Then let's make that work. Preliminary tasks have already been completed via ​core 50921.

Practically, in order:

1. We need to host two versions of the plugin: old slug and new slug.
2. The plugin author needs to point the old slug's Update URI to the new slug.
3. We need to set a 301 redirect from the old slug w.org page to the new one.

[dd32]

At this point in time, this isn't something we're considering, and is not something that we'll be putting effort into achieving.

The limitations go deeper than just the update location.

[Cybr]

Could you elaborate on the limitations? Is there anything I can do?

Currently, because the team is unwilling to allow changing the slug for unspecified reasons, plugins stuck with the wrong slug can not rank well in Google Search, nor via JetPack ES.

This artificially maintained limitation is hurting the people who contribute most to WordPress.

[dd32]

The "unspecified reasons" are that we internally use the slug as a hard one-and-only ID in multiple systems, these are not places we can (or are willing to) change, this is not simply a matter of lack of development time.
I would LOVE to change the slug of certain popular plugins that were approved with "inappropriate" slugs.

There is zero benefit to WordPress.org to allowing that to change at present.

stuck with the wrong slug can not rank well in Google Search

The URL should not be the deciding factor in ranking in search results..

nor via JetPack ES.

Likewise, the slug is not part of the search algorithm.
edit: Apologies; it is included, but only as a match for when someone searches for an explicit plugin by the known slug, if they're not searching for the title or exact slug at present, then they're not requesting a specific plugin

Discussion can continue while the ticket is closed; but to avoid getting in a close-war with you, I'm not going to close this ticket; but I won't be further engaging the topic.

[Cybr]

The URL should not be the deciding factor in ranking in search results..

But it is. Moreso when pages are competing on the same domain.

Likewise, the slug is not part of the search algorithm.

But it is, and it used to weigh as much as the title and orders of magnitudes more on non-en_US subsites. I've not been made aware if this has been rectified; the code is mostly closed-source.

In any case, I proposed keeping the old slug so that nothing in the system needs changing and no IDs can be desynced.
I also proposed making a new slug, which is nothing out of the ordinary.
Then, all we need to do is add a 301 redirect, which requires one line of code—perhaps a few more to make this process easier.
And lastly, we need to change the plugin's Update URI header to migrate users from one to the other.

[dd32]

Likewise, the slug is not part of the search algorithm.

I've not been made aware if this has been rectified; the code is mostly closed-source.

I clarified above that it is indeed part of the search, intended for direct slug-searches, but the search is indeed open-sourced, and always has been (Which is why y'all game it hard, and why the state of search is so bad, and why I don't think we should add yet another field here).

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-plugin-search.php

I also proposed

And again, that's your opinion of what's required, and is simplification of how other processes work on WordPress.org, which, as you'll understand, you don't have the full knowledge of (because there are some parts that are not open-source). My personal opinion of what's required is greatly different.

I'm saying no; and I believe all other meta developers with experience on the backend of the systems in question will also say something along the lines of either "No, it's not technically feasible right now", or "No, it's not worth it."