This is a direct follow up to SEOPress no longer compatible with ClassicPress, but since offtopic I split it here.
My goal is to rise A) discussion and B) awareness about what follows.
Plugins and Themes stopping to work on CP is what it will come down to for every single theme and plugin out there that is built for WP - and time is running, and not forgiving, unfortunately.
I think, we can’t rely on author promises, not only because promises or statements are just that, but also, to keep the split working between 4.9 and 5.x, is a huge amount of messy workarounds.
You basically need to run two different plugins in one, because Blocks changes so much in how things work, that most of the things working before, now wont work anymore or not anymore the same way.
Specially I can imagine SEO as in the example - if attempting to get contents from an editor - must be a big change now that it is all cluttered with the html Comments in Blocks. Thus a Seo plugin would have to maintain both options, which probably means a lot more code than just supporting one of them.
Not to speak about QA and QC processes, where you need to test your software with 3 years old versions of the core. That’s plain simple unreasonable.
IMO we should instead start accepting that we are a new CMS - even if a Fork of WP.
We need to develop our own solutions. We should not add “missing” parts from WP to CP, because that again just is copycatting and actually stops us from developing our own, new CMS with new ideas and paths to discover.
A recent comment on a post regarding how CP is the best choice of CMS for pros and businesses I wrote, pointed out this exact issue:
no matter how some plugs and themes still work now on CP, very soon those will stop working, wether the author tries to keep compatible or not, in most cases. It wont help adding missing patches here and there, because it is like patching constantly opening holes in a bathtub.
Just as an example, I recently reached out to Toolset’s CEO just to ask a formal permission to fork his plugin and he discouraged from it not because of any concerns about PRO plugins being available in CP for free (if I’d fork it) but because the backwards maintenance became almost unbearable he says - which is why he decided to drop support for 4.9x version altogether recently.
Worth mentioning that OTGS, the company behind Toolset (and WPML) has huge resources, almost a hundred developers on the payroll, and thus would surely have the technical and financial resources to do such support work.
The problems starts with simple things where is_admin is suddenly not anymore what it was before, but it doesn’t end there, the changes keep coming and rather sooner than later, nothing will be the same anymore. You even need to think about two doc versions, at some point, if you have screenshots or videos or else.
Thus I decided to code my own version of “Toolset”. Really, no joke. It will take time, but also give the chance to do it the way I believe it should be done, and be targeted for CP.
If its not worth for those bigger companies like OTGS to keep the split working, I think anyone else also will sooner or later have to think about how much work to invest in something that they do not get any (or not the main part) money out from (at least, not now). And where they are “after money”, they will go with WP, that is the where the bulk of the clients is.
Only those who truly want ClassicPress and can’t stand or work with WP 5.0+, they will make the effort to develop new things, even if it means no big for a while.
I understand those developers who decide to not support the older versions anymore.
It is not a maintainable business model if you have many people on a payroll, or even just a smaller but working business. Making the change, or maintaining the backwards compatible code, means putting anyone in jeopardy - whereas if you start fresh, with a focus put on CP, at least the risk is not affecting existing models.
As a freelancer for example, one can live off the sites built with what Clients want, and invest whatever possible into CP development. This is what I do, as much as possible. It is basically a core concept, to take the money where it is, and put it where it is needed. But this model works only for new enterprises, and rather small operations, because the big and established ones, they have profit goals to follow, and what not, yearly churn presentations to make, they can’t take a risk “that maybe pays off”. As a smaller company or freelancer, I think this is more flexible, even if we have less funds.
More than anything else, I also I believe that keep relying on WP Software, throws a “dependancy” on CP that will ultimately hurt it.
It avoids people to get real and start crafting CP solutions, which is very much required.
Thus, I’d like to open a discussion as of how we want to manage this in the coming time in the “main stream” of CP and how we suggest users to approach CP.
My personal suggestion is to highly motivate and steer developers (and users) towards creating things with CP solutions, instead of relaying on WP Software.
It may also mean that instead of developing CP core we perhaps should push work towards a few essential plugins (Commerce, SEO, surely a theme or two that is rock solid instead of the child 20xx themes), which gives a basis for CP to grow, and then we can focus back on adding new things to Core.
This also goes along with the showcase we where discussing recently in slack, where we should show not only sites built with, but Themes and Plugins working explicitly with or for CP (or definitely guarantee to keep compatibility with it)
As far I know for example there is Beaver Builder which does support it, although I do not know the precise plans on continued support. If it is just a “a long it is possible”, then it is for us a bad choice, because we’d need things to be working for the future to come.
Often, discussing with a Plugin Support or Dev about “please support 4.9” and waiting for it, or trembling at the thought they will suddenly break on CP, costs more time, effort and money than actually creating a new plugin altogether.
Just as an example - I used Views to display a slider with AJAX. It stopped working in CP. I created a custom WP Query and used owl.js to create the slider. It took me 5 hours, inclusive CSS polishing. In no way that is the same as a full fledged solution like Views, but it does exactly what I needed, is 100 times less heavy, and can be re-used. With a little more effort, a GUI can be created for the less Cody user, and there you have the first “CP Solution”, targeted for a specific purpose, developer friendly and user friendly. And it didn’t cost thousands of dollars. This kind of Solutions I think we should promote. With Showcases, Code “library” for snippets for users to get stuff from and implement, and a very active “consulting” community where people do not have to be afraid to ask if they do not now how. Those are the points where I think we can build a very strong presence with very less financial effort.