WordPress (plugin) updates do not warn about unknown plugins

[Quandary]

The WordPress plugin update system does not notify the user if it could not find updates for a subset of plugins. That is, if the user has installed plugins not hosted with WordPress, they are not notified that new versions were not actually checked for. This can lead the user to believe that all of their plugins are up-to-date when they are not.

Fixing this will require both the server-side and the client to be updated. The WordPress update API will need to return data on which plugins it does not recognize as being hosted, and the WordPress installation will need to render that information so that the user understands which of his/her plugins are not automatically checked.

[zamoose]

+1.

Additionally, I think the plugin listings should be displayed in a manner similar to the comments listing -- approved comments are in black, moderated are in grey, etc.

Officially-recognized plugins should be in black, ones that don't show up on the service should show in some other color to denote them as not being checked for updates...

[Quandary]

AFAIK, the order of the posts isn't important/significant right now. Breaking the posts screen into two sections, with headers for "Hosted" and "Unhosted", might be more self-explanatory and convenient than just color-coding.

[jhodgdon]

+1 on the concept - people should not be lured into thinking non-hosted plugins (or ones whose readme file is screwed up so update checking isn't working) are updated, just because there is no notification.

I do not like the idea of color-coding. Grey on white is hard for people with low vision to see (I don't like it on the comment screen either).

I prefer the idea of putting a notification line below plugins that couldn't be checked saying "This plugin's update status could not be checked. Please visit the plugin website for updates" or something similar.

As noted in the description, this is not something a random volunteer developer can patch, since the response from api.wordpress.org also needs to be changed, and we don't have access to that code. Oh well!

[markjaquith]

Assigning to Matt, as this requires an API change.

I think it is important to distinguish between "up to date" and "status unknown"

Paper napkin idea: green checkbox, red exclamation point, orange question mark. But anyway, we need the API to support it.

[jaredbangs]

I additionally suggest (once Mark's "status unknown" mentioned above is in place), that there be a hook that plugin devs can use that fires only for "status unknown" responses.

That way, if plugin devs want to roll their own update notification system, they can do so, but still have the core only check the official repository.

[zamoose]

Replying to jaredbangs:

I additionally suggest (once Mark's "status unknown" mentioned above is in place), that there be a hook that plugin devs can use that fires only for "status unknown" responses.

That way, if plugin devs want to roll their own update notification system, they can do so, but still have the core only check the official repository.

I would actually suggest that ANY plugin that wishes to utilize the official WP update beacon create at least a stub README in the official repo. There should be a portion of the file that allows developers to point to their own download location (hosted wherever they desire) and then pass that URL along to the end WP "client" installs.

This has three distinct advantages, IMHO:

1. A fairly comprehensive official listing of WP-sanctioned plugins can be maintained.
2. Misbehaving plugins can easily be de-listed.
3. End WP clients spend no extra time hitting other update beacons.

There is a perceivable downside: all plugins must be GPL-compatibly-licensed.

What if only the README was GPL-licensed? Might this get around this constraint?

[jaredbangs]

Replying to zamoose:

This has three distinct advantages, IMHO:

1. A fairly comprehensive official listing of WP-sanctioned plugins can be maintained.
2. Misbehaving plugins can easily be de-listed.
3. End WP clients spend no extra time hitting other update beacons.

There is a perceivable downside: all plugins must be GPL-compatibly-licensed.

Yeah, I guess there are benefits and drawbacks either way. Of course, the best case scenario would be for plugin devs to just use WP.org hosting, but I was thinking that some may not want to do that (for whatever reason, licensing or other).

I guess I'd tend to favor keeping only WP.org hosted plugin info in the directory, and making / allowing plugin devs who don't wish to host their plugins there do their own thing.

Regarding the benefits you list above, I don't know whether WP.org wants the responsibility of hosting an official list, specifically "sanctioning" or "de-listing" them, as you suggested.

I think if the hook were there, the core client would still only be checking one update site (WP.org), unless the plugin devs choose to optionally hook into the not_available status and run their own checks, etc.

I guess they could do this now (and some do, I believe) but it seems like this would be a convenient place to establish a standard way for external plugins to take part in the update check without burdening WP.org with extra requirements.

[jhodgdon]

Just a bit of perspective on why someone whose plugins are under the GPL wouldn't want to host at wp.org. The reason I don't host mine on wp.org is that I was already maintaining my own SVN repositories and download scripts on my web site for other purposes (I distribute some non-WP free software as well as WP plugins). I didn't feel like the extra hassel of dealing with two different publish/download mechanisms was worth the extra exposure, since I do not actually care how many people find and use my plugins.

On the other hand, if all I had to do when I released a new version is update one readme file on wp.org, so that the plugin update checking would figure out there was a new version and alert my users, I might put the time in to figure that out. So:

+1 on stub README files on wp.org (and I don't care if it's restricted to GPL plugins)

+1 on red exclamation mark, green check, orange question mark idea, except that I don't think anything else in the admin screens uses images to indicate status. Maybe it was one of the other tickets in this series of three that suggested adding a column to the plugin screen and putting the status message there? I like that idea too.

[zamoose]

Bumping version to 2.5, as this is still very relevant (and very necessary, IMNSHO).

[lloydbudd]

+1 can someone create mockups / screenshots for the client side? Then when we have a sensible experience we have more compelling arguments to take to Mike/Matt on the server side part.

[neoxx]

+1 for visual notification in the plugins tab

+1 for jaredbangs's stub README idea or an extended how-to in the developer center ​http://wordpress.org/extend/plugins/about/

in addition i would suggest a daily email notification, which should be available as option in the plugins or settings tab.

[lloydbudd]

#7016 is a dup of this issue.

[zamoose]

Can we get any traction on this issue? Any way to get some movement from the API server?

[DD32]

Can we get any traction on this issue? Any way to get some movement from the API server?

If someone was to make a UI mockup, Then that'd create a reason to get someone to get an API running, As it is, Without the UI being designed, the API would be useless. ​http://trac.wordpress.org/ticket/5117#comment:12

[strider72]

By "UI mockup", are we just talking a screenshot or code? I'll get on this, as I would really like to see it happen. :)

As far as visuals go, I'm very much in favor of putting the info in a column instead of the bar beneath each plugin. Perhaps we can add some indicator to the Version column itself.

I propose a new optional header line for plugins: "Update URL". If a plugin is not on WP-Extend, an author can put the download page URL there. Then...

On the plugins page, in the Version column, show the version as we do now. In the same cell, just below the version:

1) If checked and no update: nothing

2) If checked and update available: "Version X.X is available. Download | Auto Update"

3) If not found on WP Extend:

a) If plugin has "Update URL" header: "Updates not checked. [LINK:check manually]".

