The project was always short-staffed, to me the issue at the time was that there was a lot of people talking and very few conscious developers and this was moving the project in a direction that I didn’t like it.
This was one of the reasons why I left the project
This fork was just something against Gutenberg and not new things, I can assure that they are not jokes from WebP to new performance stuff and I can say because I am someone that works with the WP codebase (not just installing themes), study performance improvements on high traffic websites and so on.
Also, they are not just improvements that affect Gutenberg as WordPress is a CMS and a framework, so any improvements affect other things in areas that you have no idea if you don’t check any single changeset.
So again we need to discuss if this project is just WordPress without gutenberg or not.
After this, we can discuss those things but if this project doesn’t care about the new performance stuff (that are developed mainly by Google contributors to the WP and this community don’t understand that there is a reason behind it) this cannot compete with the web that is evolving and moving forward.
Group A: Wants to stick to the very roots, a CP version that is a “frozen” version of WP 4.9 with security support and some improvements, but which does not keep up to pair with WordPress.
Group B: Wants to avoid Gutenberg but still keep up with the modern version of WordPress.
I suggest, going on with:
CP v1: for group A.
CP v2: for group B.
Then, we can work together for new features that may be common to both versions (like a standalone Plugin Directory).
Voices will arise, stating that there isn’t enough workforce to keep up with two versions.
Well. I am not helping with v1 anyway because I don’t see the point in working on an outdated version of something that has already been improved by many great developers at WordPress (as stated by @Mte90, there have in fact been A LOT of improvements). But I can take care of v2, since I already am the author of the mentioned fork, I can help with keeping WP-CMS up with WordPress and then using that as a base for CP v2.
One thing to consider about re-fork and maintaining a codebase that’s close to WP for backporting, instead of removing parts and making backporting more difficult we could instead switch features off by default and allow users to enable them. Which is what a lot of stuff in WP should have been like.
I hate everything there is about WEBP being forced down users’ throats in the name of performance. I don’t hate WEBP itself (we use it with clients), but the feature being on by default is a NO. So instead of removing it, we simply disable it by default and let users decide if they want it on or not. This would take less code, so backporting would still be relatively simple.
Not everything is about webp (which btw is nothing more than an evolved format for images… don’t understand the hate). Also, I use WordPress with jpg images that I optimize before uploading. Don’t know why you mean they are forced. Anyway… WP 6+ is way beyond WP 4.9 in many more senses, as previously stated. Look at the commits history, there are a lot of performance optimizations done in Core.
And then we have cool improvements like being able to pass $args directly to get_template_part() | Function | WordPress Developer Resources - but yeah that wasn’t included into CP because… I don’t know why. But yeah. It makes it a pain in the backdoor to maintain themes that are supposed to work on WordPress AND on ClassicPress, but they don’t work on CP because CP is an old WP.
Easier said than done. WP architecture is messed up, it’s not about disabling/enabling easily. Yes, some things can be converted into Core Plugins. But that requires full power devs working on it for at least a couple hundred hours. Id est, won’t be done anytime soon (ever?).
Can we somehow focus the discussion into the very important question proposed by @Mte90?
If this is about creating a new CMS that is completely detached from WordPress but is still an old version of WordPress, then I personally won’t waste more energy on this. Working with WordPress makes sense because of its ecosystem, but working with a pseudo-WordPress is just… crazy.
As I said, I’m not against the format. It’s the WEBP implementation by Google-sponsored contributors in WordPress that I hate and everyone else hates. When they announced the feature on Make blog, comments on that blog were not in favor of this feature. They had to postpone adding it to core because of this. Generating WEBP images automatically in addition to all the image sizes WP generates would increase the hosting bill and eat up disk space. If you haven’t followed that feature, read the comments on this Make blog.
Any business site will prefer a faster site with better pagespeed score. Webp is just better.
You can disable it with a filter if hosting cost is a problem. In any case, a normal shared hosting for $3 a month won’t cause problems for hosting some more bytes in the form of webp image. You’d need hundreds of thousands of images for this to be a concern.
Anyways, that’s just one example. The whole point is:
If the answer to that question is: no, we don’t care about WordPress, we just want to stay frozen in 2019, that’s fine. But it has to be clear once for all, so people know what ClassicPress is about
Currently, CP is chasing PHP compat… which was already solved months ago on WordPress. But not much more than that. Yes, a plugin directory that doesn’t have woocommerce, ACF, … everything that businesses want and pay money for having.
And before saying that “eventually” the ecosystem will grow… is just fantasy. What are the real CP growth numbers? People don’t want an old WordPress, most people want WordPress without blocks.
If that’s true then shouldn’t the focus be on a plugin that removes or thoroughly disables Gutenberg and adds a better editor?
Also, in that same idea, a bunch of stuff that thoroughly cleans up WooCommerce to remove the analytics bullshit and adds the simpler stats and redo the menu so that we can remove the terrible marketing menu?
Probably yes, and it’s why I switched many websites back to WordPress.
Other than that, not having that code in core also makes it more lightweight.
Some other irrelevant things can be removed too, not saying that everything has to be the same.
Add the post ID as a column… okay cool.
Allow customizing the login screen… okay cool.
Remove gravatar and replace it with normal self hosted avatars… okay cool.
But come on, leaving normal core improvements behind just to “be different”, is … a strange thing to do. Keeping up with the good improvements in WordPress Core is just smart and makes the transition from WordPress to ClassicPress easier. That’s what I had in mind when I started the WP CMS project… but yeah, as you say, just using WordPress and disable a bunch of things with filters isn’t a bad option either, if no one really cares.
It appears many circles of this discussion focus on aspects that involve the “mission” of CP. As I understood, ClassicPress is a CMS framework of WP that contains nothing new for WP 5.0 and older, versions.
So would not the obvious answer to this topic be Path 2: Continue As-Is ?
Just do security updates and continue with using the petitions method to gain any new elements which seem in line with CP mission. Why try to re-invent something that already exists. We are merely keeping WP PG (Pre Gutenberg) in the loop of CMS available frameworks in the guise of keeping the CMS lightweight and less code/confusing/JSON/dependency concentric.
If all that people want is WordPress without Gutenberg, there’s absolutely no need for ClassicPress at all since there’s already a plugin that provides what you’re looking for. It’s called Classic Editor +: Classic Editor + – WordPress plugin | WordPress.org
The idea that the question is whether CP should essentially mirror a stripped-down version of WP or not is therefore entirely misconceived. Those who desire that objective should be using that plugin. It’s really that simple.
CP (and the work that goes into it) only makes sense if it’s its own CMS with its own decision-making process and its own features.
So the question is actually what’s the best way forward to make CP successful in that endeavor.
But that’s what it says on the front page of classicpress.net - in the Less Bloat bit.
So are you then saying CP is misconceived?
I don’t think there is anything wrong with having CP as a sort of LITE version of WP.
I also don’t think its wrong to be 3 (or 30) steps behind WP in terms of features/development/whatever (in the vein of having a LTS version).
And lastly I don’t think it’s wrong to NOT have feature parity as WP 4.9 did everything what most people would want from a CMS already (I think).
So then, and that’s also why I voted “continue as-is”, continuing with 4.9 and updating it for modern stuff is probably the way to go.
But problems seem to start when people question or wonder about the mission, (vision?) and perhaps even leadership of ClassicPress as a whole.
Figuring that out, as @Mte90 also wants, is an important step in determining the direction of CP.
And as for the WebP discussion that keeps popping up as an example here. That has no place in this particular topic.
WebP as a format is fine, Google inventing and pushing it is less fine. The end.
Just add it when it makes sense. Right now I have a hard time on macOS to even find apps that can use it (converters for example). Perhaps it’s too early to add it as a mainstream thing.
WordPress itself didn’t continue to try to be backwards compatible with b2 for very long and honestly I think the fact that ClassicPress is continuing to try to maintain some compatibility with WordPress here is holding the project back.
It’s time to start a new path. One that’s unique to CP.
I don’t have a problem with backporting features from WordPress when possible but a 2.0 version of CP that’s based on WP6? Oy vey. Not good.
Several people have expressed similar, implying that it’s better to be compatible with WP, as if that is the only reason to backport from WP.
Let me just be clear that the beginning of CP had several developers with WP core experience. James was the last of those, and with him gone, the CP team won’t win any resume contests. The whole point of backporting from WP is because they have thousands of developers, millions of users testing every combination of version and plugin and host to find problems (plus a testing team), a security team, and a performance team. CP has none of that and it’s kind of silly to not take advantage of their efforts. But the more things we ignore or fall behind on, the harder it is to backport anything.
There are many things that continue to evolve, outside of WP, like PHP, Javascript, CSS, HTML, and various bundled tools (like jQuery and TinyMCE and PHPMailer and Simple Pie and Requests…).
CP can’t stand still at 4.9. That’s dead. But if you tried to backport all the PHP8 stuff, you’d find it very difficult because of all the formatting changes they made, plus all the bug fixes, plus all the new features.
The new fork bypasses the backport problem by taking it all at once and deleting the block stuff that is unwanted.
I personally think that CP doesn’t have any features of value that WP doesn’t have. It has a bunch of fixes and a few features from WP, but it’s a dead end, especially with the limited roster of people who contribute code.
Who would want to use plugins and themes made for WP5+? WP5- is what we chose ClassicPress for. Just take it from there, I would say. As an end user non-developer I can’t oversee all consequences, though. Working on plugins and themes compatible with CP as it is should have priority, if you’d ask me. Just keep up with technological standards in the background. How a site looks and works in the front end doesn’t solely depend on CP, but also on the theme and design and coding skills.
Secondly: would it be helpful to start a crowdfunding in order to attract, say, three good developers who could help the core developers team on a project basis? From what I read the most vulnerable part in CP is the small number of core developers. And they happen to be our golden egg. A crowdfunding could also help spreading the news about CP.
Very well said. And that’s exactly what I meant when I started WP CMS. I wanted something that has the mission that ClassicPress has but without being so old and so crazily behind WordPress.
CP can be a CMS on its own, of course. And being an exact shadow of WordPress just without Gutenberg is also somehow stupid, I agree. But you cannot ignore everything that was stated above, and just throw away all that “free work” that can be used to help CP stay updated.
Instead of wasting time in fixing things like:
“CP code is using http://api.wordpress.org/themes/info/1.0/ and that endpoint doesn’t return the necessary data, upstream is using 1.2 now but we can’t just swap over as the return is now a JSON object rather than serialised PHP.” (Slack #core)
That time could be used to work on Core Plugins and other interesting features, that indeed make CP different.