I’ve been using ClassicPress and Classic Commerce on PHP8.0.13 on a test site (localhost) for many months now. No issues that I can see.
The only reason I haven’t updated my VPS is because I can’t be bothered to provision a new version for apache as that has some bigger impacts - Nextcloud, several sites etc.
Anyway - as for going whichever way - I voted “continue as is” but don’t really care either way as long as CP stays snappy, responsive, lightweight, and has no block editor. As I mentioned in another thread a few months ago - CP is pretty much perfect as it is right now. Just gotta keep up with modern PHP and such.
For (or against) considering the refork - I don’t see much useful features in WP5+ that CP would need - As in, I switched from WP5.7 or something to CP and never had any regret or missed any button or function. So what did WP5+ really add other than an updated codebase? Nothing important I’d say.
My view/advise:
Make it “easy” on yourself and focus on your own thing with CP.
Develop a way to to stay compatible with plugins that require WP5.0 by adding essential functions that those plugins commonly miss.
This doesn’t even have to be a core ClassicPress thing but could be a ‘WordPress compatibility plugin’.
Adding alias functions (for if WP renamed something) or add full functions (‘essential’ things added in WP5 that plugins need).
That way you can focus on modernizing CP where it matters and not worry about WP too much but keep benefiting from their huge plugin availability for a while without too much issues. If you wait till WP8 rolls around they’ve probably strayed too far for that to still make sense and CP will fail at that point if it can’t stand on its own.
That gives you some extra/free time to put more work in promoting ClassicPress as an alternative to WP while there still is some compatibility. Be more active on socials and attract attention where you can to encourage developers to switch to/join ClassicPress.
I guess I care a bit more about not re-forking than I thought, oh well.
I can chime in here, at least a bit: I’m not “willing to contribute” to ClassicCommerce as its incompatible with the most important plugins for the European market (for Germany thats eg. German Market and Germanized for WooCommerce). Thats solely thanks to the refactor of the Taxation classes after 3.6.x, which is why 3.9.x is still working, where others are not (current plugins have some changes, but can be adapted easily, whilest the changes for ClassicCommerce are too massive - I tried and failed).
What would probably make for an interesting path changer / key element / “hookup line” is making the PayPal payment gateway work with the current PayPal API, so that “the shop system” choice is pulling potential interest.
Thats what I’m trying to do with my own fork, but I’m currently still just in the planning / drafting / sketching stages, as I’m only a single person working on it, and things like being to pay the rent or buy food / ressources comes first (as much as I’d love to clone myself, so there is 2 x 24h per day available).
so “willingness” has NOTHING to do with this. It might be different for others, who are less idealistic and passionate, and eg. do not work freelance in Germany (ie. get punished for being your own boss, just by existing).
Everything doesn’t have to be free. This easily can be a paid plugin (including Stripe and other payment gateways) And no reason to limit it to Classic Commerce, it should work with WooCommerce so your target market is bigger and you can make more.
My personal guess would be: If its easier to achieve near-level feature status (eg. REST-API, theme framework changes, PHP 8.1, etc.) by reforking without gutenberg and “up-port” changes already done to CP 1.x - do it.
To me, CP is not WP without Gutenberg, but also its not “a completely different CMS”. Although I indeed think, too, that WP 8 is not gonna resemble anything remotely “WordPress” anymore, but just a FB vs Squarespit Crossover Framewrong Mutation.
False, I follow the development of WordPress weekly. I can assure that from 5.0 there were a lot of improvements on Performance in various places, not just the webp support but from the DB query side to improve the amount of query and improve the cache internals for cache plugins.
Soon there will also be the SQLite support as example https://github.com/WordPress/performance/pull/547 that are 5450~ lines of new code.
There is the image lazy loading native support that is important as it is automatically.
So just for the performance improvements, there are a lot of things and with a bit of digging there could be just more reasons about it.
Talking about bugfixing there were a lot in various part of the code and improvements to the rest API that were necessary to improve Gutenberg. Yes they implemented more new things there just because they needed.
So if you check the changes from 5.0 to 6.1 not in the public changelog in the blog but the changes in the “fields guide”:
Another reason why I don’t use CP for my customer (or support it officially in my plugin /free or premium) is that it is not aligned with the last changes or improvements required from a lot of plugins.
We can’t make decisions in a complete vacuum, that’s how Gutenberg ended up in WordPress
Salient statement by @viktor and a grand point to keep in mind. The MOST important aspect of WP/CP is PHP. So having compatibility for 8++ is by far the biggest ‘pro’ to focus on. Although in my opinion I do not think we should “simply” fork WP6.0 as it may be more work to separate updated branches from the GB elements than it would be to create a compatibility mapping of PHP for version 5 and below.
I have a feeling I am wrong about this, since keeping up w/ PHP is a never ending zen-master event and having the staff to do this is an issue. So piggy-backing on WP 6+ may be the ONLY option if we want to keep CP secure and forward looking.
I would hate to suggest “both” but guess I just did. LOL. ClassicPress < 6 and CompatiblePress 6 &>
Wrong, a lot of plugins now use REST also for their backend/settings as example Redirection or Yoast (or the system check).
Also, the REST are often used to integrate WordPress with external services like for Woocommerce or others. They are used also in some themes or plugin for frontend stuff instead to use AJAX for various reasons.
Another example is that I did for my customers custom rest endpoints to integrate in their tools or for custom JS interface in their website, so they cannot be ignored as now are part of a lot of things.
In my personal opinion, if we were to re-fork CP based on v6.0 that would be the only re-fork. We catch up with WP, and then focus on backports and new features. Right now we’ve spent a lot of time trying to get PHP 8.0 support done, but we could be focusing on backporting more useful features.
On that topic I think that we should find something that let the project says “we need to refork wp 6.2, execute the command” and it is done. The procedure for that should be so much automatically possible (with minimum changes to the original code) in a way to not have these discussions again.
Otherwise keep up with WP will be very difficult…
I agree with automation, but the problem is many CP users want more flavor than WP provides. Our own directory with plugins and themes is one example. Something like the relationship Ubuntu has with Debian, though I don’t know the technical aspects of how they manage it.
There is a lot of nonsense that’s being pushed into WP that CP community doesn’t want besides block editor. For example, WEBP being forced down users’ throats.
So I think that we can think on that stuff with a set of patches that remove what the project doesn’t want.
So probably is required a list of what CP don’t use and don’t want from WP and in a way evaluate for the automation how to do.
Are we talking about GitHub Actions and lots of shell/bash scripts? Or something else. Just curious about what that approach might look like. The main barrier to that would be getting help implementing it. We’re a bit short-staffed
In my life I often have used to make choices at first intuitively (“1”), and then I try to find out what says my reason (not very sharp in the evening time:).
When I try to think, at first my thought goes to plugins: I use them in big numbers (in total 60+; active site; copy site; and I also have a rough copy site with WP 6.x.). I think, I have used quite a lot of time to get the plugins I need to work – as normal user, not knowing much about code. And I have seen how more and more WP plugins need to be downgraded, if I want them to use with CP. I really do not care too much about security – for example I use an outdated version of a good WP security plugin.
A human has limited memory capability and so I like to continue with familiar plugins – especially if they have complex backend pages. So I use also the Yoast – again a good yet outdated version.
But from that point arises some questions: how many are people like I, who out from some fascination are prepared to do extra work, to reuse the WP plugins that are marked now “not compatible with CP”? And to make also some evaluation at their own level of underestanding: does certain plugin really propose a big security risk if used outdated version? I fear it could easily limit the per cent of potential users of CP. People mostly are comfort lovers.
But at the same time, I appreciate the thought that has been expressed above that the ultimate choice depends of the working forces the developing team has. I believe that the 1.-st (the new fork) would need much extra work to be done. (I myself would be content also if it would be just a plugins like Classic Widgets etc and even not the whole GB code has not been removed. But I am contented also if CP would continue as the fork from WP 4.9. – In this terms I agree with a thought expressed above that not all changes made by WP during past years are “interesting” (for me, but also for many others?). I could even say that CP, in my personal view, has backported most of the interesting or more useful new functions.
If I try to make a conclusion: I think that the 1. choice (a new fork) could attract more people, both everyday users like I, and probably also the new developers.
Yet I could not say: let’s do it – because I am not the doer. Like a walker on Sunday morning I like to cast my eyes on a fresh, beautiful park with hundreds of flowers, trees, footpaths – easily forgetting that some have been working everyday from early hours, with cold and warm, with rain and even snow there for years.
I think the plugin/themes issue will solve itself given we have enough time to allow devs to submit theirs to the dir. To do this we need to offer them what CP is specifically while demonstrating we are up-to-date with latest standards and that could be done by cleaning up the WP 6 and adding CP stuff to it. And having a more efficient way to cherry pick from them for the future.
This could give us the time we need to develop a stronger ecosystem.
What I mean by CP being its own thing above is that to me WP is not WP anymore, so CP can think of what WP should have been and be it. But even staying true to the last real WP 4.9 will result in CP being totally different CMS because WP is going farther away very fast.
We can be the real WP and slowly grow and introduce improvements in line with staying true to the real WP. But we have to consider that at this rate WP will become something else entirely.
This means we can benefit from their work now, but if they continue to drift apart their next versions could be so different that backports are impossible.
That is why I say refork now that we can, align as much as we can, and release dir and maybe do work on REST API so that we can offer something devs are willing to support and build an ecosystem for. One thing leads to another and little by little CP will grow (and in its development steps CP is just “following WP steps” because WP started to have a real ecosystem around V2 and V3. Before that it was old devs translating it to allow localization and sharing the language files on very small forums and message boards month after a release and plugins shared the same way. This means that like WP, CP also can build an ecosystem given that we implement ways to make it available like the dir).
Looking at the comments posted after mine - I noticed that a bunch of people are akin to chasing after WP to reach feature parity in some way. Nobody says it with those words though but that’s what I pick up from it.
To name one thing the rest API - WP was fine WITHOUT a rest api or deep integration for it (for plugins) for may years. ClassicPress doesn’t need to chase that I’m sure - Or not right now. If you’re just going to copy such things, we may as well develop a gutenberg remover plugin and use WP again.
CP has the trusted and known action and filter stuff from WP which works fine for pretty much everything a plugin or theme may want to do. No need to replace, or even alter, that for now.
A basic but properly integrated API for EXTERNAL services is required at some level but doesn’t have to be a core thing and could be a separate plugin for those who need it - I’d bet that 50% of regular users (including WP users) never really need a rest API at all. Especially not if they’re not doing ecommerce or sending newsletters or using some remote thing like security scans or cdn.
And another - Code changes after WP5… Fine, but does CP really need those changes as well? Probably not. Consider that carefully as well… There is nothing wrong with running 10 year old routines if they still fall within modern specs and work fine. This ofcourse is in the vein of “don’t fix what isn’t broken” and will save a ton of time if you can let backports like that go or fix the newer routines with a simple alias function (or something to that extent).
For attracting plugins to your own repo. I’m not familiar with the repo too much. But my attempt to get AdRotate in there didn’t went so well as your guidelines are way way more strict than what WP does.
I keep putting off ‘fixing’ AdRotate because of it and as such it has been months with little to no action on that end. Loosening up the standards a bit to match WP (If its good enough for them, why not CP) that would make the bar of entering a lot better too. Just a thought.
@viktor And my CP plugins - I think I sold 2 copies this year, in case you’re wondering . But yes, it’s my small effort to make CP/CC appear a valid platform for my users to switch over. I few have so far. So yay!
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.
And no reason to limit it to Classic Commerce, it should work with WooCommerce so your target market is bigger and you can make more.
. But yes, it’s my small effort to make CP/CC appear a valid platform for my users to switch over. I few have so far. So yay!