Link appends "?plugname=_&ver=_&wpver=_" to end of URL so that page can programatically respond if it wants to. Some authors may make a single update.php that handles multiple plugins. Also might be good for author's logs.

b) If plugin lacks "Update URL" header: "(not checked for updates)"

I will make a visual mockup and get it up -- hopefully this evening.

[strider72]

(I was trying to put blanks in the GET string -- came out as underlining. Sorreee!)

[strider72]

Actually, even people who DO host their plugins on WP Extend could use the "Update URL" header. It would serve as a backup in case there is a glitch/failure on the server side.

ALSO: I think I would add a filter or do_action so that in case "3" above, authors can influence the output just before it is written to the page. Actually, this would be better than (as I suggested above) automatically appending the GET. With a filter, the author can add a GET or #id or do anything he chooses.

What do people think about this?

[strider72]

Clarification: I would add the filter to the _URL only_, not the entire text. I believe visual appearance should remain highly standardized in this area. The main purpose of the filter is to allow the author to alter the URL based on the installed version of plugin and the WordPress version.

Does anyone think this causes privacy issues? If there's a filter, the plugin author could record WP version and Plugin version of people who click the link. (Of course, that's _only_ people who click the link, and only _when_ they click the link.)

[DD32]

strider72: I think the possibility for WordPress to support non-WordPress.org hosted plugins should be in a different ticket, As its a complete different functionality than the one in this ticket; Which is to warn about plugins which do not have any update information available.

[strider72]

