The problem with relying on WP Software while running CP

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

Thoughts everyone?

4 Likes

Depending on plugins written for WP was never going to work long term because of the move towards Gutenberg.

Creating new plugins or forking existing ones into specific CP versions is going to be necessary.

I think I’ve got about 5 WP plugins left which I am using and need to get sorted out with replacements.

3 Likes

Hi smileBeda. (I do drop in occasionally to see how things are going here.)

The problem for me (and why I gave up on CP) is that it is not just a case of things that “stop working”. I realised that there is a far more serious problem. A plugin I was using extensively released a critical security update and at the same time moved from WP4.9 compatible to WP5+. This meant I was happily using the plugin, received no update notices and subsequently had one of my sites hacked.

And for a CMS that promotes its security credentials this is not a good look.

I think over the last year that I was using CP I contacted a number of people and said: “We should stop trying to make this another version of WP that somehow works in parallel. We need to make it a different CMS”.

Anyway, it’s good to see some new enthusiasm happening and I hope you can drive this project forward.

1 Like

Thanks @ozfiddler - this puts my concern in a few concise lines, actually.

I would be in favour of saying “if you use cp then we don’t suggest using WP plugins” directly on our user guides.

And I belong to those people who believe we need to start “development towards a standalone” instead of backporting wp into cp.

This is also why I suggest a “freeze” of core development in a stable version until we have a ecosystem of MVPs available.

Thanks for the feedback. It’s exactly a (sad) example of what can and will happen.

1 Like

I don’t think a freeze is the way to go. But otherwise I agree with everything you’ve said. Developing the next version of CP is what is going to make it really stand out as an independent CMS.

Central to that, in my view, is the abstracting out of core plugins. @MattyRob has already done a lot of work on this.

Of course, backports from WP can still be added (and one reason why I would not be in favor of a freeze) but they should not be the main focus.

I think it’s also worth re-thinking plugins. Too many WP plugins are bloated things. As you say, you have replaced Toolset with a very slimmed down alternative. I myself have written lots of mu-plugins which take a similar approach. I wonder if we should be promoting gists or mu-plugins alongside regular plugins.

There is an idea floating around somewhere to have an area in the ClassicPress admin area that showcases vetted plugins and themes, designed, developed and maintained for ClassicPress.

For small to medium sized plugins, I see now reason not to support older versions - I have 2 plugins that support all the way back to WordPress 4.4. While I understand that dropping support for older version for features that rely heavily on the Block Editor is going to happen such decisions are missing the millions of users that use the Classic Editor which is in reality no different to ClassicPress.

And pushing a security update at the same time as bumping supported version numbers is quite honestly irresponsible and would be reason enough for me to stop using that plugin or anything else coded by that person or team!

But, my feeling overall is ClassicPress needs to move away for WordPress now, back porting etc is find to a point but it’s time we took our own path - the influx of users and developers that was hoped for if we waited patiently has never happened, so those of us that are here need to get the project moving forwards, gain some momentum and make our own product, then ewe might tempt new users and migrators once they see a stable, supported and developing community and platform.

3 Likes

such decisions are missing the millions of users that use the Classic Editor which is in reality no different to ClassicPress.

The thing is, disabling blocks is another thing all together than not having its core functions in the base code like cp does (not)

Like, if you drop support for wp 4.9 it won’t really affect WordPress users who disable the blocks
Because the functions are still there.

The main issue with cp is it doesn’t have the functions and thus it’ll fatal, rather then just not load the particular blockified feature like is the case in any wp install that disables blocks

Again with an example of toolset, it will work perfectly fine without blocks. They even have a special legacy mode just for that.
But they don’t check if the core functions actually exist or not, thus, legacy works as long you have updated wp but disable the blocks

However on cp it fatals unless you shim in the missing things.

That said, I agree completely that it’s a bold move dropping support for something while bumping a version without any prior notice, and also a bold move to just assume everyone is with blocks, considering the millions of active de-blockifier installs …

1 Like

