WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 11 months ago

#23318 new enhancement

Plugins Admin Showing Details for Wrong Plugin

Reported by: miqrogroove Owned by:
Milestone: WordPress.org Priority: normal
Severity: normal Version:
Component: Plugins Keywords:
Focuses: Cc:

Description

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?!

Attachments (2)

update-service.diff (1.9 KB) - added by DavidAnderson 4 years ago.
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.
23318-upgrade-header.diff (3.4 KB) - added by meloniq 4 years ago.
Adds optional "Upgrade" plugin/theme header, defaults to 'true', when 'false' set it excludes plugin/theme from checking for updates in WP API

Download all attachments as: .zip

Change History (26)

#1 @miqrogroove
5 years ago

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!

#2 @SergeyBiryukov
5 years ago

  • Milestone changed from Awaiting Review to WordPress.org
  • Version 3.5.1 deleted

Related: #13928, #14179

#3 follow-up: @rmccue
5 years ago

+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).

#4 @crazycoders
5 years ago

  • Cc crazycoders added
  • Keywords 2nd-opinion added
  • Severity changed from critical to normal
  • Type changed from defect (bug) to enhancement

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.

#5 in reply to: ↑ 3 @jdgrimes
4 years ago

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.

#6 follow-up: @DavidAnderson
4 years ago

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.

Last edited 4 years ago by DavidAnderson (previous) (diff)

@DavidAnderson
4 years ago

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.

#7 in reply to: ↑ 6 ; follow-up: @jdgrimes
4 years ago

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.

#8 in reply to: ↑ 7 ; follow-up: @DavidAnderson
4 years ago

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.

Last edited 4 years ago by DavidAnderson (previous) (diff)

#9 in reply to: ↑ 8 ; follow-up: @jdgrimes
4 years ago

  • Keywords close added

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.

#10 in reply to: ↑ 9 @DavidAnderson
4 years ago

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.

#11 @helen
4 years ago

#28660 was marked as a duplicate.

@meloniq
4 years ago

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

#12 @meloniq
4 years ago

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.

#13 @DavidAnderson
3 years ago

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/).

#14 @DavidAnderson
3 years ago

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.

#15 @dd32
3 years ago

  • Keywords 2nd-opinion close removed

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.

#16 @miqrogroove
3 years ago

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

#17 @DavidAnderson
3 years ago

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"

#18 @DavidAnderson
3 years ago

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.

#19 @ocean90
3 years ago

#32539 was marked as a duplicate.

#20 @chriscct7
3 years ago

#13928 was marked as a duplicate.

#21 @Clorith
2 years ago

#36348 was marked as a duplicate.

This ticket was mentioned in Slack in #core by sergey. View the logs.


20 months ago

This ticket was mentioned in Slack in #themereview by grapplerulrich. View the logs.


16 months ago

Note: See TracTickets for help on using tickets.