Alert user if a WP4.9+ plugin moves to WP5


This has been discussed on the forums but I don’t think a formal petition has been put in place yet. There is a security issue with using WP4.9+ plugins if they change to WP5+. No further updates are received (including possible critical security updates) and the user is totally unaware that the plugin is now out of date. Further discussion here:

Possible implementation

I like the solution proposed by @james

I am all for including this specific feature in ClassicPress core. It should probably also show a global notice (in all admin pages) in the same style as the one that appears when a new ClassicPress update is available. It might even be a good idea to make this an “error” notice with a red border instead.

Will you be able to help with the implementation?

The coding is beyond me but I can certainly help test it.

Yes, this sounds good.

1 Like

ClassicPress will get a problem anyway if it doesn’t get a stable community of its own plugin / theme developers soon, I’m already in the process of forking BuddyPress to secure the last important plugin for my projects, because I’m slowly having to completely move away from the WordPress plugins since I only use ClassicPress. What do we do when there are hardly any current WordPress plugins available? Then ClassicPress has no arguments.


That’s a valid point and might justify not doing this check but instead moving forward with our own plugins

The problem thou is there are many cp sites with wp plugins and we’d somehow need to “warn” them

So such check could help doing that.
But it’s absolutely true that without cp plugins there’s not much of a point in it either…

I mentioned this issue over at WP Slack and Sergey said to write a ticket. (I didn’t though.)
If the WP API changed so that it reported plugin updates regardless of core version, that would help both WP and CP. The version check would have to be done on the user’s site instead of at the API, which was part of what was added to WP for plugin/theme auto-updates in WP 5.5. (Those checks are not in CP.)

Someone could write the ticket for WP to change its API. I wasn’t sure how to incentivize it without mentioning CP, because supposedly only the latest WP version is actually supported. The WP statistics page shows quite a lot of older WP versions running, though, so there are a lot of sites that have this same problem.

The CP API needs to get this right from the outset.

1 Like

Another problem is with removed plugins. As i know when querying the API for a removed plugin it just return a not-found, same that is returned for any pligin that is not in the repo.

I’m kinda tired of this “war” between WP and cp
(As in “cant open a ticket mentioning cp”, for example)

Can’t we in earths name collaborate?
Like grown ups?

We help you you help us and so on?

Does someone know people high up enough to talk?


They started it. :laughing:

I have been working on a similar plugin warning for Classic Commerce. It doesn’t come up on the dashboard, but at least it puts it into the Status Report (which is the first place you should check when you have problems).

1 Like

There are c.58,000 WP plugins available so it will be quite some time before they are all WP5+. :wink:

The big players are rapidly evolving to try and keep up with WP’s constant changes, but many small plugins don’t need to, and are content to stay at <WP4.9. These are the ones we will be using for many years because we don’t have the resources to fork all of them.

Of their nearly 60k plugins, I doubt even a few hundred of them actually matter.

1 Like

I have just created a PR with a proof of concept for this petition. The code is based on the cpcompatibility plugin developed by @Simone. Still needs a lot of work, so if anyone wants to contribute that would be much appreciated.

Also still some questions to be discussed. For example, do we allow users to dismiss the message and never see it again? Or do we keep nagging, or maybe re-nag every time a new version is released? Or re-nag once a week?

This is a screenshot of how the message(s) would look:

And the PR is here:

1 Like

Like it! Tested!
You should add a transient because every time admin_notices is fired an API call to WP is fired.

Thanks @Simone - yes we need to discuss transients. Also for whether to dismiss or keep nagging. Anyway, good to know it works for you. :+1:

1 Like

I’m all for having every notice dismissable, but if we decide that is very important to keep nagging I’d like the is-dismissable class to be removed.

1 Like

Maybe I have misunderstood, did this conversation go from “possible critical” and the user may be “totally unaware” to a dashboard permanently full of nags until the user finds a new CMS?

We sure need a “no” vote now, although 7 votes is a unanimous landslide here!

1 Like

No. Simone has just expressed a personal preference or a possible implementation. Nothing is certain yet until this pull request is approved and merged to the CMS code.

1 Like

What I mean is that if the notice is persistent is meaningless to close it and get it again on next page load… so the X button to hide is unuseful.

One thing I will add to this, plugin notices should be limited to the plugins page, especially if it concerns the updates. I don’t see a reason for it to be on the dashboard page, especially if they’re persistent.

OK, I did completely misunderstand! I completely agree that a dismissal that doesn’t actually dismiss is even more irritating :upside_down_face:

I don’t see any justification for making this warning impossible to dismiss. I’ve seen the warning and made a decision. Now please let it be quiet!

1 Like