DD32: Perhaps I overthought things, but ultimately the distinction you make is negligible.

The bulk of the change we are discussing is getting the server response to distinguish between "no update" and "not found", and then putting *something* on the Plugin Admin page to mark plugins that are "not found".

That's 95% of the work. Beyond that, it's a small step to change *something* to a link and tossing in an apply_filter() before output.

That last bit entails changing:

• If not found on WP Extend: "(not checked for updates)"

to:

• If not found on WP Extend:
  

a) If (has "Update URL" header): "Updates not checked. [LINK:check manually]".
b) else: "(not checked for updates)"

Total changes:

1) Get additional "not found" output from server (format to be determined)
2) Add new "Update URL" parameter to output of plugin_data()
3) In plugins.php, add new logic within $plugins loop that writes "not checked|check manually" as needed to Version table cell.

[strider72]

RE appearance/ Location:

1) Yesterday I suggested putting regular update messages in the same place. I've changed my mind on that: regular WP Extend update notices should remain exactly as they are.

2) Incidentally, The reason I suggest putting it in the same call as the Version is because doing a "not checked" stripe below the row would essentially be permanent for these plugins, which I don't think we want. BUT...

3) I'm certainly open to suggestions as to how the message should display -- no need to clutter the interface. _Should_ we go with a modified "update stripe"?? I suppose we could also add a single line below the Description but in the same cell.

4) In any case I strongly believe there should be a filter on the "not checked" output, so authors can change or even remove the notice entirely.

[strider72]

I definitely overthink things.

If the filter is there so the "not checked" output can be modified, I hereby withdraw my push for automating update link. Authors can roll their own and use the filter.

Sorry for the runaround. Let's keep things simple and get it done! :)

[strider72]

Adds a "Not checked for updates" notice if the update status of a plugin is unknown

[strider72]

example plugin showing filter usage

[strider72]

example plugin showing filter usage

[strider72]

Added a .diff -- hope I did it right.

This adds the filter-able "not checked" message to plugins that the update server lists as "unknown".

This is dependant on a change on the server end. The diff includes demo code that manually marks the two attached plugins as "unknown."

As this is coded, Server will have to add an array "unknown-plugins" containing elements of $plugin_file=>true for all the plugins for which it doesn't have data.

This was coded against the standard WP 2.5.1 release.

[strider72]

Current patch is modeled for the server data adding an array "unknown" that contains elements:

$plugin_file => true

for unknown status

A possible alternative to the server change:
Add an "other_plugins" array that contains both:

$plugin_file => 'unknown'

or

$plugin_file => 'current'

for _all_ plugins not in the existing update data.

If they're going to bother changing the server data returned, explicitly returning status on all plugins checked might be useful down the road....

[strider72]

Replying to markjaquith:

Assigning to Matt, as this requires an API change.

I'm assigning this back to Matt, as the ball is back in his court. I've done the PHP end -- we now need a change to the server API.

[strider72]

Changed assumed server data return per comment #26 (specifies both unknown and up-to-date)

[strider72]

Link in the above is wrong Should have referred to comment #26 on this page, not trac ticket 26....

[strider72]

This is a more efficient version. A chunk of code is not run unless it's needed. (Not huge, but every bit counts!)

[strider72]

Assigning to Matt. requires server API change
(Tried this before and it didn't stick....)

Changing milestone to 2.8

[santosj]

Moved to 2.9 to allow core team to decide which tickets they are going to put into 2.8.

[Denis-de-Bernardy]

See also: #5117

[Denis-de-Bernardy]

#7875 even

[strider72]

This patch has been lingering since WP 2.3.

Is Automattic even considering this change to the update API? Is the patch worth updating or will it simply be ignored for another year?

Please take a look at this -- I'm not the only one who thinks this is a slap in the face to plugin authors.

[strider72]

Changing "Type" back to "defect/bug"; this isn't adding a new feature so much as correcting incorrect behavior. WordPress is suggesting that certain plugins don't have updates, when in fact WP has no idea what their status is.

[helen]

Still a thing? Plugins can be updated from other sources now.

[nacin]

This doesn't seem like something we should be solving for, at least as proposed. Closing.