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

[vincenthasselgard]

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.

[vincenthasselgard]

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

[vincenthasselgard]

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

[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

[vincenthasselgard]

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.

[vincenthasselgard]

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

[vincenthasselgard]

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.

[SergeyBiryukov]

Related: #29046, #30465, #42981.

[vincenthasselgard]

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.

[audrasjb]

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

[vincenthasselgard]

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.

[audrasjb]

What about moving this information to site health?

[audrasjb]

Hi,

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

[desrosj]

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!

[karmatosed]

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.

[audrasjb]

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

[davidbaumwald]

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

[audrasjb]

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

[stuffradio]

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.

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

[stuffradio]

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

[stuffradio]

Accidentally removed keyword for has-patch.

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

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

[stuffradio]

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.

[stuffradio]

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.

[elrae]

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

[desrosj]

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.

[desrosj]

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

[stuffradio]

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.

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

[stuffradio]

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. :)

[stuffradio]

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?

[elrae]

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.

[stuffradio]

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

[stuffradio]

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

[stuffradio]

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

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

[stuffradio]

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]

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

[audrasjb]

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

[audrasjb]

Works for me

[garrett-eclipse]

Updated patch to improve handling of translator comments.

[garrett-eclipse]

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]

Further improve the language of the translator comments.

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

[hellofromTonya]

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

[SergeyBiryukov]

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.

[marybaum]

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.

[hellofromTonya]

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

[audrasjb]

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

[audrasjb]

In 49151.4.diff, use sentence case

[audrasjb]

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

[helen]

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.

[stuffradio]

Replying to helen:

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.

What if there was a "Screen Options" available here where it could be toggled? My thinking behind this is that a WordPress admin is already used to using "Screen Options" to show/hide information on certain pages, so it would seem intuitive enough to me to just take advantage of this space to have an admin toggle the information there.

[MattyRob]

From a user experience of using the plugin page - what are we going to expect blog owners and admins to do when they see this message?

Presumably, there are three main options open to them:
1/ Disable and deactivate the plugin and loose whatever functionality it gave them.
2/ Disable the plugin and try to find a suitable replacement.
3/ Ignore the message if the plugin is vital and there are no suitable replacements.

In the case of the third option should we not be including some kind of logic to allow the nag message to be hidden when a site users has seen it and decided to do nothing about it?

[Guillermo77]

I was thinking about my ticket #52960,

Can be good one e-mail notification, from the wordpress account, this plugin xxxx is dangerous critical issue, you need action in your site xxxx now. In my website I no have e-mail from my provider,

And you can add, in 3 months this plugin will be deleted from your web automatically,
Maybe after 3 months or one year for example in one critical error can delete the plugin automatically from the website?

You can alert in admin section updates, and with one central banner, Plugin was definitive closed for critical issues you need search another plugin similar and delete this plugin now, in xxx days (counter) will be autodeleted.

And put one notification if the admin no log in 3 months, this plugin xxxx was autodeleted for critical issues xx days ago, search one similar in add plugin.. the notification will show after the admin close it, and will be available for 1 week for exp., so he/she know what plugin was deleted.
You can have one history plugin installed, like google play store apps.

If the plugin is critical but will receive one patch, we recommend disable this plugin, developer is working in one solution.

I no sure about this, if one update have many errors, you can back to the last stable version of this plugin pressing here.

Is true now we have health, but put one mark or change the color in plugin section if the plugin was discontinue by the owner, maybe is more direct and visual, and you have time for search another plugin similar.

I think wordpress can be better and more simple, I have many ideas.

That are just some ideas from one user (i am new here sorry and my english no is good),
thanks for read

[audrasjb]

Moving for 6.0 consideration.

[Hareesh Pillai]

Moving for 6.4 consideration.

Aligning on the approach and trying to address the queries raised above will help move it forward.

[oglekler]

I am personally thinking that this is very important information, and it cannot be only present in the Site Health, because people most likely will notice it in the plugins page doing their business and Site Health needs to be open separately and this can be easily postponed for until something will be broken.
Can we add this info into 2 places, possibly by tho tickets?

[oglekler]

Moving this into 6.5 for further discussion.

[premaanjum]

We can make the warning stand out by putting it in red text inside a quotation box.

"Caution: This plugin hasn't been checked with the latest 'x' WordPress updates. It might not work well with the newest WordPress version or might not be actively supported anymore."

[ukdrahul]

Replying to premaanjum:

We can make the warning stand out by putting it in red text inside a quotation box.

"Caution: This plugin hasn't been checked with the latest 'x' WordPress updates. It might not work well with the newest WordPress version or might not be actively supported anymore."

---

I believe maintaining the same color codes and design as the existing wordpress.org's design would be the best approach. This consistency will eliminate confusion and uphold a unified design and UX across platforms.

[rednishat]

Replying to premaanjum:

We can make the warning stand out by putting it in red text inside a quotation box.

"Caution: This plugin hasn't been checked with the latest 'x' WordPress updates. It might not work well with the newest WordPress version or might not be actively supported anymore."

We can show something like this right into the plugin dashboard:

[swissspidy]

6.5 Beta is approaching soon and there hasn't been any traction on this in a while. Punting for now so it can be picked up in the next cycle.

[zodiac1978]

We allow every plugin developer to add as many links/icons/images to this plugin page as wanted, but we are discussing if we add essential information like "last updated"!?

From a supporter and maintenance perspective, this information is crucial and should be shown.

Directly on this plugin list page would be best. If this is not possible due to performance or other reasons, it could be added to Site Health. But we shouldn't add this to the existing Site Health UI without further thoughts.

There are plugins that are doing this job already:
​https://wordpress.org/plugins/plugin-report/

And this plugin shows more needs for such a solution. Even more important is the information that a plugin was closed on the plugin directory. This is not shown at all and is (mostly) much worse than a plugin which is just not updated for a while. Very simple plugins may not need updates, they just still work.

I would recommend adding this as a new tab for the Site Health feature. Maybe only in the plugin first.

The warnings on the plugin list table (as mentioned and mocked up above) should be added for closed plugins, IMHO.

Both features would help with the security of WordPress and align with the core and plugin principles in general and for this specific feature.