I first raised this back in January.
2 Likes
Done! Works well. I think this should be included in the CP distribution by default! 
3 Likes
BTW I can confirm that if a plugin officially requires WP 5.0+, and you run it on CP, then it will not push any notifications about updates.
I have confirmed this on a site that I cannot disclose here but I have notified its owner because there are … guess what, disclosed, unpatched (due to outdated plugin) vulnerabilities on said site (thru its plugins)
So yes, this is urgent. I have seen that there are CP installs actually using plugins requiring 5.0 and I am not sure why this unwise choice was even made, but the results are exactly those: Updates are not pushed. And thus, security issues are left open.
1 Like
When I chose ClassicPress, I know that these things will be an issue, but I jumped in anyway, hoping for the best. And now I am glad that the developers are actively facing these problems.
I think that the advantages of using CP far outweighs the pains involved in a growing CMS. As they say — no pain, no gain. As for me, after I’ve built my website, I plan to manually monitor the plugins I’m using.
I used your plugin to find a couple more WP plugins to use, but I didn’t know it can give warnings about outdated plugins. But how about other WP plugins not on the list? I have some of those.
@Paul the creator of Shield Security, is an active member of this community, and though I can’t speak for him, I take it that he’s willing to support CP in the long term. Thanks Paul!
2 Likes
That’s awesome! Must say I am pretty impressed (as a staunch WordFence user… 
) how it “looks and feels” so far.
2 Likes
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.
One thing that needs to be thought through further is what the call to action would be for this notice. When there is a core update available it is simple: “Please update now”. However, when there are potentially incompatible plugin updates available, the solution may not be so simple.
The simplest call to action would be to disable the affected plugins. This is easy for us but it’s likely to degrade the functionality of the affected sites.
We might consider adding a feature that lets site owners opt-in to report these incompatible plugins to our API server so that we can see which plugins are most commonly in this situation, and a way to offer to install forked versions of the most common plugins. It would be a lot of work to maintain this but I can’t think of another solution that would fix this issue while keeping the affected ClassicPress sites in full working order.
5 Likes
That would be an ideal solution. I could then add some code to my utility plugin to send me an email if this happens, the same as I do for plugin updates.
If this is sorted out then I can confidently start using CP again. 
1 Like
Shield Security is in ClassicPress directory since they support CP.
It’s in the directory with the same name as for WP repo so I don’t know if the two versions are different, but since it’s there it can be considered a CP plugin.
I think we should leave it to the user deciding what to do ultimately and not disable things for them.
Since this is clearly encompassing security I think it’s ultimately something to put in our famous security page
We could:
- check for outdated plugins in General and list them
- check for plugins requiring 5.0+ and state that those might be out outdated
- provide a clear message why outdated plugins can be a problem but without generating panic
Something like:
We detected outdated plugins on your site. We suggest you consider updating them. (Link to a doc post about security)
And for the case where we detect plugins with a 5.0+ requirement:
We detected plugins that require WordPress 5.0 and above. You will not receive notifications when they update. Please visit the plugins page (link) and consult with the author of security updates are necessary. It might be safe to continue running this plugin but we suggest looking for alternatives (link to our repo)
There’s a problem case when the user has a plugin installed that still required 4.0 above WP on current install but bumped its requirement during an update
They won’t see those update nags.
That means we’d have to query WP remote api to check if the plugin requires a update and that means we’d add slowness in the backend.
Perhaps here a button that can be clicked (instead of a always running query) could help:
„Check for issues with plugins“.
Then only we run the code to check for updates of those plugins.
This way we could avoid overhead and still offer a way to find potentially unsafe code
I didn’t look at the plugin but I think it should be possible running the plugins queries on demand instead of always, speak „on press of a button“
Said button of course would live in security page.
I would agree with that. A clear, prominent warning should be sufficient.
I like this idea. I’ve always thought CP needs to be targeting the most-used plugins to make sure there are good working alternatives for users. This would help find out where work was most needed.
1 Like
While we add something more robust to the core, why don’t we make the migration plugin either recommend or pre-install/activate @Simone’s plugin when migrating WP to CP? This could help “solve” the temporary updates issue now. Give us time to develop a robust solution in the core that @james described above.
4 Likes
I think this will work much better if it is not hidden away inside the security page, rather, it should be always active and completely integrated into the plugins screen like Simone’s plugin is.
Since CP is already checking for updates for WP plugins, there shouldn’t be any extra network requests, it is more a matter of making better use of the information that CP already has available to it.
6 Likes
Is this something we can squeeze into 1.3.x or wait until 1.4 or 2.0?
1.3.0 is already in the release candidate stage with the recent release of 1.3.0-rc2. A release candidate should be exactly the same as the final release, unless there are issues with the changes to be included in that release, so 1.3.0 is already set.
I would consider this a new feature suitable for a minor release, so this could be released with 1.4.0 if it is coded in time.
1 Like
Right, when I wrote 1.3.x I meant more like 1.3.1, 1.3.2, etc.
A patch release like 1.3.1 would be for bugfixes or to fix specific vulnerabilities in the core code itself, which isn’t really the case here.
The difference is just semantics though - 1.4.0 can be released as soon as we think we have something ready which warrants the release.
3 Likes
After I added @Simone’s awesome plugin in response to this conversation, I am more motivated than ever to move all my sites from WP4.9 to CP, I didn’t even realize how many of the plugins on those WP sites had been updated!
I would think that besides the plugins screen, it should be on the updates screen, maybe even in the admin bar next to the updates notification. Even though I rarely look at either maybe some rely on them.
4 Likes
I’ve just released a new version of CPCompatibility.
It speeds up things and limits API requests.
I’ve revisited the code to make it cleaner (and object oriented) so it can be used to add functionality to core.
Seems that the API is returning results only if the update is compatible with the installed WP version, so there is no already fetched data.
5 Likes