I haven’t read it lately, but I think the roadmap says this already. The initial version of CP was supposed to remain compatible with WP 4.9. Changing the version number to v2 indicates a breaking change, and that hasn’t been done yet. We haven’t designed v2, much less coded it.
Hopefully, this community will be different than WP, in terms of documenting what the software should do and then coding it, instead of throwing some code together to try stuff and iterating.

1 Like

Hopefully, this will have a solution soon.

About different CMS.

Good to hear from you @ozfiddler. The perspective some have outside about CP is that it is an unofficial version of WordPress, which they don’t feel comfortable using.

4ffc328d-e964-49e3-b0e2-43583b1dc2e7

We need to figure out a way for people to see and understand what CP is and what it’s doing.

As others have pointed out, version 1.x is supposed to be a drop-in replacement of WordPress 4.9 with long-term support (LTS). This version needs to be backward compatible and critical things should be backported.

However, version 2.x should and will start moving in its own direction where it can be considered its own CMS. This version will have breaking changes. Version 2.x was supposed to include integration with our Directory, replacing the WordPress repository. This is a major move in its own direction.

Giving the roadmap page some TLC might be a good idea. Helping visitors understand what’s happening with the project.

Also, the homepage copy (especially the Community First section) could be worded differently to bring more focus on the fact that CP is its own CMS and not an unofficial version of WP.

Another thing to keep in mind, we need to be mindful and supportive of WordPress plugins that officially support ClassicPress. It’s not an easy thing to do and they placed their trust in ClassicPress. For example, Shield Security and Beaver Builder. When CP introduces breaking changes, we would want them to continue supporting CP. I love Beaver Builder and would hate to see them not support CP. Will they support CP after breaking changes are introduced? I don’t know, we’ll cross that bridge when we get there.

Lastly, we need to be aware of our own resource limitations. We only have a few core contributors, volunteering their time to help push CP forward. We all want a lot for CP and see it succeed, but we have to gradually introduce things. Look at the current 1.3.0 version, which got stalled for a while. As we get more core contributors, it will get easier to introduce new features and reduce backports from WP. We have to be smart about it with limited resources. Backports help reduce the time needed to code a new feature or fix a bug. We can eventually stop backporting, but until we have a healthy team of core contributors pushing out new releases backports are necessary.

1 Like

To add to this: Personally, esp. with my current time (and monetarial) restraints, its “easier”[1] for me to create a “generic” WP compatiblity plugin, than doing actual work on the “bare metal” system.

But I wouldn’t mind if all of what is collected in this plugin, to be merged with CP 2.0 later on. So you would develop the plugin with that goal in mind, too.

cu, w0lf.

[1] “easier” in quotes, because thats just about the only time I’ve got left for things “outside” regular freelance jobs (and a bit of “spare” time). Ie. If I dont work, I dont get paid, and thanks to Big C, I lost about 50 - 60% of my regular monthly income.

About all the above: @anon66243189 I agree we need to develop a plugins/themes ecosystem to avoid relying on WP’s.
I don’t agree on freezing the development of core, because we at least need to supply security updates and the infrastructure to allow themes and plugins installation from the admin area.
Customers of mines are very reluctant to use CP for now, just because they need custom plugins and themes developed not to rely on WP’s ones, and they think that if they have to use those and know they are going to cause issues, it’s better something different entirely, like Wix.
To make CP credible as a standalone CMS we need both the ecosystem and the continued core development.
One thing I see for myself: I don’t understand WP anymore, what they are doing is making everything more and more complex (full-site editing and block widgets screen where the coup-de-grace for me), but CP is nowhere near to being what WP 4.9 was. I can cope with that because I am an early-adopter kind of person, but it’s very frustrating having to explain to people that CP is evolving and in time it will be even better than WP and given people go where money is, at present CP is not a profitable business, so as many have noted, big dev companies are very reluctant to commit.

3 Likes

I agree… and then I disagree.

I hear it not the first time, that “all CP does is back porting WP code”. And, you say it yourself:

Customers of mines are very reluctant to use CP for now, just because they need custom plugins and themes developed not to rely on WP’s ones, and they think that if they have to use those and know they are going to cause issues, it’s better something different entirely, like Wix.

