WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 6 days ago

#49151 accepted feature request

Show a warning for plugins in WP admin that haven't received updates in a long time

Reported by: vincenthasselgard Owned by: audrasjb
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-screenshots has-patch needs-refresh
Focuses: ui, administration, ui-copy Cc:

Description

When upgrading plugins in WordPress admin users are very likely to miss plugins that aren't receiving regular updates from their authors. The same warning (or similar) that's displayed on WordPress.org plugin repo should be displayed in the same manner as available plugin updates on the WordPress admin plugin page.

Attachments (5)

wp_plugin_old.png (33.0 KB) - added by vincenthasselgard 6 months ago.
Suggestion for how the warning may be displayed on the plugins list in WP admin.
Skjermbilde 2020-01-08 kl. 11.15.02.png (32.6 KB) - added by vincenthasselgard 6 months ago.
Suggestion for how the warning may be displayed on the plugins list in WP admin (Ignore previous file)
Screenshot 2020-01-08 16.59.20.png (107.3 KB) - added by dkarfa 6 months ago.
Skjermbilde 2020-01-08 kl. 12.41.34.png (17.8 KB) - added by vincenthasselgard 6 months ago.
Screenshot of old plugin installed on a site with no warning displayed.
Capture d’écran 2020-05-28 à 18.18.39.png (68.2 KB) - added by audrasjb 7 weeks ago.
What about moving this information to site health?

Download all attachments as: .zip

Change History (39)

@vincenthasselgard
6 months ago

Suggestion for how the warning may be displayed on the plugins list in WP admin.

@vincenthasselgard
6 months ago

Suggestion for how the warning may be displayed on the plugins list in WP admin (Ignore previous file)

#1 follow-ups: @dkarfa
6 months ago

Hi @vincenthasselgard,
Welcome to WordPress Trac! Thanks for the report, I believe it already address. I cannot see the same in latest trunk version.

Cheers,
Debabrata Karfa

#2 in reply to: ↑ 1 @vincenthasselgard
6 months ago

Replying to dkarfa:

Hi @vincenthasselgard,
Welcome to WordPress Trac! Thanks for the report, I believe it already address. I cannot see the same in latest trunk version.

Cheers,
Debabrata Karfa

What I'm suggesting is a warning for plugins that hasn't received updates. Such as the case is with this plugin which is 8 years old https://wordpress.org/plugins/page-menus-widget/

The warning is there in the plugin repo, but if it's already installed on your site there's no warning. I'll upload a screenshot of how this plugin is displayed in the WP admin plugin list.

Last edited 6 months ago by vincenthasselgard (previous) (diff)

@vincenthasselgard
6 months ago

Screenshot of old plugin installed on a site with no warning displayed.

#3 in reply to: ↑ 1 @vincenthasselgard
6 months ago

Replying to dkarfa:

Hi @vincenthasselgard,
Welcome to WordPress Trac! Thanks for the report, I believe it already address. I cannot see the same in latest trunk version.

Cheers,
Debabrata Karfa

I uploaded the screen shot of how it currently is. My suggestion is that we add the same info that is on this page https://wordpress.org/plugins/page-menus-widget/ to the list of plugins in the WordPress admin in the same manner as the update notifications are shown.

#5 @vincenthasselgard
6 months ago

I made a simple plugin as a proof of concept for this https://github.com/vincenthasselgard/plugin-last-updated-warning. The plugin checks the WP.org API for all installed plugins last updated info and uses a DateTime diff to check if it's more than a year. If it is it adds a warning with information on how many years it's been since the last update on the installed plugins list.

#6 follow-up: @audrasjb
5 months ago

  • Owner set to audrasjb
  • Status changed from new to accepted

Hello, let's try to add this ticket to milestone 5.4. It would be a good nice-to-have alongside #48850.

#7 in reply to: ↑ 6 @vincenthasselgard
5 months ago

I did a quick proof of concept in the form of a plugin, some of the code might be reusable. It's on github: https://github.com/vincenthasselgard/plugin-last-updated-warning

Replying to audrasjb:

Hello, let's try to add this ticket to milestone 5.4. It would be a good nice-to-have alongside #48850.

This ticket was mentioned in Slack in #core-committers by audrasjb. View the logs.


7 weeks ago

@audrasjb
7 weeks ago

What about moving this information to site health?

#9 @audrasjb
7 weeks ago

  • Keywords has-screenshots added
  • Milestone changed from Awaiting Review to 5.5

