plugin_auto_update_debug_string does not receive plugin file path

[bpayton]

This filter receives plugin information but no indication of the plugin file. For example:

Array
(
    [Name] => Akismet Anti-Spam
    [PluginURI] => https://akismet.com/
    [Version] => 4.1.6
    [Description] => Used by millions, Akismet is quite possibly the best way in the world to <strong>protect your blog from spam</strong>. It keeps your site protected even while you sleep. T
o get started: activate the Akismet plugin and then go to your Akismet Settings page to set up your API key.
    [Author] => Automattic
    [AuthorURI] => https://automattic.com/wordpress-plugins/
    [TextDomain] => akismet
    [DomainPath] =>
    [Network] =>
    [RequiresWP] =>
    [RequiresPHP] =>
    [Title] => Akismet Anti-Spam
    [AuthorName] => Automattic
)

We have a WordPress.com use case where sites can have both platform-managed and user-installed plugins. The user-installed plugins can be auto updated by the site, but the platform-managed plugins cannot.

The auto_update_plugin and plugin_auto_update_setting_html both receive objects with a reference to the plugin file, and we use that information to look at the plugin on disk and determine whether the plugin is auto-updatable. The plugin_auto_update_debug_string filter does not provide this information, making it difficult to provide useful auto update debug strings for the Site Health page.

[pbiron]

Thanx for the report.

I can definitely see the usefulness of passing the plugin filename to that filter (and parity with plugin_auto_update_setting_html would be good thing).

It is very late in release cycle (with RC1 already released), but since this is a new filter in 5.5 maybe adding that param would be OK...and if we wait for 5.5.1/5.6 to add it then the order of the params of those 2 filters would be different and could possibly cause confusion for developers.

I'm leaning towards adding it in a future release. What do you think @clorith, @audrasjb ?

[johnbillion]

Moving to 5.5 for visibility.

[audrasjb]

Thanks for the report @bpayton !

Agree with @pbiron. While it's a very interesting input, I'd suggest to address this in the next minor. By the way, I'd defer to the release coordinator for the final decision.

[pbiron]

In the off-chance that the release coordinator thinks this should land in 5.5, 50821.diff​ adds the param.

Note: as far as I can tell, an equivalent change is not needed for the theme_auto_update_debug_string filter, since that is a passed a WP_Theme object which has methods to get the equivalent info for a theme.

[audrasjb]

Whatever the final decision is, the patch is good on my side and I can make an update to the exiting devnote. Thanks for the patch @pbiron.

Let's pass the baton to @whyisjake and @SergeyBiryukov for final decision, as Release coordinator and Tech lead for WP 5.5 :)

[SergeyBiryukov]

I see no problem landing this in 5.5 RC2.

[whyisjake]

In 48696:

Upgrade/Install: Pass the plugin file path into the plugin_auto_update_debug_string filter.

Adds better tooling for when user specific plugins can be updated, but platform specific ones cannot.

Fixes #50821.
Props bpayton, pbiron, audrasjb, SergeyBiryukov, whyisjake.

[whyisjake]

In 48697:

Upgrade/Install: Pass the plugin file path into the plugin_auto_update_debug_string filter.

Adds better tooling for when user specific plugins can be updated, but platform specific ones cannot.

This brings [48696] to the 5.5 branch.

Fixes #50821.

Props bpayton, pbiron, audrasjb, SergeyBiryukov, whyisjake.

[bpayton]

Thanks to everyone involved and for the quick turnaround!