Agreed. The plugin I’m developing, however, is intended for CP. It would certainly work with WP as well, but I decided not to care too much about compatibility with it.
1 Like
You wouldn’t have to remove those features. Remember that people can migrate from WP to CP, so that means they can have block in their content. Just as a WP theme needs to still handle classic content in addition to block markup, a CP theme can have styles that affect block classes. If the theme has settings specific to blocks, however, you might want to make those conditional on the $wp_version variable.
Don’t forget the ‘extra’ code CP users load and never use in a shared plugin/theme.
Ideally it’d be 2 plugins or themes if you’re including newer functions for WP.
I’m torn on that too for AdRotate (Pro), use newer functions in WP and replace them with CP compatible stuff.
But I hate the idea of people having to load a bunch of code they’ll never use.
But, if compatibility in CP would be extended and that extra stuff is limited to blocks or small things… Then that’d be much less of an issue 
1 Like
Fortunately you don’t need to have users “load code they never use” (not that it would matter, actually, modern servers and PHP could probably load an entire App that is never used without even affecting any load time). You can use Best practice to detect a ClassicPress Install | ClassicPress Documentation to check if it is a CP install for example, and load your “CP only” code or not load “WP only” code depending on that.
However my plugins for example run on both WP and CP, and I never came across the need to separate the code bases. As long your plugin is compatible with WP 4.9, there’s no need to do this acrobatic exercise.
Of course, if your plugin is not compatible with that version of WP, it would probably just be better to not ship that plugin to CP/make another plugin that actually works with CP/WP 4.9
It is certainly not within our goals to start including either shims for blocks, or actual blocks related code.
Not only because the very core of CP is “no blocks”, but because it is useless to start with. Blocks will not work on CP no matter what.
As for the other new features/functions that WP has and CP does not, I rather would prefer we actually spend time maintaining security (which has been and still is honestly lacking, even if the parts that should receive updates are hard to exploit, or close to impossible, they are there/have been there way too long), and adding new features unique to CP or improving existing features, something that will actually distinguish CP from WP rather than making it a zombie-frankenstein-doppelganger of WP.
I would also like to reply to
Search for ClassicPress stuff and you won’t find much if anything at all.
We have a 100% covered documentation for CP at https://docs.classicpress.net/
The reason you can’t find results in google when searching, is mostly that this is mostly duplicate content and google of course will prioritise the original + the one that 50K users click on it, versus 1.
Another reason to actually start distinguishing CP from WP by adding new, unique features and not copy even more. That just gives us the image of the “copy pasta wannabes”.
There are unfortunately not many people talking about CP in their blogs or else, and that is the other reason you can’t find lots of contents or how to’s in the net. That, is entirely up to the community and its users (which as in any community, have a lack of contribution willingness and are not involving personally. This is just normal, and the only reason WP is so widely covered is that it grew to be a giant powering over 50% of the web probably. This happened because while WP Grew, it was basically the only viable solution, and probably still is, for noobs to devs. This may, or may not change in CP overtime. Not if we keep being the copy pasta folks, however, that much is sure.)
1 Like
I completely agree. I’ve been thinking about it: currently it doesn’t make sense to divide plugins and themes based on installation type. CP and WP are still overlapping, so it’s better to do a preliminary check of the type of installation on which you are installing the plugin (or theme). So far, however, my themes and plugins work for both. Implementing blocks (via add_settings, mainly) don’t stand in the way.
Just today I was reading that WP is implementing block themes (argh!) and has already made a distinction with “classic” themes. Now, this will probably imply (I haven’t read anything about it), a progressive abandonment of the traditional way of developing themes, and therefore the distance between WP and CP will become even more evident and irreversible.
It is clear, therefore, that CP will need new blood. I see it, unfortunately, in the scarcity of news about it (few bloggers actually talk about it), in the slowness of blog updates and script updates, due to the scarcity of developers available to collaborate. I, personally, would like to help in my spare time, but unfortunately I don’t know the dynamics and functionality of CP core to take on the task: I’ve always built themes and plugins (few in truth), and not even very complex, so my usefulness would be very minimal. For example: I made available on Github a plugin to create tables (to be used in the development of my plugins that required them) because I didn’t like the system created by WP and I found it complicated.
But it is certain that CP would deserve much more. It’s a project that has an ambition that I fully support: to keep simple what was born to be simple. Of WP it will be necessary to continue to take what is good (it would be stupid not to), discarding what is not, but it is clear that sooner or later CP will have to start walking on its own legs and acquire its own identity, otherwise it will die.
I’m going to write something in my blog about CP (I haven’t actually done that yet), hoping it will be read enough. The effort has to go in this direction: talk about CP and try to get people talking about CP. But it’s clear that whoever is “in charge” of the project, maybe should look for more visibility, even on social media. On Twitter, the last post is from 2021…
2 Likes
Facebook is continuously updated by me at least with releases. I don’t have access to other social media of CP, but I’d maintain at least the update notification, it does not cost much. About blogging, I used to write some blog posts about CP on my own site and also on CP itself and interestingly those are the only posts I even ever received comments to (on my site), so it is actually worth it. However that takes time.
I think us less experienced devs and users can help where we can. For example I provided a couple new features that made it to CP core. It was no big “whoa” feature, and anyone with little PHP knowledge can do such things. We need help in DOC writing, etc all shown here Currently Active Projects
Now also I’m setting up a testing project (see Release testing system | Help needed - #8 by smileBeda) which is basically something anyone can help with - it needs basically no knowledge (actually the less experienced the better because it helps catching UX issues)
I think (no, I know) the main issue is like in any society or group: we do a lot of talking and not much action. This is unfortunately just normal. I believe Pareto principle - Wikipedia pretty much applies here as well.
So for example assuming we really have 5k users (we do not, but that is the number of sites that supposedly use CP), we would have roughly 1k “vital fews”
We do not have 1k vital fews, we have some perhaps 3 vital fews. That makes it 15 users. And that pretty much correlates to the amount of voters on polls, commenters on posts, and voices on releases. We rarely have more than 10 distinct voices.
So there you go. Does someone really want to develop a paid product for 15 active users? Nope. Not even a fool would do that.
Does someone want to contribute where they can because they want to, or because they require the project alive, or because they are fools? Yep. Perhaps, we should update our tagline again 
(note, this is not intended to offend anyone or complain - it’s just facts, and perhaps there’s a better word for describing “those who contribute to a project that has basically no safe future nor reward” than fools, but I couldn’t find any. “Courageous Pioneers” maybe )
I think the only way to “fix” ClassicPress and keep it relevant, is to move away from WordPress which would introduce breaking changes and make ClassicPress its own CMS.
This is the conversation for that:
4 Likes
Totally agree with that. WP 4.9.x was a good starting point, now take it from there. I also think linking to the WP plugins and themes from within the CP panel should be abandoned. It would be best to offer users of CP a similar experience with a CP repository to make it as userfriendly as possible. Most people don’t even know github exists let alone be “how this stuff works”. The KISS principle should be applied as far as I’m concerned.
5 Likes
I haven’t yet given up on my tutorial blog that is dedicated to CP. It’s in development, but it’s only a part of the writing business I’m building, and so the progress on it is slow, as I have so many other concerns.
BELIEVER.
You believe in the project and the things it stands for (stability, reliability, democracy, etc.), and that’s all that really matters.
3 Likes
What are the current thoughts on this problem?
That is a very cool idea. I think, we could focus on that together. I have already backported some functionality to make CF8 (CF7 fork) work. Example here.
Some changes should be backported directly to core though. Question is, how we should decide which changes and adds go where.
I am happy to help whereever I can.
If CP keeps backporting everything from WP just to make stuff work, CP will be nothing else but a delayed version of WP.
Why is this so bad, and what else can be done other than keep being a WP copy?:
You have been making many valid points, but you also continue to perpetuate flawed reasoning. CP doesn’t have to add new stuff. The fact that it doesn’t use blocks already makes it much lighter, faster, and more stable than WP.
So please stop portraying the issue as if a fork is the only possible option. It isn’t. What’s important is that the ecosystem of plugins that work on CP is sufficient for the uses to which CP users want to put it. That doesn’t require a fork at all.
Do I consider a more modular CP as strongly desirable, with the development of core plugins? Absolutely. But it’s not either/or.
4 Likes
WordPress plugins will be diverging from the current codebase more and more and more.
I still haven’t seen any other solution for this issue, other than forking plugins for ClassicPress.
I agree I am “pushing” my view in other aspects, but also started the experimental version just to play and I am not interfering on that side anymore.
But about plugins, again and again, it is the only solution. Other solutions are: tweak the core to keep adding fuss from WordPress and even that won’t fix the whole thing with plugins… and what else?
I am waiting for more alternatives since a few months, no valid alternatives have been proposed, other than the utopic “something has to be done to make plugins work”.
Forking plugins is different from forking CP.
1 Like
Sure it is. And if you click the link you will realize it is what I intended to say from the beginning. What kind of person would I be if I came to a community preaching to fork it?. This community is beautiful, apart from many of my ideas being different. I want it to succeed. Maybe it has been a misunderstanding
Still waiting for reasonable and valid alternatives to this proposal.
The work on the plugin directory has resumed. This means that many plugin developed for CP are going to be published in the coming weeks. And devs will make available what plugins the community needs by listening to people’s requests.
As soon as the plugin dir is done, I think we all should have a talk about themes dir.
And then we need to start inviting all the theme devs who published their themes on the forums to publish them in the theme dir also.
Is this a reasonable answer to your concerns?
1 Like
Not really. I’m starting to think that many people here don’t even read what’s being said before answering.
It doesn’t mean that. It means that a member of the plugin review team reviewed two plugins that were hanging since some time and that they commited to review more. But stating that “many” are going to be published is misleading.
And for the rest, you more or less repeated the same thing that I am trying to say, which is:
- Have a CP specific set of plugins (which implies that some WordPress plugins will inevitably have to be forked)
But you missed the fundamental point that I made, which is:
- IF we are going to go this route (the route of a CP independent plugin directory), we can as well come up with a list of minimal breaking changes so that we don’t have to fill up the NEW directory with blocking code that will force CP to stick in the old times.
And for that point, I’m really intending to say very very very simple things, nothing crazy. Things like:
- Remove the deprecated argument from the load_plugin_textdomain() function. When you clean your fridge do you take out the accumulated ice and dirt or do you just take food out and put it back in?
- Maybe NOT assume that jQuery will be loaded, force the plugin to make that available if it needs it. If we just assume that jQuery will be loaded, instead of making the dev take care of that (two lines of code), then we will never be able to remove jQuery from CP frontend because: “oohh we can’t because some plugins rely on it”. And that’s very sad.
- And some other MINOR things that will help CP to be a bit better. And again: will not make any substantial extra effort for the developer, as far as making the developer hate creating for CP.
The whole thing that I described here and that not many really seem to care about. And which is a very logical approach. I’m not saying anything crazy, just: “gonna have a new plugin directory? okay let’s first set some MINIMAL requirements and ideas so that the new plugin directory doesn’t block the future potential of CP”.