Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22129 closed defect (bug) (wontfix)

Plugins cannot be updated when getting updates from outside the repo

Reported by: griffinjt's profile griffinjt Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4.2
Component: Multisite Keywords: dev-feedback
Focuses: Cc:

Description

This problem in particular is a bug in MultiSite, but it is a general annoyance outside of MultiSite as well.

WordPress can check for and offer updates to plugins that aren't activated if they are listed in the WordPress Plugin Repository. Since the update process grabs all the plugin basenames and checks them against the URL in the plugins_api function, anything found in the repo will be blessed with an update, active or not.

However, plugins that get updates outside of the repo don't get this opportunity if they are not active. I suppose this is expected since the plugin is not active (and therefore does not have the ability to filter the update_plugins transient or the plugins_api function), but it could provide for a poor user experience when they are receiving updates for some deactivated plugins and not others when updates are known to exist.

Beyond this, there is an actual bug with this regarding MultiSite that needs to be addressed. If you have a plugin that is receiving updates outside of the repo when activated on an individual site in MS, the plugin update will be shown when on that site's admin area. However, when you click to process the update (assuming you are a network admin), the update disappears on the Network Updates screen. Why? Because the plugin is not network activated, it is not run and thus no updates are filtered in. This means that there is absolutely no way of automatically updating the plugin unless you network activate it, run the update, and then network deactivate the plugin. Yuck.

I'm not sure what the best way to approach either of these scenarios would be (mainly the second issue with MS), so I wanted to get some other opinions on it.

Change History (13)

#2 follow-up: @SergeyBiryukov
11 years ago

However, plugins that get updates outside of the repo don't get this opportunity if they are not active. I suppose this is expected since the plugin is not active (and therefore does not have the ability to filter the update_plugins transient or the plugins_api function)

Sounds like the filtering should be in another (network activated) meta plugin.

#3 in reply to: ↑ 2 ; follow-up: @griffinjt
11 years ago

Replying to SergeyBiryukov:

However, plugins that get updates outside of the repo don't get this opportunity if they are not active. I suppose this is expected since the plugin is not active (and therefore does not have the ability to filter the update_plugins transient or the plugins_api function)

Sounds like the filtering should be in another (network activated) meta plugin.

Are you insinuating here that WordPress should do this or that plugin authors should do this?

#4 follow-up: @markoheijnen
11 years ago

The only thing I can imagine is that you can provide an alternative url for the version check as a comment. What calls the url and that url only returns the version number and nothing more.

#5 in reply to: ↑ 4 @griffinjt
11 years ago

Replying to markoheijnen:

The only thing I can imagine is that you can provide an alternative url for the version check as a comment. What calls the url and that url only returns the version number and nothing more.

At a minimum the check needs to return the version number and a download package that can be referenced if an update is available.

#6 in reply to: ↑ 3 ; follow-up: @SergeyBiryukov
11 years ago

Replying to griffinjt:

Are you insinuating here that WordPress should do this or that plugin authors should do this?

Since custom repositories are not going to be supported by core, I guess plugin authors who need a custom repository should create a meta plugin (intended to be network activated) which would add support for that repository, allowing inactive plugins to also be checked.

#7 in reply to: ↑ 6 @wpmuguru
11 years ago

  • Keywords 2nd-opinion removed

Replying to SergeyBiryukov:

Replying to griffinjt:

Are you insinuating here that WordPress should do this or that plugin authors should do this?

Since custom repositories are not going to be supported by core, I guess plugin authors who need a custom repository should create a meta plugin (intended to be network activated) which would add support for that repository, allowing inactive plugins to also be checked.

I develop plugins that are hosted on private repositories and agree that this is the best solution. WP core cannot reasonably be loaded up with a list of all third party plugin repositories. Nor do I think that most people running said repositories would want their repositories being automatically checked by all wP installs.

I'm for won't fix.

#8 @rmccue
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Plugins can do this already with the filters and actions already in core. There are only a few places where this is slightly challenging, but it's still very possible.

I'm going to close this as wontfix, since the capability is already there and it's not particularly hard to use. In multisite, the same applies, but using network activation is a must.

#9 @scribu
11 years ago

Yep, I have developed such an updater plugin (and know several other WP shops that have done the same) which works fine in Multisite, so it's definitely doable, without any changes to Core.

#10 follow-up: @griffinjt
11 years ago

I've developed a way around it. Won't fix is fine by me.

#11 @scribu
11 years ago

Follow-up: #22377

#12 @SergeyBiryukov
11 years ago

#25314 was marked as a duplicate.

#13 in reply to: ↑ 10 @farinspace
11 years ago

Replying to griffinjt:

I've developed a way around it. Won't fix is fine by me.

I'm interested in know how you worked around the issue of a plugin being deactivated and still being able to check for updates on its own repo/api .. is it doable with current core functionality.

With some more research the option of having the plugin install an "mu-plugin" which is constantly on after initial activation seems like an option (but still a problem if a user installs the plugin and never activates it)

Last edited 11 years ago by farinspace (previous) (diff)
Note: See TracTickets for help on using tickets.