Hi,

Shouldn’t we rather handle that in Site Health screen first?
I made a quick proof-of-concept (see screenshot above).

This ticket was mentioned in Slack in #core-site-health by audrasjb. View the logs.


7 weeks ago

#11 @desrosj
7 weeks ago

I think this is a good thing to add, but I am against adding it inline on the Plugins page. Users are frequently overwhelmed by admin notices added by plugins. I think an average site would have more plugins with this notice than without it, and it would devalue/drown out the inline update notices that appear.

I like the idea of putting a plugin/theme health report of some sort in Site Health. It feels more at home there. But I don't know that adding it inline there is appropriate. I wonder if a new tab would be warranted.

Some design feedback would be very useful here!

#12 @karmatosed
6 weeks ago

I have to agree with @desrosj on this one. I would love to see site health become a 'one-stop for knowing about your site'.

Our plugin pages are a lot to process right now. In that situation, I tend to think quite hard over what is really crucial information there and what could go somewhere else. That's why I lean even more to site health for this. I also think the copy needs some crafting to soothe and guide. Not having updated might not be a bad thing, so best to not worry people.

This ticket was mentioned in Slack in #core-site-health by audrasjb. View the logs.


6 weeks ago

#14 @audrasjb
6 weeks ago

  • Keywords needs-design removed

I agree with the above comment.

Wording proposal:

Replace This plugin wasn't updated since X years
with something like Last update: X years ago (and less than one year ago if the time diff is equal to 0, which is the case if plugin was updated less than one year ago).

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


13 days ago

#16 @davidbaumwald
13 days ago

@audrasjb Is this one still on your list to handle with 5.5 Beta 1 approaching next week?

#17 @audrasjb
12 days ago

@davidbaumwald I think this one could stay in 5.5 until the end of the week, but it will need a patch in the next couple days.

#18 @stuffradio
10 days ago

I got this mostly working for some things but it's not all completed yet on my end. Not sure if I should submit a patch yet.

This ticket was mentioned in PR #392 on WordPress/wordpress-develop by cwuensche.


7 days ago

  • Keywords has-patch added

Added information to site health data for active and inactive plugins displaying how long it has been since a plugin was updated.

Trac ticket: https://core.trac.wordpress.org/ticket/49151

#20 @stuffradio
7 days ago

  • Keywords has-patch removed

@audrasjb Created a patch but I will keep going through to see if I missed anything. Feedback requested :)

#21 @stuffradio
7 days ago

  • Keywords has-patch added

Accidentally removed keyword for has-patch.

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


7 days ago

#23 follow-up: @elrae
7 days ago

A few notes on the patch:

  • This introduces a new variable on line 835 $plugin_slug but I don't see that variable actually being used within the foreach context. We should either remove that new line or use it for its intended purpose
  • do we need a new function to get the plugin info? I thought there was already a way to get all that information for plugins. If there isn't, an minimum we should probably store this health data in a transient (with a filter to allow custom plugins to tap into it) the same way the plugin update transient works. This way you aren't hit with 60+ curl calls on every page health load if you're loading it multiple times. Chances are if you're visiting the health area it's to fix problems so you'll constantly fix a problem, then reload to see if it's fixed.

#24 follow-up: @Hareesh Pillai
7 days ago

  • Focuses ui-copy added

I'd rather have this Last update text at the end of the row. Having it in the second position leads to the Auto-updates text moving between 2nd and 3rd position. Looks inconsistent and makes it difficult to scan the page.

#25 in reply to: ↑ 24 @stuffradio
7 days ago

Replying to Hareesh Pillai:

I'd rather have this Last update text at the end of the row. Having it in the second position leads to the Auto-updates text moving between 2nd and 3rd position. Looks inconsistent and makes it difficult to scan the page.

I have now made this adjustment.

#26 in reply to: ↑ 23 @stuffradio
7 days ago

Replying to elrae:

A few notes on the patch:

  • This introduces a new variable on line 835 $plugin_slug but I don't see that variable actually being used within the foreach context. We should either remove that new line or use it for its intended purpose
  • do we need a new function to get the plugin info? I thought there was already a way to get all that information for plugins. If there isn't, an minimum we should probably store this health data in a transient (with a filter to allow custom plugins to tap into it) the same way the plugin update transient works. This way you aren't hit with 60+ curl calls on every page health load if you're loading it multiple times. Chances are if you're visiting the health area it's to fix problems so you'll constantly fix a problem, then reload to see if it's fixed.

