On the CP homepage you find:
I quote: “[we] continue to actively seek smart ways to reduce code bloat”
Let’s suppose someone or myself tries to do something similar to what I proposed here, as a potential CP Next roadmap.
The first thing would be to remove things that the community wants to remove. In that sense, I ask:
“Is there anything you would REMOVE at all from ClassicPress?”
Just my two cents.
I agree with the idea of moving things out into plugins that can be activated/deactivated at user will. This proposal isn’t new, it’s the core plugins concept that was set for a future version of CP.
Recently however I asked myself how it is possible to implement all that without launching the plugin/theme directory.
I mean, ok we can have an install packaged with a couple of themes and a group of plugins.
What if I decide to delete some plugins I don’t use and later I want to install them? Do I have to locate them in the beta directory? People would be discouraged.
What if at the same time the directory is launched and a direct connection to it is made available on the dashboard and a filter is added to it to search for core plugins?
I think these two things go hand in hand.
As concerns what I think should be removed: comments, media library, gravatar for obvious reasons, xmlrpc, and customizer.
I not only agree with that part, but also believe it’s the most important step to once for all do the first cut with WP. Stop this mess:
Start being something that’s not a broken copy of WP.
I remember starting an initiative to implement the Plugin Directory but I stopped after realising that the backend API structure didn’t match the original WP structure.
It’s kinda fun… back compat everywhere but then the CP Plugin Directory API is done with a new random structure, losing the whole ease of integration. Why?
Here you mean separating into Core Plugins, not remove from ClassicPress. That’s fine but I would leave that list for the second step in the proposed roadmap and stick to removals for now. If the community decides that NOTHING at all has to be removed, but moved into Core Plugins instead, then that’s cool and I will focus on that step.
the only ones I would entirely REMOVE are xmlrpc and gravatar (gravatar is wp stuff, it sends data to wp and is an external service we don’t need. we could provide a simple plugin to manage avatar that hooks in an open source alternative and eventually it could be a core plugin or a simple plugin).
the others are to be moved into plugins, and I agree they can be looked at in a second moment.
Good. I can take care of both things if the community approves. Here go my two cents:
Note that the Pingback functionality needs XML-RPC to work. Either the Pingback functionality gets rewritten without using XML-RPC or it gets removed together with XML-RPC. Hence the question:
1. 1. Do you approve on removing Pingback functionality from ClassicPress? Yes or No.
If No, why? Solid reasons please, more than “I’ve used them during the last 20 years because they once were a trend and I’m afraid of moving forwards”. Just as a note, other than useless, pingbacks are a source of SPAM.
See the updated Pingback concept called Webmention. (This is W3C stuff, not just someone’s random fancy idea)
My first cent is: remove XML-RPC/Pingbacks altogether and leave Webmention functionality for Plugin territory.
I’m not a fan of externally hosted Avatars, hence I am against the idea of “an open source alternative”. I would in this case replace it with local self hosted avatars. One could argue if this should be core or plugin territory, but here I defend the idea of having it in core. An avatar for a user profile is as old as the internet and still expected to be available in modern times. The code it requires is actually very little compared to other things that should obviously not be part of core like a GraphQL API, a REST API or a whole Comments System.
My second cent is: remove Gravatar from CP and replace the avatar functionality with a self hosted functionality.
I never use pingback/trackback and the like. so for me is a yes remove. because nobody wants an insecure site prone to attacks and spam. I agree on relying on more modern systems like Webmention.
About gravatar, what I mean is that the avatar generator could be a plugin (a simple plugin that hooks in something that is not gravatar) and yes, generally if we remove it we can totally include a basic avatar management in core.
you have to think about two things however in relation to avatars: multisites and communities where user generated content is key. there should be limits in place or people with no knowledge about image optimization are going to upload to sites very big images and this could result in bad performance in those sites.
I agree with removing both xml-rpc (and leaving webmentions for a plugin) and gravatar (and replacing the avatar functionality with something self-hosted).
There’s a table in the database called wp_links
I’ve never seen it used. Perhaps there’s code related to it that is also not used? Afaik it was „moved to a plugin“ about 9 years ago, and that plugin I’ve also never seen in action on any site. Maybe something that could be counted as bloat.
“Before version 3.5, WordPress had a so-called “blogroll”, “bookmarks”, “links” - these were entries that had their own separate menu in the admin-panel, just like “posts” or “pages” have now. Since version 3.5, this menu disappeared if there were no links in it. The link functionality has been disabled, but it all remains in the WordPress kernel code and is very easy to enable it if you needed.” - Source.
Also read: #21307 (Remove Link Manager from core) – WordPress Trac
I agree with removing rests of the Link Manager/Bookmarks functionality.
And yeah, willing to start right now with all three topics but I don’t know what will happen next when people complain about their old plugins not working because it relies on an old pingback/xmlrpc/links function.
How far is the community willing to accept inevitable breaking changes form this initiative? What I am definitely not doing is remove one thing and then start adding random empty functions which return random stuff just to “make old plugins work”. No no.
How many votes is “fair” for a decision to be democratic?
In v1.x none (no backwards issue may be introduced. Not even if the plugin is at fault 
)
In v2 do what you feel like.
That’ll be the status quo.
This is contradictory to this:
But yeah, that second statement doesn’t make much sense anyway because if CP 1 is compatible with CP 2, then CP 2 limits = CP 1 limits. Or am I wrong?
So, I’ll start working on the 3 mentioned topics. But I wonder if the ClassicPress-research/ClassicPress-next should stay as a fork from ClassicPress/ClassicPress or if it should indeed become a standalone repo, so that it doesn’t constantly say “this repo is x commits behind”. Some people may want to keep on with CP 1.x (an that’s fair), but eventually both versions will be independent. Any benefits for having the fork relationship?
Im saying do what you want in v2 because no one even knows what v2 should look like, and to be 100% honest it will never come to existence imo.
If it will, it’ll be probably v2 because we update jquery or so.
So maybe I should have said „V3“ or even „your own cms“
You’ve better chances of bringing such changes to v2 than to v1, because v1 will not accept changes that might break things.
But yes, maybe it should be v3. Or as said a new cms. Not joking. It all depends on your Goal
But voting and discussing won’t either expedite nor actually make it possible, believe me on that.
I understand. I’ll wait for more voices. The only thing I don’t want to do is waste energy.
@viktor asked me if I was still willing to do something.
I proposed a roadmap, got positive feedback, and now got more feedback on 3 potential realistic approaches for said roadmap.
Once the questions I proposed are answered, I’ll start on it.
If this leads to dead-end discussion about subtelties then I’ll respect that and leave 
Quoting questions for clarity:
Yes. That’s what I mean.
The positive feedback came from 2 voices.
Perhaps 3?
What tells you that about the actual community behind cp?
Let’s remember that wp pushed gb based on community voices too. There, it was some thousands of against, thousands more in favour. Now there you know you do something for a large community
So the question is justified I think - what’s the goal?
Produce/help a community or because you like the challenge? If you like the challenge then going full blown own cms is many times more rewarding.
There’s so many things we could do… we just need pr’s
If you do it for the challenge it won’t matter if they get merged now or in future or never. If you do it because you want this tool to be in a certain way, you’re better off creating that from scratch.
Not trying to discourage you, just pointing out that voices here in cp will sum up to perhaps 10 voices. And even with all in favour that won’t mean it gets done, actually.
In answer to your questions - there’s no “amount of votes needed” defined anywhere and we don’t have numbers to actually define one. There’s no way breaking changes will go to v1. maybe to v2, but that again depends on who’ll accept the merges and not on us delivering the idea. And yes probably v2 will be as I mentioned (if ever existing) a “minor” change in the sense that maybe some libraries get updated but with major focus on keeping sites working. That’s what I’ve gathered from my experience here and discussions (endless sometimes) about the subject matter
Thanks for your kind and realistic explanation of your wise perspective on the situation.
I want to do it for a combination of challenge, nostalgy and creativity.
I understand that CP is not about doing something that entirely breaks from WP (in the sense of creating a new CMS from scratch) but what I still cannot grasp is… does CP aim to be a frozen WP 4.9 with some minor tweaks or does it aim to be something new, based on the foundations of WP?
If it’s the first thing, the whole branding should be changed and all the lean, lightweight and less bloat and so on should be removed from the descriptions because it would all be lies. It should say: “ClassicPress. The WP 4.9 version with minor tweaks and a few backports”.
All this fuss about a potential “Next” version, be it a 3, a 4 or a 6283 doesn’t make sense if CP 5 wants to be compatible with CP 1 because then it’s all just semantic BS. So that’s why I asked how far the community wants to go with breaking changes in the “Next” version. I don’t care working on it alone, I just want to know I am not doing it just for myself, because in that case, I will just do nothing.
Lets just say: I joined the circle pit called ClassicPress, to not only keep WP pre-Gutenborg alive, but to also see some improvements over the “original”. So, in my case, you wouldn’t indeed do it “just for yourself” 
cu, w0lf.
So did I.
I have been using CP since it started with Scott Bowler and a dream.
Everyone knew there would be problems with plugins no longer working with CP down the line, and forked or new ones have been made to help mitigate that. But WP 5 has made this a nightmare.
All my sites run on CP and I have to use old plugin versions to keep them going. I even have to run old versions of my themes as well. It is obvious something needs to be done to keep CP 1.x viable.
The majority of CP users do not post in this forum and I rarely do either. Doing so usually results in being intimidated. Looking at the number of views on topics shows people are reading them, but keeping their mouths shut.
I even ran a site for a while that was dedicated to following CP and had a forum where non-geek people could feel relaxed enough to post anything. But still they did not post.
CP 2.x has always been the version that would be vastly different from WP. We were told we would be able to use 1.x indefinitely and it would receive security updates as needed.
The recent debacle with 1.4.0 showed how moving too quickly can cause major problems. There is no simple solution to 1.x’s compatibility problems and not enough developers to fork plugins.
I know nothing about how CP works at core level, but if it could be made to work with WP 5 plugins, then it would solve our biggest problem.
I have been thinking about moving back to WP, but the classic editor is not going to work for much longer. If Scott’s dream is to be realized, the compatibility issue needs to be overcome. We don’t need anything removed in 1.x - we need something added.
There is nothing you can add to make this happen. This is a dead end discussion. You can call Einstein and he will say the same: the only way to keep a frozen copy of WP 4.9 working with modern WP plugins is, not use modern WP plugins but instead, fork them all and freeze them in the past too.
Now you know why users don’t post in this forum.
They are afraid of Einstein? Or dislike common sense?
It’s funny, how when arguments fail, people look for a reason to get offended
Appreciating harmless jokes for what they are, keeps the soul happy.
