Really this is what makes CP, CP. We should only be concerned about keeping up with PHP [8+] and nothing else besides security forks. If something comes along, like HTML5 and web3 require (JSON for example (just a whim example… could be anything; webp maybe)) then we would be obligated to follow through on some-type of support for the new browser thingy.
But as it stands, nothing says ClassicPress like keeping it as is and focus on OS, FOSS and the scripting language compatibility (PHP). Other than that I think all other points in this thread would be moot.
So do we “fork and filter” 6.0/… apparently someone has taken their valuable time to do so, already. But it is still a tough decision.
You say that @Simone is incorrect, yet you go on to list several examples of why he is absolutely right!
Webp integration is a classic example of foisting something on users, many of whom are going to be caused lots of problems and incur increased costs as a result. For those who do want it, it’s easy to implement with a plugin or small amount of code.
The implementation of lazy loading in WP core has been a joke from the very beginning. They have recently realized what a major folly it has all been and have mitigated that particular disaster, but it doesn’t belong in core in the first place. Where useful, it’s easily implemented in a theme.
I have yet to hear any point to having WP (or CP) work with SQLite other than “it’s cool”. The touted performance improvements are marginal at best and really only for tiny sites. So it’s a change that looks more like another attempt to enable WP to compete with Wix or Squarespace rather than anything that significantly enhances the platform.
So, if we were to refork, those changes would actually have to be taken out.
As for the performance improvements, most of those have been related to GB and, where they are not, CP development has already shown that we can cherry pick them irrespective of whether we refork or not.
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.
Google has its own agenda.