Plugins Admin Showing Details for Wrong Plugin

[miqrogroove]

I just set up a new site with some plugins, none of them activated yet. The plugins screen says:

"There is a new version of Google XML Sitemaps available. View version 4.1 details or update now."

I know for a fact there is no such version of this plugin. When I click details link, it tells me to install some other plugin called page-list?!

[miqrogroove]

Steps to reproduce:

1. Download the plugin from ​http://wordpress.org/extend/plugins/google-sitemap-generator/
2. Rename the plugin directory from 'google-sitemap-generator' to 'sitemap'
3. Refresh the Plugins admin screen a couple of times.

Using the directory name to detect plugins seems like a bad design!

[SergeyBiryukov]

Related: #13928, #14179

[rmccue]

+1, this needs a smarter mechanism IMO. In my code, I use an extra plugin header called Plugin ID: xxx, where xxx is the slug on the repository. We could add something like that, with a legacy fallback to the directory name (and eventually mark that as deprecated).

[crazycoders]

Agreed with the smarter mechanism but this is kind of a stupid bug.

Renaming the folder of a plugin willingly and it calling it a bug because it shows the patch for another plugin thats kinda like saying "I busted my car engine cause i used normal grade gas while i was supposed to use super grade but it's not my fault, it's the maker's fault for not letting me do it"

I don't think this should be kept open as the changes that are required to end up making this work would be really broad and could introduce many other bugs. Or if it must stay open, then it should be marked as an enhancement for a future release instead.

[jdgrimes]

Replying to rmccue:

+1, this needs a smarter mechanism IMO. In my code, I use an extra plugin header called Plugin ID: xxx, where xxx is the slug on the repository. We could add something like that, with a legacy fallback to the directory name (and eventually mark that as deprecated).

Thinking along the lines of solving #13928 as well, what about adding two headers, something like Update Service: xxx and Plugin ID: xxx. So for plugins that should receive updates from wordpress.org, you might have:

Update Service: wordpress.org
Plugin ID:      google-sitemap-generator

Then we would only check wp.org for updates if wordpress.org was the update service. (Of course, wordpress.org would be the default update service.) If you've modified the plugin and don't want to receive updates, you could change that to:

Update Service: none
Plugin ID:      google-sitemap-generator

I'm thinking this could also be used by other plugin distributors or repositories:

Update Service: github
Plugin ID:      JDGrimes/google-sitemap-generator

These could be condensed into a single header, like Update URI, but then we would have to parse the URI to see where it pointed to. I think two headers is cleaner and more extensible/fine grained.

[DavidAnderson]

I don't think that a header "Update URI" can work, because many 3rd party plugins will not have a static URL - they will want to include variable parameters (e.g. licence key).

In #28660 I proposed a simple "WordPress.Org Update" header. I like your "Update Service" header better though, as that covers the same ground and provides a little extensibility (e.g. something like WooThemes' "Helper" plugin that provides updates for multiple WooThemes plugins could use this).

I think a second "Plugin ID" header would be unnecessary. Instead, let "Update Service" be arbitrary in form, with a conventional/optional separator, e.g. "Update Service: github/JDGrimes". Whatever action/filter processes this header can then parse it to work out what is primary and what is secondary.

[DavidAnderson]

