WordPress.org

Make WordPress Core

Opened 11 months ago

Last modified 5 weeks 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: Future Release Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-screenshots has-patch needs-design-feedback
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 (11)

wp_plugin_old.png (33.0 KB) - added by vincenthasselgard 11 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 11 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 11 months ago.
Skjermbilde 2020-01-08 kl. 12.41.34.png (17.8 KB) - added by vincenthasselgard 11 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 6 months ago.
What about moving this information to site health?
49151.diff (4.3 KB) - added by audrasjb 7 weeks ago.
Site Health: Show a warning for plugins and themes that have not received updates in a long time.
Capture d’écran 2020-10-10 à 23.22.55.png (158.6 KB) - added by audrasjb 7 weeks ago.
Works for me
49151.2.diff (4.4 KB) - added by garrett-eclipse 6 weeks ago.
Updated patch to improve handling of translator comments.
49151.3.diff (4.4 KB) - added by garrett-eclipse 6 weeks ago.
Further improve the language of the translator comments.
49151.4.diff (4.6 KB) - added by audrasjb 5 weeks ago.
Small i18n changes and uses a variable to avoid double function call
Capture d’écran 2020-10-20 à 15.36.04.png (227.5 KB) - added by audrasjb 5 weeks ago.
In 49151.4.diff, use sentence case

Download all attachments as: .zip

Change History (62)

@vincenthasselgard
11 months ago

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

@vincenthasselgard
11 months ago

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

#1 follow-ups: @dkarfa
11 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
11 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 11 months ago by vincenthasselgard (previous) (diff)

@vincenthasselgard
11 months ago

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

#3 in reply to: ↑ 1 @vincenthasselgard
11 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
11 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
10 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
10 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.


6 months ago

@audrasjb
6 months ago

What about moving this information to site health?

#9 @audrasjb
6 months 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.


6 months ago

#11 @desrosj
6 months 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 months 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 months ago

#14 @audrasjb
6 months 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.


5 months ago

#16 @davidbaumwald
5 months ago

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

#17 @audrasjb
5 months 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
5 months 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.


5 months 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
5 months 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
5 months ago

  • Keywords has-patch added

Accidentally removed keyword for has-patch.

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


5 months ago

#23 follow-up: @elrae
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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
5 months 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 5 months ago by stuffradio (previous) (diff)

#34 @elrae
5 months 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.

#35 @stuffradio
4 months ago

  • Keywords needs-refresh removed

@elrae @desrosj I have added more details now. Now the active/inactive themes show the last release date.

#36 @stuffradio
4 months ago

My PR failed only for PHP 7.4 and I have no idea why.

#37 @stuffradio
4 months ago

Well it's actually showing the PR did pass the builds. Awaiting feedback now :)

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


2 months ago

#39 follow-up: @hellofromTonya
7 weeks ago

  • Keywords needs-refresh added

The PR has a merge conflict. @stuffradio can you update the PR?

@audrasjb or @desrosj Is this PR on your radar to land in 5.6 Beta 1?

#40 in reply to: ↑ 39 @stuffradio
7 weeks ago

  • Keywords needs-refresh removed

Replying to hellofromTonya:

The PR has a merge conflict. @stuffradio can you update the PR?

@audrasjb or @desrosj Is this PR on your radar to land in 5.6 Beta 1?

Done

@audrasjb
7 weeks ago

Site Health: Show a warning for plugins and themes that have not received updates in a long time.

#41 @audrasjb
7 weeks ago

49151.diff refreshes the last patch (PR) against trunk.

@garrett-eclipse
6 weeks ago

Updated patch to improve handling of translator comments.

#42 @garrett-eclipse
6 weeks ago

In 49151.2.diff I've refreshed the patch to ensure each string with an %s has a translator comment. and we apply one per string as there was some where it was one comment for two strings.

I also moved the includes to the top of the function so future uses don't have to move it around to make it available earlier in the function.

I am wondering if we should remove the | and , separators from the string so they're not in the translation string.

And with the strings so similar ' | Last Theme release: %s ago' and ', last theme release: %s ago' (also the same for plugins) can we somehow merge them, as aside from case they're identical.

And one final thought should a threshold be introduced so themes/plugins that are X (1 year maybe) old with no releases get denoted with a warning?

@garrett-eclipse
6 weeks ago

Further improve the language of the translator comments.

#43 follow-up: @garrett-eclipse
6 weeks ago

After re-reading the patch I improved the translator comments in 49151.3.diff.
Theme last released time. => Time since last theme release.
Plugin last released time. => Time since last plugin release.

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


6 weeks ago

#45 @hellofromTonya
6 weeks ago

  • Keywords needs-testing needs-copy-review added

Per scrub today, this ticket needs-testing and needs-copy-review. Then it's ready for commit, ie pending changes.

#46 @SergeyBiryukov
6 weeks ago

Last Theme release

Just a quick note that we don't generally capitalize "theme" or "plugin" in the UI, so that could probably just use sentence case. Also ' | ' and ', ' separators should be moved out of the translatable strings.

Last edited 6 weeks ago by SergeyBiryukov (previous) (diff)

#47 in reply to: ↑ 43 @marybaum
6 weeks ago

Theme last released on %s.
Pligin last released on %s.

Replying to garrett-eclipse:

After re-reading the patch I improved the translator comments in 49151.3.diff.
Theme last released time. => Time since last theme release.
Plugin last released time. => Time since last plugin release.

#48 @hellofromTonya
6 weeks ago

@garrett-eclipse Can you add more screenshots for the latest patch please?

@audrasjb
5 weeks ago

Small i18n changes and uses a variable to avoid double function call

@audrasjb
5 weeks ago

In 49151.4.diff, use sentence case

#49 @audrasjb
5 weeks ago

  • Keywords needs-testing needs-copy-review removed

49151.4.diff: uses sentence case phrasing.
@SergeyBiryukov it looks better to me now.

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


5 weeks ago

#51 @helen
5 weeks ago

  • Keywords needs-design-feedback added
  • Milestone changed from 5.6 to Future Release

Taking a look here - I have some issues and am going to punt this for the moment (it can be brought back if we feel super strongly about it):

  • The "Last updated" date is a little misleading because it's when the item was last updated on .org, but within the site health context it reads like when the item was last updated on your site. Presumably for many sites those are the same thing, but I don't think that's universally the case enough that we can phrase it this way.
  • I still would like for the full date to be available somewhere/somehow, whether displayed as a parenthetical or using something like abbr to make it available in another way (whatever is semantic and accessible, of course).
  • If we're looking at this as a piece of information to help site admins decide what can be cleaned up based on inactivity, it is impossible to scan in this format and I am not sure line breaks would help much if they can even be added. Adding it only to site health feels just informational and not actionable.

I think I'd like to see some exploration about how to enable the workflow that I think is being described here, which is a site admin who is reviewing/managing plugins based on whether it's been kept updated. I agree that adding banners/notices inline in the full list view is probably going to end up overwhelming and ignored, but maybe there's an alternative like an "Outdated" filter or something like that.

Note: See TracTickets for help on using tickets.