Assuming there is a similar amout of work to get from WP6 to CP 2 as from CP1.5 to CP2 and no other considerations then toss a coin especially given limited manpower.
Does WP6 fork get back any plugin compatability that would be, although probably short term, a plus.
Would it get more core contributors, probably not.
Would it possibly get some plugin developers to actively maintain compatability again probably not.
So for me it comes down to what the team actually doing the coding and updates prefer and hopefully I like/can use the result.
I have written another post on what CP could/should be.
It is a long post, thake a breath or a Cedrata (italian soft drink) before reading.
Something that didn’t change since when the project started. At the same time, I think that the project did too many things like the custom repository for plugins/themes that to me is unnecessary.
Anyway, to go back on track, I think that when the roadmap or what is the purpose of the project is clear it will be easier to contribute to CP. Honestly, I left the project when I saw there were more interests on adding things like the custom login screen that backport stuff from WordPress.
I am disappointed as today also on contributing to WP, but I am still doing it with patches because there was margin to do things and with people to talk that are real contributors, not just giving opinions. This is the issue of WP where the opinions are ignored usually if not pushed by core committers instead on CP everyone can say something. So we see now the problems of every side of that.
What is the solution for all this?
Define clearly what is the purpose of CP, to me is just WP without gutenberg.
About the plugins that need gutenberg like WooCommerce for the analytics stuff it is something to discuss but to me not with a custom fork of Woocommerce again. Just 1) because add more things to do and keep up with the official release, 2) create more troubles with integration with other plugins.
It is something that we need to address in this thread? No.
Define what is the future of CP and the purpose, excluding the issue of “How many contributors we have” as if there is interest in our direction we can find the skilled contributors that want to put efforts on that.
To the people that says that CP in that way is not different to WP with Classic Editor/Classic Widgets, well it’s not true.
If you are a coder, you know that when there is less code to maintain it’s better, there are less risk stuff and so on. Including also that the technology is more performant just because some stuff it’s not there or enabled only when needed (like for integration with woocommerce).
Also, we have to remember that the plan is to have the gutenberg stuff also in other part of the backend like in the menu editor and who knows also where? Moreover, those plugins that put back the previous UIs have a deadline for support, and who knows if it will be postponed after 2024?
If I have a business running or multiple, I need to thrust someone that let me sleep well and not with nightmares. WP gives that safety to support the latest PHP versions, but doesn’t give me safety about the performance/security because of Gutenberg.
Our customers don’t care if it is using a tractor or a drone, just matter that the website can be pursuing his business. This means listen to what Google is asking, what are the new performance trends, integrates with plugins and so on.
If the project can offer natively a WordPress Gutenberg-free in any side, that is turned on only when a plugin required to work because needs a JS library or whatever I think that is worthy.
Probably I said too many things or forgot to specify something better. If you (everyone) want to discuss with me (on my website put above there are all my social reference), but I am not anymore on the CP slack instance.
Thanks for the good insight Daniele. With blocks taking over classic features and JS taking over from PHP, there will be a time when CP won’t be just WP without Gutenberg. It will be a different CMS.
WP won’t develop these features further, so do we freeze them in time and never work on them? Because if CP is the only one with classic menus, widgets, etc. we have to develop these features and enhance them so they cater to the present needs of users. For example, when jQuery v4 comes out. We would need to upgrade it, and make these features work with the new version.
I think a hybrid approach would be the best approach. This is the only way to leverage the WordPress codebase while meeting CP users’ needs.
CP will never beat WP, it doesn’t have to. It was created to fill a specific need WP can’t fill.
A hybrid solution that keep CP without gutenberg to me is fine, as we are still following that idea.
The problem is right now what is the idea for this project after all those comments.
CP can fill the market for a WP that is a LTS, that was the initial plan. So you don’t have to worry every 3 months for a new release but you have something that doesn’t change but is still working with the latest stuff.
Aha! That’s where the link reference came from… totally missed that.
Well, out of curiosity I installed it yesterday and classic commerce works on it. So did most other plugins i use.
It kinda renders the whole ‘forking wp6 is a lot of work’ moot, as it’s already been done. So the little resources you guys have can be used to add to this (or something) and then add the classicpress flavor on top, if any is needed.
You won’t be classic anymore though… so a rebrand is in order then.
The fun fact is, that has been to proposed idea since day 1. This only proves that people against the idea didn’t really get the idea.
Again. I created that fork because after having discussed this a million times in the forum, I decided to do something about it and test it, see if this idea works.
And, as you well said:
Of course, the whole point is, keep the WordPress Core WITHOUT Gutenberg/FSE intact (just with PHP 8.1 compat inside, query optimizations, code modernization, dependencies updated…) as well as a VERY easy to maintain workflow, which consists of git cherrypicks.
I stopped maintaining it (even though it’s something I can bring up to date in less than 1h) because I don’t want to waste more time in an open source project with no traction. That’s why I reached out on slack and proposed the idea of using this as a base for a new version of ClassicPress.
AGAIN. No one is saying that we have to copy WordPress. That would indeed be a very stupid thing to do. The idea is just to have a fresh start which will make it EXTREMELY EASY to bring in further enhancements (compatibility with upcoming PHP 9, jQuery updates, …) while at the same time focus the little team we have to work on a standalone plugin directory, instead of chasing compatibility changes and random problems that were solved months ago…
And just so you can see how extremely difficult it is to maintain this project, I recorded the whole process and uploaded it for you:
Of course, before pushing stuff into the repo, gotta run the tests, make sure everything works fine and blahblahblah.
Thing is: MOST commits are about performance optimizations, code improvement, dependencies updates, … so yeah, why miss all of that?
Update: I went over the whole list (60 commits - could you please link to any useless commit, or is it all about good things to bring in?), now WP CMS is up-to-date with WordPress again. Easy.
Well I’m not sure if I understand all the issues here but I think this is primarily a question for the main contributors. But otherwise my gut feeling is as follows:
In my mind, the primary reason for Classic Press’s existence is not for what wordpress is today but the threat of what wordpress will (supposedly) become in the future - namely an unusable CMS for those of us who see Gutenberg as an intolerably inelegant solution to a real problem. When that day comes we want to be ready for it. So in my mind the question for the current maintainers (the ones doing the most work) is: what’s the least labor-intensive way to keep the codebase as up-to-date as possible between now and that future time (re-fork or continue back-porting)?
The poll is closed now. Path 1 has 20 votes while Path 2 has 18 votes.
Although path 1 has more votes than path 2, the difference is negligible and highlights how divided the ClassicPress community is. What’s more important is that every participant wants ClassicPress to exist and grow.
With the WPTavern article about our “crossroads”, many outsiders across social media channels said they don’t understand why ClassicPress was created to begin with, how it survived for over 4 years, that it’s a stupid idea, and that it will die.
Comments like that are not new. We’ve heard them since day one, we’ve heard them when ClassicPress turned 1 year, 2 years, 3 years, and 4 years and they will continue… so will ClassicPress.
ClassicPress continues to exist and slowly grow because it’s not WordPress without Gutenberg. It is WordPress. It stayed true to WordPress philosophy, something WordPress leadership failed to do in order to advance their commercial interests. There’s a reason why Matt killed WordPress Governance project, then pushed a half-baked, bug-ridden Gutenberg into the core a few months before securing $300 mil and $80 mil from investors to compete with website builders. Why some controversial features are forced into the core by Google-sponsored contributors. WordPress might be open source, but it’s not a community-driven project anymore.
Gutenberg was the breaking point for the community when WordPress failed its own philosophy:
The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.
We are able to do this because we have a very capable theme and plugin system and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
The Gutenberg plugin is still 2 stars. Classic Editor is still 5 stars.
ClassicPress users don’t hate WordPress, they love it. That’s why they chose to use ClassicPress instead of Joomla, Drupal, etc. WordPress right now is basically MySQL when Oracle acquired it, so now we have a community-driven MariaDB (or ClassicPress in our case). No wonder WordPress lost market share for the first time recently.
Forking is a natural part of an open-source project’s lifecycle. Even WordPress was a fork of b2/cafelog. Look at all the Linux-based operating systems and their forks, and forks of those forks. When the project doesn’t meet the specific needs of a group of users and these users are willing to dedicate time and money to make something to fill their needs you get a fork.
WordPress didn’t (and still doesn’t) meet the needs of a group of users. The fork lives on:
After listening to part of the wordpress#StateOfTheWord I am so glad I have stopped using WordPress and moved to @classicpress (source)
Frankly, many developers in the ClassicPress community use both. I use WordPress for many projects and when I need something lighter, leaner, and easier to use I choose ClassicPress. Use the right tool for the right job, not everything is a nail that needs to be hammered in. Sometimes you need a screwdriver, sometimes an Allen wrench. Pick the right tool for the right job.
ClassicPress won’t beat WordPress. It doesn’t have to. It will help fill the needs of users that WordPress can’t fill anymore. This is why forks are important.
ClassicPress community has made mistakes, no open-source community is perfect. We’ve learned from our mistakes and are trying to implement changes to build a better foundation for the project to grow.
That’s my personal 2 cents.
This topic will be closed.
The core contributors will discuss the results of the poll, the feedback given by the users, and what we can realistically accomplish. All active contributors will be contacted. Since it’s the holiday season this may take a few weeks. We’ll try to draft a plan/roadmap to leave this crossroads behind us, and give WPTavern something to write about again.
Anyone willing to start contributing to the core should PM me, but all non-coders are encouraged to step up and help the project grow - writing documentation, translations, testing, marketing, blogging, etc. Whatever your skills are, they can help ClassicPress grow. PM me, join Slack, stop by GitHub, pick your channel. Donating to support ClassicPress is also a great way to show you care!
And remember, use WordPress, use ClassicPress, use Joomla, use Drupal, use Django, use Laravel, use Backdrop, use the right tool for the job.