The problem with relying on WP Software while running CP

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?

If all of these features are backported from WP, then major version would not change since no breaking changes were introduced. Or we decided to include these changes in 2.0 along with a breaking change that necessitates major version increase.

1 Like

Not everything that @joyously mentioned would be a non-breaking change, even if backported. Moving to jQuery 3, for example, could break themes or plugins.

I think we can conclude that we need more Plugins and Themes in CP, apart of also pushing forward CP, and that it is allover a dangerous, and on the long term unreliable approach to rely on WP Theme or plugins just “keeping to work with 4.9”

The problem intended to be discussed here, touching the possibly catastrophical effects it can have on a website when using a mix of things and especially the main-stream recommendation being to drive users towards such approach, I think received enough consensus.

As well I think we all seem to agree that relying too much on another ecosystem from which we did distance ourselves (WP), is not only a potential danger for users, but an issue for the project itself.

Thus I think we can resolve this issue here by:

  1. Update our instances where we say “contact other devs and ask them to ensure compatibility” to mention that the best approach would be to choose if available, or even develop, a CP solution.
    For example, there is this DOC entry: Whatever the case may be, we recommend contacting the plugin developers and asking them to make their plugin compatible with WordPress 4.9.x (and therefore ClassicPress).
    I think the whole section there needs an update reminding users that yes, Software labelled with 4.9 will work, but - recommended - would be to use these (list here) plugins or themes as substitutes for XY.
    We already have some replacements, like CC and CSEO.
    Even just mentioning this there, can contribute to the change.
    Please if anyone knows of other instances where we recommend to simply contact dev’s and ask them to make things compatible (again) share here so we can enhance those.

  2. Much more important, since words are nice but do not change a thing, everyone interested in this project with the capacity and knowledge to do so, should be if possible focusing towards working on CP, or Themes and Plugins for CP. For starters, it is clear that Themes are 100% missing. I know there is one person working on a new starter theme based on Susty, and I myself am creating a widgetized theme for those people who want a more backend-ish experience but still could get their hands dirty on some code. So that would make 2 Themes being ready in the coming up weeks.
    So for the theme dev’s amongst us, now would be a good time to think about creating some amazing new theme, working solely for CP (nice if it works also with WP but it shouldn’t be the gaol).
    If anything is stopping you from developing such theme - even if a simple one - we should immediately try to resolve the blocking issue. I think however there is nothing blocking us, other than motivation.
    Related to Plugins, we have some 90 plugins already, but none of the major “wow” features that WP users have in the major PRO Plugins
    Thus, I made a ShortCodes plugin now that allows you to display almost anything on a CP site GitHub - TukuToi/tukutoi-shortcodes: Indispensable ShortCodes for ClassicPress (and WordPress without Blocks) Websites..
    For those amongst you who know Toolset or even Visual Composer from back in the days, this is very similar. You can display a bunch of information using ShortCodes that you usually can only display with PHP. You can nest, and use ShortCodes as attributes inside themselves, allowing you to build pretty powerful templates and dynamic content. I assume you do know that most “templating” plugins who switched to blocks, under the hood do nothing else but parse old shortcodes. Thus, one could say, shortcodes are Blocks without the user interface to choose fancy borders :slight_smile: with more control over the surrounding HTML.
    Following in this same project, a Forms and a Search/Filter Plugin. Again here I am heavily inspired by Toolset, because it just wins everything out there.
    Help is greatly appreciated on this rather massive project.
    These plugins will be always free, open source, but powerful like PRO paid stuff.
    Project on Github is here. https://github.com/users/TukuToi/projects/1
    As said - the Shortcodes plugin is mostly done, it needs a thorough QC, and probably then will need to go back into a dev cycle to fix the things found. Forms and Search & Filter was done a while ago but likely needs a total rewamp, on which I am now, because not really user-ready nor full functional.

  3. I also think each and everyone of us developers/freelancers needs to take a more responsible approach and NOT deliver a CP site with WP stuff running on it where we are not sure if it will continue to work. Let’s assume the worst, like when sanitising and escaping, and not the best. I think the general consensus should be “You may, but if possible should not use WP Software. Be sure the Developer did not just forget to bump the version, and is actively and planned maintaining the older versions”.

  4. I think this is the most important point. It is fine to not have time or motivation to create something for CP or with CP. However lets not take down the ones who want to create, and are full steam believing in this project, with unfounded assumptions 'bout some dark future where ClassicPress has no chance because “not ready”. Instead, if we do not believe in the project, lets stick with other CMS and leave the ones who do believe in it, do their thing. Negativity has never helped someone. However they say that by believe you may move mountains. And I for one, believe very much in CP being the next big CMS of the years to come, unless we screw it up in a endless discussion related to how crippled CP is, or how many things should be done (but then no one takes a finger up to do). Lets bring that trust out in us that convinces those “clients” to trust CP, and let’s try to do what we ask to be done ourselves, or at least help with it.

4 Likes

You really have a problem here, because CP 1.x has the WP repo built in, with nothing for the CP directory. We are still in the transition phase to CP v2, but supposedly 1.x will remain as WP 4.9 was and still supported. So how do you split the few contributors you have to handle both? And what kind of mixed messages are you sending if you say CP 1.x is supported, but don’t use all of its features (WP plugins)?