Plugins cannot be updated when getting updates from outside the repo

[griffinjt]

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.

[SergeyBiryukov]

Related: #13067

[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.

[griffinjt]

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?

[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.

[griffinjt]

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.

[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.

[wpmuguru]

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.

[rmccue]

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.

[scribu]

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.

[griffinjt]

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

[scribu]

Follow-up: #22377

[SergeyBiryukov]

#25314 was marked as a duplicate.

[farinspace]

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.