Latest update fixes the fact that the variable on line 835 wasn't being used anywhere.

For your second question/point, I would like feedback on how I should do this. I was trying to figure out ways to get the plugin info easily. The code I'm using comes from the file wp-admin/includes/plugin-install.php and the function is plugins_api(). So if there's a way I could easily use this and get the same result in my patch without rewriting everything, I welcome suggestions. I will try and see if I can do this myself too.

#27 @elrae
7 days ago

@stuffradio - I didn't have enough time earlier to investigate fully but have had some more time to look into this. We can leverage the plugins_api function to help reduce the amount of code you've written. A few more pointers on the code:

add include_once ABSPATH . 'wp-admin/includes/plugin-install.php'; // For plugins_api(). above line 830. This will let us use the plugins_api function.

Then later in the foreach loop we could do something like

`$plugin_slug = explode( '/', $plugin_path );

$plugin_info = plugins_api('plugin_information', array('slug' => $plugin_slug[0]));`

and that will expose $plugin_info->last_updated which we can use to output the last updated.

I'm not sure if we need the && ! array_key_exists( $plugin_path, $plugin_updates ) restriction on the display, that's just basically saying if there is a plugin update then don't display the last time it was updated. But just because you have a plugin update available doesn't mean the update that is available is new, so I think we should remove that.

We may also want to include this check in the MU plugins section, since an MU plugin could be one from the repo and plugins can tap into the plugins_api to add their info.

#28 follow-up: @desrosj
6 days ago

  • Keywords needs-refresh added
  • Milestone changed from 5.5 to 5.6

With Beta 1 later today, I am going to punt this to 5.6 as it still needs some work.

I agree that the new function in the PR should be avoided in favor of plugins_api(). There is also a $fields argument that can be used to only request the information required. Something like this should work:

$info = plugins_api(
	'plugin_information',
	array(
		'fields' => array(
			'last_updated',
		),
	)
);

There is also one situation I don't see discussed yet. Say version 1.0 of plugin A is installed on a site and version 2.0 is available. Currently, the patch shows the date the plugin was last updated on .org, not on the site itself. I'm wondering if this would ever be confusing to the user. "Oh, I last updated x months ago."

We may also want to include this check in the MU plugins section

I think that MU plugins should be excluded from this check, mainly because the user cannot take action to update them. But I don't feel strongly about this.

#29 follow-up: @desrosj
6 days ago

Also, is there any reason why we can't or shouldn't add similar details for themes at the same time?

#30 in reply to: ↑ 29 @stuffradio
6 days ago

Replying to desrosj:

Also, is there any reason why we can't or shouldn't add similar details for themes at the same time?

I haven't looked into it fully yet, but I don't think so. It was just out of the scope of this ticket, so I hadn't bothered to look into it yet.

#31 follow-up: @desrosj
6 days ago

Since we're punting this to 5.6, let's do both at the same time. We can open a companion ticket if necessary!

#32 in reply to: ↑ 31 @stuffradio
6 days ago

Replying to desrosj:

Since we're punting this to 5.6, let's do both at the same time. We can open a companion ticket if necessary!

I will just work on it at the same time. :)

#33 in reply to: ↑ 28 @stuffradio
6 days ago

Replying to desrosj:

There is also one situation I don't see discussed yet. Say version 1.0 of plugin A is installed on a site and version 2.0 is available. Currently, the patch shows the date the plugin was last updated on .org, not on the site itself. I'm wondering if this would ever be confusing to the user. "Oh, I last updated x months ago."

I didn't think about it this way. I wrote the code the way I did because I was thinking someone would want to know how long ago a plugin was updated so they could see if it is being supported or not. For example, I have worked in agencies in the past where they would audit a client's plugins to see if any plugins should be replaced due to a lack of updates.

Would it make sense to have some text to say "The plugin author last updated plugin: x years ago" or some more simple variant of that copy? Then we could save the "Last update: x ago" for when the person might have updated the plugin last?

Last edited 6 days ago by stuffradio (previous) (diff)

#34 @elrae
6 days ago

I didn't think about it that way either but Jonathan does bring up a valid point. Maybe the text should be like Last Plugin Release: to make it more clear?

I don't feel strongly about the MU plugin thing either so yeah maybe we should leave it off the updates. Since it does require manual work chances are you aren't as worried about them or know when the last time you did it.

Note: See TracTickets for help on using tickets.