The thing is users who choose CP they do not expect huge movements in CP now.
That is the whole reason they change.
But they can’t without a solid ecosystem, which is based on Plugins and Themes, and a stable CMS.
The CMS is stable. It is time-vetted like nothing else is.

I prefer using old, discontinued Plugins over actively developed ones because nothing changes.

Of course, security patches are another thing. We can’t halt those. That would be not responsible.

However, I am of course also understanding that CP needs to continue to grow. I am not saying “Stop all work”
What I mean is that perhaps of the very skilled developers who right now might be busy developing a V2 (I am not sure, it is just a guess) - if they get some hands on a plugin each, and perhaps a theme or two, in about a month or two we can deliver those, and then we can go full steam ahead on actual core development.

It is difficult to not make me appear as saying “halt all stuff, go the other direction”. I am one of them in favour of CP finally “growing” into its own path, nothing I’d love more.
But if we don’t get plugs and themes, all development we put into CP will be lost time, I am sure about that, because unfortunately CP alone is not really versatile. You can create a simple blog, and with lots of code, more than that. But users aren’t all coders. Specially “Clients” - even if they never use it - want to believe that they “can” if they want. If you as developer deliver them a hardcoded PHP magic, they aren’t happy. They want things to edit and do in the backend. Thus, plugins, or themes.

Well. In the end it is like a Ouroboros. More Core development means more people trusting it survives and thus more plugin and theme devs coming in.
More plugins and themes available means more users and thus more resources (and reasons) for Core Development.

Thus I “submit” :smiley:
Lets not halt CP development. But lets try to not forget themes and plugins on the path (like many in this thread already stated there are actually ideas and WIPs, thus… I should be happy now :smiley: )

Let’s also start encouraging to develop new (CP targeted) things instead of "just use WP things and ask their devs to make it compatible)
I think if we lead the way, just as a recommendation, it can change the status quo, which as it is currently, will lead in a big problem down the road (or did already, as we can see from above posts, some got hacked just because trusting this “works with” philosophy/culture).

Hope it didn’t come along the wrong way :wink:

First, with continuing to develop core I meant that we need to keep it stable by releasing security updates. You say “stop development” that I understood as “stop it entirely”.
Second, yes now we backports from WP. Because we do not have the manpower to release our own security fixes and it is sensible to at least check if theirs can be used. I’m sure in the future we will have pur own security updates.
Third: version 2 is about plugins and themes directories.
Without version 2 there will be no way to ship plugins and themes in the backend, but I agree with you it is not sensible to deliver the infrastructure without any viable plugin or theme inside, so maybe we can complete the infrastructure part and then, before releasing we can work on plugins and themes to deliver with it. Then make a very big announcement that v. 2 comes with these plugins and the first default theme(s)?
I think devs are more likely to contribute then, if we release both the infrastructure and some plugins/themes. At least the people (users and devs alike) will not feel the infrastructure is empty.
Another thing to consider that users are “afraid of”… Custom coded site means the custom code needs to be maintained to avoid site to be insecure. That means paying for a dev to do that, and not being in control because the user usually is no coder. A site owner wants to do things but most importantly wants control over the site.
As is now, if a customer needs something more than the common bare blog done with CP, the dev has to code plugins and themes (WP themes are not working anymore, the majority of them) and maintain them. Users can’t go and install things themselves (or better, they can try but as soon as these don’t work anymore the site goes broken, and eventually every WP plugin and theme will stop working, it’s a matter of time).
That is why I cringe, my site is a mix of CP plugins and WP ones. We really need the directory and a set of plugins and themes. And that is version 2. The directory is alive and in testing, there is discussion around rules. I think we should also start to decide how to implement it to the admin area. Do we offer install from the admin or users will need to download to PC and upload to CP? Do we offer a hybrid period? Do we offer to integrate other marketplaces or not? When the infrastructure is ready and implemented what plugins do we need to add to be sure we cover the bases? And what kind of themes? Cam we consider including themes the community already developed for CP?
All these things need to be discussed and obviously worked on before releasing V2 IMHO.