This patch 1) implements an "Update Service:" header, which defaults to "wordpressorg" if not present, and 2) excludes plugins whose "Update Service" is not set to wordpressorg from the call to api.wordpress.org. This minimally invasive approach provides a way for 3rd party plugin authors to prevent their plugins being unexpectedly replaced (see #28660), whilst leaving options open for future directions, and for how other plugins (e.g. ones like the WooThemes updates helper) might want to interpret the header.

[jdgrimes]

Replying to DavidAnderson:

I think a second "Plugin ID" header would be unnecessary. Instead, let "Update Service" be arbitrary in form, with a conventional/optional separator, e.g. "Update Service: github/JDGrimes". Whatever action/filter processes this header can then parse it to work out what is primary and what is secondary.

The reason I proposed this second header (actually, @rmccue did) is because WP has difficulty determining the exact ID of a plugin (that is the main brunt of this ticket, and #13928). The Update Service: header wouldn't actually fix this issue.

[DavidAnderson]

Replying to jdgrimes:

The reason I proposed this second header (actually, @rmccue did) is because WP has difficulty determining the exact ID of a plugin (that is the main brunt of this ticket, and #13928). The Update Service: header wouldn't actually fix this issue.

It does fix it, if the "Update Service" header can have a separator. e.g. "Update Service: acmecorp/superplugin". i.e. Both functions can be handled with a single header. Whatever theoretical 3rd party plugin provides the "acmecorp" update service will know how to parse anything after the separator too.

I'm not yet seeing, though, why WP needs to know the exact ID of a plugin as distinct from its slug. If the plugin is from the wordpress.org repository, then WP identifies it through the slug... if the slug has been changed, then updating it with a pristine version (i.e. unchanged slug) is probably a terrible idea.... on the other hand, if the slug is *not* from the wordpress.org repository, then it's in 3rd party territory anyway and the developer can implement whatever mechanism he pleases for identifying the plugin (i.e. it's not a problem that core needs to solve).

I think I'm really saying that 1) I agree with crazycoders in comment 4 - the slug is the identifier, and if you decided to change/break it, then you should have no expectation that anything else will work any more than if you decide to replace "<?php" with "<?squirrels!" everywhere. 2) I think it's best just to focus on the "plugin info fetched from the wrong remote service" problem.

[jdgrimes]

Replying to DavidAnderson:
I agree, but I guess in that case this ticket should be closed as wontfix and the discussion should be moved to one of the others.

[DavidAnderson]

Replying to jdgrimes:

Replying to DavidAnderson:
I agree, but I guess in that case this ticket should be closed as wontfix and the discussion should be moved to one of the others.

#28660 is probably the best. #14179 looks like the same as 28660, but for themes rather than plugins.

[helen]

#28660 was marked as a duplicate.

[meloniq]

Adds optional "Upgrade" plugin/theme header, defaults to 'true', when 'false' set it excludes plugin/theme from checking for updates in WP API

[meloniq]

Patch 23318-upgrade-header.diff adds optional "Upgrade" header for plugins and themes. New header defaults to 'true', when "Upgrade: false" is set, it excludes plugin/theme from checking for updates in WP API.

[DavidAnderson]

N.B. This issue also causes data from plugins obtained from outside wordpress.org to leak into the new 'stats' pages. e.g. ​http://wordpress.org/plugins/updraftplus/stats/ - no plugins with a "2.9" version number have been served up from wordpress.org (​http://plugins.svn.wordpress.org/updraftplus/tags/).

[DavidAnderson]

Another example of a plugin affected by this: ​https://wordpress.org/support/topic/new-update-has-lots-of-problems?replies=8#post-6791127 - this wordpress.org plugin clashes with the paid official WooCommerce extension which has the same slug. Users of the paid extension are getting "upgraded" to the free unrelated wordpress.org plugin.

[dd32]

I think it's probably time to add a GUID to both Plugins and Themes.

Adding a Unique Identifier to plugins and themes, not only will it solve problems like this one, but will also make the API far faster for plugin updates, as then it's only got one ID to check, rather than having to check each header with it's various weights it uses to detect the correct plugin (and as you can see here, it's not always accurate).
Themes already mostly use a static lookup, but it's based on the theme slug (the folder name) which isn't always a good check either.

I don't agree with the proposed naming of the fields here though, Upgrade and Upgrade Service, I'd far prefer to re-use the Plugin URI field, but unfortunately we have to expect plugin authors to change that over time.

So I'm thinking of something far more generic such as Plugin GUID: or Plugin ID: for example, with a value of https://wordpress.org/plugins/hello-dolly/ or even less w.org/hello-dolly to follow the examples offered earlier. I'd lean towards a full URL as it's easier to read and understand, however then becomes duplicative of the Plugin URI field for w.org hosted plugins.

[miqrogroove]

I like Plugin ID. Suggested default is the repo slug, but can be any arbitrary and unique value.

[DavidAnderson]

Both of dd32's suggestions are mathematically redundant... a name-space identifier plus a slug already constitutes a GUID.

1) w.org/hello-dolly
The slug is already known, and hence redundant. The "host" part of the URL is being used as a name-space/ownership identifier - same as the existing suggestion.

The only new thing is a convention that the identifier be a valid domain name, to prevent clashes. But since this convention can't be enforced upon 3rd-party plugins, and presumably won't be part of the code (WHOIS lookups on the domain ownership?!?) it does not add anything. (Sensible 3rd parties would do something to make sure their identifier was unique anyway).

2) Pretty much the same then goes for ​https://wordpress.org/plugins/hello-dolly/ - this does not encode any different information from w.org/hello-dolly, except that it's a plugin, and that it's also a valid URL - but, both these bits of information are already known from other sources, hence redundant.

My conclusions:

• It doesn't matter what we call it; it functions as a name-space identifier
• It's best not to include redundant information that can already be added if doing things like constructing URLs
• Since it's essentially a name-space or vendor identifier, we may as well call it that, instead of my earlier suggestion of "Upgrade Service", which suggests a more restricted use.

e.g. "Vendor: wordpress.org" (for repo plugins - and the assumed legacy value if not present), or "Vendor: example.com" by convention for 3rd parties - but nothing enforces this, so if someone has a reason to not be tied to a domain name, they can use "Vendor: MyBigFatSecretMegaCorp"

[DavidAnderson]

Ah, I'm confusing this with another related ticket. This ticket is also about knowing the plugin slug, even when someone changes the installed directory. That makes sense, and I apologise for missing the point.

So, I think we're all in the same place. If the data is a vendor identified followed by a slash followed by a slug, as dd32 suggests, then this both 1) encodes everything wanted and 2) functions as a GUID, as far as I can see.

[ocean90]

#32539 was marked as a duplicate.

[chriscct7]

#13928 was marked as a duplicate.

[Clorith]

#36348 was marked as a duplicate.

[SergeyBiryukov]

Related: #32101

[ocean90]

#51143 was marked as a duplicate.

[SergeyBiryukov]

In 50921:

Plugins: Add support for Update URI header.

This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the WordPress.org Plugin Directory.

Additionally, introduce the update_plugins_{$hostname} filter, which third-party plugins can use to offer updates for a given hostname.

If set, the Update URI header field should be a URI and have a unique hostname.

Some examples include:

• https://wordpress.org/plugins/example-plugin/
• https://example.com/my-plugin/
• my-custom-plugin-name

Update URI: false also works, and unless there is code handling the false hostname, the plugin will never get an update notification.

If the header is present, the WordPress.org API will currently only return updates for the plugin if it matches the following format:

• https://wordpress.org/plugins/{$slug}/
• w.org/plugin/{$slug}

If the header has any other value, the API will not return a result and will ignore the plugin for update purposes.

Props dd32, DavidAnderson, meloniq, markjaquith, DrewAPicture, mweichert, design_dolphin, filosofo, sean212, nhuja, JeroenReumkens, infolu, dingdang, joyously, earnjam, williampatton, grapplerulrich, markparnell, apedog, afragen, miqrogroove, rmccue, crazycoders, jdgrimes, damonganto, joostdevalk, jorbin, georgestephanis, khromov, GeekStreetWP, jb510, Rarst, juliobox, Ipstenu, mikejolley, Otto42, gMagicScott, TJNowell, GaryJ, knutsp, mordauk, nvartolomei, aspexi, chriscct7, benoitchantre, ryno267, lev0, gregorlove, dougwollison, SergeyBiryukov.
See #14179, #23318, #32101.

[SergeyBiryukov]

In 53933:

Themes: Add support for Update URI header.

This allows third-party themes to avoid accidentally being overwritten with an update of a theme of a similar name from the WordPress.org Theme Directory.

Additionally, introduce the update_themes_{$hostname} filter, which third-party themes can use to offer updates for a given hostname.

If set, the Update URI header field should be a URI and have a unique hostname.

Some examples include:

• https://wordpress.org/themes/example-theme/
• https://example.com/my-theme/
• my-custom-theme-name

Update URI: false also works, and unless there is code handling the false hostname, the theme will never get an update notification.

If the header is present, the WordPress.org API will currently only return updates for the theme if it matches the following format:

• https://wordpress.org/themes/{$slug}/
• w.org/theme/{$slug}

If the header has any other value, the API will not return a result and will ignore the theme for update purposes.

Follow-up to [50921].

Props dd32, meloniq, costdev, audrasjb, DavidAnderson, markjaquith, DrewAPicture, mweichert, design_dolphin, filosofo, sean212, nhuja, JeroenReumkens, infolu, dingdang, joyously, earnjam, williampatton, grapplerulrich, markparnell, apedog, afragen, miqrogroove, rmccue, crazycoders, jdgrimes, damonganto, joostdevalk, jorbin, georgestephanis, khromov, GeekStreetWP, jb510, Rarst, juliobox, Ipstenu, mikejolley, Otto42, gMagicScott, TJNowell, GaryJ, knutsp, mordauk, nvartolomei, aspexi, chriscct7, benoitchantre, ryno267, lev0, gregorlove, dougwollison, leemon, SergeyBiryukov.
See #14179, #23318, #32101.