See title.
SEOPress 5.x now uses core methods that are only available in WP 5.x (specifically WP_Screen::is_block_editor), despite claiming compatibility with WP 4.7 on their repo page.
I have a Pro subscription so have reached out to support, I’ll update this thread when I have news.
That’s not good. I also have Pro and use it on one CP site. I messaged before about supporting CP, a year or so ago. Let’s see what he says. Hopefully he’ll fix it and keep it compatible with 4.9.
I still think CP ought to have some of these newer functions (or the migration plugin should supply them), so that there aren’t fatal errors.
There’s actually a discussion about shims plugin, that we may get soon.
Anything wrong with Classic Seo?
I am using my own solution which works just fine on CP, so I did never test Classic SEO, but I believe CP main site uses it, if I am not wrong.
Might be worth looking into it
Also, since it is a tad offtopic I added a discussion here about the main problematic I see here.
Classic SEO lost its lead developer earlier this year and so I’m wary of it until that is rectified. There have been no commits since March.
It’s also based on Rank Math which uses a huge amount of obfuscated JS in the back end, making it difficult to investigate problems.
Even though SEOPress isn’t coded particularly well, the code is at least easy to understand and I like the admin UX compared to other SEO plugins.
I even started writing my own but client work is taking all my time these days.
If I’m not mistaken, we were able to get source files from RankMath team.I remember seeing discussion about this either here or Slack. Not sure if it ever made to the repo.
Wouldn’t it save you time to pick up dev on Classic SEO? Just a thought 
Not as far as I can see.
LOL - see the rest of my sentence. I also don’t like working on other people’s code. It makes me want to rewrite it and then suddenly I’ve lost several days…
I agree with that. Taking existing code and maintaining it, unless blunt easy simple code, is a nightmare.
Same nightmare as maintaining forks of existing plugins (or themes).
With limited resources, forks are faster and easier to get out the door. Refactoring or building something new can be left for a future version. Plus, you can learn from forks. What works and what doesn’t work.
@anon95694377 if you decide to build an SEO plugin for ClassicPress and WordPress, we’ll be happy to help test it and offer any help we can.
I am just a user(creator) always looking for ways to contribute, so I tried ZP SEO on two CP sites. Where should I post the results?? 
Wherever you like! But probably either here or a new thread in the plugins category would be best.
Great, I’ll write it up and post it at plugins support. I thought maybe you would want it at Github or something, since you said it wasn’t ready yet.
SEOPress have now released 5.0.4 which has fixed the fatal error.
However, there are now other problems on the plugin’s admin pages - missing dashicons (presumably because dashicons added more icons after 5.0) and bad button styling (presumably some core admin styles were changed after 5.0).
I’ve posted those issues on my ticket so we’ll see what happens.
My gut feeling is that they won’t fix them.
Just got a quick response back from SEOPress. They’ve confirmed that cosmetic issues like icons and buttons won’t be fixed, and that WP 5.4 would be needed to resolve those issues.
They said that they can’t continue to maintain 100% perfect compatibility with older versions.
So SEOPress (in its latest version) is functionally OK with ClassicPress, but has some cosmetic issues, and my feeling is that these cosmetic issues will probably increase, version by version.
There will also come a point when SEOPress decide that keeping even functional backward compatibility is too much of a resource drain, and based on the frequency at which they release new features, I suspect that point will come fairly soon - probably within 6 months.
For the cosmetic icon stuff, we are looking into this Fix Dashicons as per #695 by mattyrob · Pull Request #769 · ClassicPress/ClassicPress · GitHub
I still prefer placing redirects directly into the .htaccess file, which doesn’t need a plugin.
That’s not always possible. A few reasons I use a plugin:
So it’s nice to have a redirects plugin, especially if they have a few nice bells and whistles. One feature I would pay for is keyword replacement. Pretty Links plugin stopped working with CP, which is what I was using before for redirects and keyword replacement. You specified specific keywords for each redirect, and the plugin would automatically hyperlink that keyword in posts/pages. You could specify how many keywords in one post to replace, etc. This is helpful for affiliate marketing, but also good for SEO and internal links. Just something for @anon95694377 to consider for the Pro version.
Luckily, I have a lifetime subscription with SEOPress. So I’ll keep using it with WP websites, but will switch to either Classic SEO or ZP SEO when I find time to do so. Thanks for letting us know.
PS. On the very large htaccess file point. A client asked me to put 40,000 URL redirects into htaccess file which were created by a fake pharmacy website due to a hack and they were indexed by Google. She thought htaccess would be the best option since everyone says so. Let’s just say performance went dooooown
In this situation I probably would have pushed to leave these invalid URLs as 404 as they arguably should be. Also, this kind of batch redirect can often be done with regexes and a couple of lines. If not, I would consider a short bit of custom code.
All of these other points do have solutions also, for example, there are ways to expose a list of redirects for nginx to follow; clients shouldn’t be doing redirects anyway IMO; and server logs can provide the necessary information for analytics.
I personally prefer to use lower layers of the system when possible, rather than installing more plugins. To each his own, though.