Completely agree, and I think we maybe start looking at petitions that we can start planning out v2.

I also think spending some time with CP supported plugins will be hugely beneficial. For example, Theme One, CC, and CP SEO. They all need a little love.

If CP itself can build out those “core required” plugins to help convince people I think it will make life easier. Those plugins would also be updated with V2 since we are managing them ourselves.

1 Like

This is bogus. There are thousands of plugins and themes that do not interface with the new changes in WP, so they continue to work. Some might need updates for PHP version though.

3 Likes

I think in time CP will differentiate enough for that not to work. For example considering the fact we will ship libraries so plugins/themes won’t need to include them. This means having basically two versions of the plugin. One using WP standards and one that uses CP’s and doesn’t ship libraries to avoid conflicts. Also, the more CP develops, the more it can get something different from what WP 4.9 was. Just continuing to tell people that they can use WP ecosystem to win them over won’t work in the long run, they will be frustrated when they’ll see their theme doesn’t render images alignment or custom CSS as did mine, or that a famous plugin causes errors. And they will leave for something else entirely not wanting to wait for us to develop a stable and working ecosystem of our own. That is why we should ship the infrastructure and a set of vetted plugins and at least a theme for V2 IMHO. To show people we are getting there. And retain their trust in what CP can be in the future.

Plugins and themes already fail now if they simply use one tiny function not in cp (and that’s not just blocks stuff, there’s a whole more).

Read this thread here to see at least one person even experienced security issues due to plugins dropping support for older wp versions.

Definitely it’s not bogus seeing the future coming which is already here:
Plugins, and themes will not work smooth anymore with WordPress 4.9 very soon and most big ones of them already don’t anymore, this is just a fact.

Toolset, elementor, yoast, astra, kadence, those are names come to mind of big, actively developed plugins and themes and they all won’t work with cp.
Metabox is officially compatible but stated “as long it works”. Big lol on that. If someone’s going to develop a process website or use cp in a professional environment then they won’t be able to use any of that stuff, because not working means not working and “as long it works” is like almost the same.

There are literally thousands of people who’d love nothing more than old traditional editor as cp has it and do also use it thru the disable gb plugin but also want those themes or plug-ins.

As said prior, wp 4.9 has nothing to do with Gutenberg deactivated on updated wp install. Those installs keep working with all and every most modern theme or plug because the code is there, just the scripts aren’t loaded and legacy editor is instantiated.

I’m member in several big communities and those are the major softwares these people use, even if disabling gb.

This problem has nothing to do with cp evolving.
It has everything to do with those plugins and themes also not sleeping and evolving with WordPress.

If you’re asking a plugin or theme dev to keep compatible it means to keep compatible with a 3+ years old code. And as said no major plugin even thinks about doing that.
It’s not “not happening in the future”. It’s “already” happening.

Relying on a plugin or theme not updating and thus not breaking on cp, or not evolving ever and thus not breaking on cp is plain simple unpredictable and is not what I’d want to tell or recommend a person who pays me for doing some work for them.

3 Likes

… it really doesn’t have to be though :slight_smile:

Query Monitor – WordPress plugin | WordPress.org is a good example: it is working with all WP versions since 3.7 (released in 2013!)

It has some features related to blocks. They are optional, and only enabled if the plugin detects a running block editor. The code is cleanly separated between “classic” WP-backend-stuff and “new” block-editor-related stuff.

I expect this plugin will continue working with CP for a long, long time.

Of course, most plugin authors won’t or can’t write their plugins this way. Which brings me to agree with this:

The main drawback is that migration from WP sites becomes harder and harder over time. I cannot think of a way to avoid this.

4 Likes

I think we need the CP versions of the newer features that have been added to WP, like Recovery mode, error handling for image uploads, some of the REST API stuff, maybe Site Health, admin email verification, custom fields on menu items, jQuery update, lazy load images, App passwords?, https migration, Robots API, plugin Update URI header.
But these things would be in v2+, is that right?