Yo waddup! I like the idea. Count me in.
1 Like
…first and foremost. CP has very little number of devs able to really take care of what managing a whole release is like. Dividing them to do everything at once isn’t logic at all.
About compatibility there are two types:
-
compatibility with WP 4.9 to ease the path of the migrating users
THIS ONLY REFERS TO V 1 THAT IS AN LTS AND IS USED AS AN ENTRY POINT AND AS A LIASON WITH V2 THAT WILL INTRODUCE BREAKING CHANGES (WordPressers will entry from WP 4.9 (or whatever version they have that we support migrating from) to CP V1, that will allow them to have a secure path to V2 and following - migrating from WP to CP V2 directly is NOT going to happen). -
compatibility CP with CP
That is meant to ensure that if I am on V1 and wanting to upgrade to V2 my site won’t get bonkers when I hit upgrade. Basically as I have understood the WP autop issue stands in this category because core of V1 relies on it and instead to be able to ship the editor V5 in CP V2 we need to do something to core so that it doesn’t need WP autop any more (or if it does it works with the upgraded editor) and this if done well is going to result in me upgrading to CP V2 as soon as it ships without fear of my site breaking into pieces.
As of now V1 has some issues we need to complete to be able to use it as a bridge. And a bridge is needed because there aren’t only the users discovering CP firsthand, but we need to consider also the ones wanting to migrate to CP from WP.
The second type of compatibility (or better: make breaking changes in a way they don’t break sites) is what CP was born for.
GB is a breaking change (it is a very different editor). It was introduced and broke sites. MANY MANY MANY SITES.
It could have been implemented slowly, better developed (WP has the manpower to do so!)… And in that case it woukd have being a breaking change DONE RIGHT bringing a very new feature without disintegrating people’s hard work on building their sites.
CP wants to introduce breaking changes without throwing sites in the garbage.
Breaking change doesn’t mean:
“Oh I want to develop a new feature, I will throw it in without considering the outcomes, I don’t guarantee it works, if it breaks your site I don’t mind because it’s your fault for upgrading”
It means:
“Here, I am developing a cool new feature that is very different. I will release it in V2 since it’s a breaking change and I am taking my time to release it to ensure that you can upgrade from your V1 to the new V2 safely. If you don’t like the new feature, please do know that you can use V1 safely since it is an LTS that will receive security updates for very long time and that if you at any time change your mind and want to upgrade you can also do so without issues because upgrading is seamless from V1 to V2.”
That said: people are already working on both V1 and V2.
It was decided that V2 will be all about the editor upgrade and the introduction of plugin/themes directory.
The directory has priority and is a VERY MAJOR CHANGE that will open the doors to the development of an ecosystem (devs will have a way to deliver themes and plugins and their updates).
To integrate it into CP there are two things needed: working on refining it and making it really something amazing (and this means knowing Laravel since as far as I understood it is made with Laravel, love and efforts) and the part where core code gets changed to implement it.
@anon66243189 is leading the effort of making the directory amazing and @james is leading the effort to implement it into core when ready to ship.
V1 is all about backports of useful things like SECURITY FIXES and smaller tiny features that are “non breaking” (it is possible to include in V1 some features like the login page customization since things like that don’t break sites when introduced and so there is a number of people following backports of security as a priority and these little nifty things as a way to show that even if V1 is only a bridge LTS it is making smaller improvements for people who want to stick with it forever).
Now, if you are a dev and you want V2 to happen this is fantastic!
Please help to include the amazing directory into the core in a way it doesn’t break my site when I hit upgrade.
The editor upgrade is scheduled to happen after the directory inclusion in one of V2 point releases, so you will have to work on it after completing the directory.
If instead you think you are better at keeping up with backports, that is happening for V1 so you can lend a hand there!
The slowness everybody sees is due to the fact that our few devs are working on both versions keeping them moving at the same time.
If MORE DEVS decide to roll sleeves up, then having V1 team and V2 team is feasible.
4 Likes
Great 
You have expressed a lot of enthusiasm for this approach here and in other threads, for example:
Enthusiasm is a great first step. The next step is doing the work to make it happen. So, I invite you to try out this approach.
Sure, I created one: https://github.com/ClassicPress-research/ClassicPress-next
It is under ClassicPress-research and named ClassicPress-next because it’s not currently clear to me whether this would be released as v2 or v3 etc, and on what timeline. I imagine that alpha and beta releases would be published here on the forums for people to try, and then the repository would be moved/renamed when it gets closer to an actual release.
Other than that, I think you should be the first person to “take care of PRs” there. If you are willing to help with this as you’ve stated, then send me your GitHub username (here or in a DM) and I’ll add you so you can get started.
Multiple people have expressed a desire for ClassicPress development to work this way, and I’d be happy to see this take off. In that case, I would take responsibility for the ClassicPress v1 branch and leave the work on future versions to others.
When breaking changes are introduced, there is generally no way to guarantee safe upgrades. This is one of the biggest issues with breaking compatibility: how do you make sure that people can upgrade? For a high-profile example of this I suggest taking a look at the transition from Python 2 to Python 3.
In this case, what would the upgrade path from ClassicPress v1 to v2-with-breaking-changes look like? This isn’t something to be solved today but it needs to be kept in mind when planning a future version with breaking changes.
2 Likes
I think I’ve heard this before, but it is a misunderstanding that originated from comments made from ignorance of how things work.
We should correct this misunderstanding by saying that upgrading the editor from 4.x to 5.x has nothing to do with changing wpautop or the format of the content stored in the database.
And the work of the update could go faster if people would stop by and help test more often. Contributing is not all about code! We need testing and docs and monitoring bug fixes from WP. Part of knowing what to try in v2 or v3 is gleaned from knowing history of WP, what was tried and rejected or why things ended up the way they did. Considering the large user base, you can bet that the important things were proposed in tickets already.
Can you point me to this decision?
I’ve heard that also, but I think it is a bad decision. But, not my problem.
Really? Where is this documented?
2 Likes
I think that nothing has been decided yet. There was only some discussions about these when James updated the Roadmap to better reflect the current and realistic status of the project.
2 Likes
Thanks @james for pointing this put.
To me a breaking change is “something that changes the CMS that gets included in core”.
It doesn’t mean that the change will surely break sites.
It seems instead the term is used literally to mean that this kind of changes are going to break sites FOR SURE because even if we are carefully introducing them it is impossible to make them safe.
My question then is: why should someone risk all their site to upgrade to V2 from v1, when there’s no certainty? Only for the sake of new features? It’s not much different from what WP did with block editor. It’s only slower and gradual. But in the end, the result might be the same. Sites being broken nevertheless.
@joyously thanks for explaining WP autop better, not being a dev I clearly misunderstood when trying to piece together what the issue with it is.
About the “where is this written”, there were many discussions (slack and forums) and what I understood is that people were working to make things happen in a certain order. There wasn’t a real “let’s write this up officially” but the fact people discussed the possibility to release the editor in core during version 2 to me means that the community leans towards that solution at present. What I noticed is that the project is progressing when people take leadership and tends to stall when this leadership “vanishes”, but the general direction is to release things one after the other. Not at the same time. Directory is at the final stages and people are pushing to put it in core when ready, but being the editor important I believe the suggestion to include it in the V2 cycle is consistent enough to call it a plan.
Other people stated that CP doesn’t seem to have a “real plan”, that the roadmap isn’t really a plan.
I think the real plan may not be the official written one because some people may not recognize themselves into it, but it is surely represented by what people get done. I mean… If many people work on something like the directory for many hours this means they want it and they “see it in core”. Things like the directory and the editor really received constructive discussion that lead people to actively DO SOMETHING. Even if there were conflicts, disagreements and misunderstandings along the way. These two things and what is going into V1 point releases are the real plan. These things are being worked on. Are what people see when coming to meet CP for the first time.
2 Likes
V2 Roadmap is pretty clear to me actually. Perhaps that page would need a more “roadmappy look” thou, because it might no the clear when reading it that it is actually a roadmap.
Plugin Directory
(Status: not done. We can’t even enforce basic guidelines as of now.)
Increase the Minimum PHP Version to 7.x
(Status: not done, we are not even compatible with PHP 8 yet as far I know.)
Just to clarify this:
@smileBeda is leading the effort of making the directory amazing and @james is leading the effort to implement it into core when ready to ship.
I am not leading the effort for the directory. @wadestriebel is.
I do not speak Laraval, even if it is PHP., and that is the language or framework used for the dir.
I am merely seeing issues I pointed them out and am willing to do what I can with my knowledge and ability to make it better.
Current ongoing projects are listed here both with leading person, and progress made:
There is progress made that somehow is not seen, I think. Daily. Daily we get new Docs for example, that then will be linked from inside the CMS to point to our doc rather than back to WP.
It is a extremely time consuming task to which everyone could contribute, but as a matter of facts, only 3 people so far did actually contribute results.
We have a entire DOC site with code reference as well, all set up within this year, not perfect, but much better than linking back to WP Doc which will not be compliant with CP anymore (due to changes made meanwhile to many functions and many new functions added in WP).
I’ll be honest. Those progresses are more progress than this project has seen in the past 4 years, and yet, … they seem to not really matter
Perhaps it is the wrong effort? Perhaps we should produce a breaking new CMS … that has no DOC? That has no translations? That has not a single theme? (Well, I stand corrected, meanwhile a couple have been added by @benlumia007! Which is great!!!)
Now… if someone has the time and knowledge to work on a breaking CP version where RPC is removed, comments are removed, theme and plugin code editor is removed or whatever else feature is added, removed or else, I think they are very free to do so. I have said it before thou: we are not able to maintain more than one version at a time.
Removing stuff and putting it into plugins will lead to only one result: a ton of plugins that wont be maintained (like CC) and that will mean a totally unsafe CMS because folks will in most cases continue to use those features be it as plugin or as core. Once in a plugin, back ports wont do it anymore. Security updates will need to be pushed to those plugins which will have new codebase, etc etc.
Also backwards compatibility is not really about WP. We shouldn’t use WP Plugins anyway neither themes. So who cares about that, right? But now I run CP on my sites and use its features. And tomorrow a new, breaking version comes down. Why should I do? Let’s say my plugin relies on the comments system (one of it does!). I would have to either rewrite my plugin to make it V2 compatible or whatever version it would be, but then Id lose v1 Compatibility. I would have to rely on that plugin that replaces the core feature to be maintained. It wont, by what I experienced so far. Thus… I would have to decide, and my decision would be “Stick with what works and people use”. And that will be … v1 or even wordpress, to be honest, because … no one uses CP for business
I mean, maybe I am in a different world but no client so far even considered taking my recommendation to use CP. They happily install “Disable Gutenberg”. They do not want their money put on something they might not be able to use tomorrow. Thus for me CP is and remains a personal project. I use it, in my sites. And I want to keep them working.
Again, if someone has the time to do the breaking changes… nothing stopping anyone!!!
I personally don’t. I barely have time to make the work that is possible to do with more little effort like DOC, Translation, and the few tiny features I have and plan further to push to CP
I believe personally this is the way we all should focus on: to perfect the tool we have
Not to strip it apart and create a lot of unmaintainable add-ons that no one will maintain.
I tried to put in a jQuery update… and got stuck at the last part. The first part already took considerable amount of work. I would not even know how to chang the entire CMS to use vanilla JS. I think it is impossible, in a realistic way, because of all the code that already uses jQuery.
But again, I am not opposed in seeing a V3 or V2 or v100 out there.
I think no one is.
Probably I, and many others, simply won’t use it, because I would bet money on the fact that - if it makes it out - it won’t be maintained after.
WP has thousands of developers and they aren’t able to catch all security issues, for example. How would we manage this? Without a community actually testing things, using things and then fixing things?
Let’s also remember that a V2, or v100, without a single plugin, without a single viable theme, without an active community supporting and using it, will be just as useless as CP is now (in terms of real projects).
CP right now can only be used if you custom code. Not a single important plugin that users want to use is actually working with CP in a guaranteed way and if it does, it may stop tomorrow.
That is why my efforts go in the things I can do and can maintain somehow, and in a set of plugins that should resolve that massive gap we have there. That set of plugins is already used by me on my sites and client sites (with WP, since my plugins work with both CMS) but I do not feel conformable in pushing it publicly yet. I might make an alpha release sometime soon. If someone is interested in contributing, here it is again.
2 Likes
Thanks everyone for their input, really appreciate it. This work can be done in parallel, and some things can be reused for both versions.
For example, TinyMCE update is not all about wpautop as @joyously said. Most of it is adapting itself with the core to keep working for different cases (like importing media, working with wp_editor(), customizations, …)
So work has to be done on both sides of the coin (to keep compatibility with older WP and also to keep it working with WP itself). I can put in my time on the second part, and not touch the first part, which I definitely don’t support. But yeah if I put work on that second part, then it can be used for version 1 too.
What I am saying is, that having the doors open for v2 is not something bad against v1. It is an addition. So thanks @james for creating that repo. I still need to figure out how I want to help and where, but I am going to do it. Probably helping with Tiny is the best thing to do before jumping into Core Plugins.
Now, @anon66243189, about Core Plugins:
Taking them out of core and into a Core Plugin is not something bad that will be left unmaintained. The comments system is old as WP itself, it’s not that it’s something that has to change or be maintained every day. Taking that out of core will allow people who don’t use it, to disable it. And the maintenance it requires is minor, nothing big has happened to it in many years. Having it apart will also allow to work on it independently and keep the codebase cleaner.
I actually want to use it in one of the sites I manage. It is a fitness platform where the fitness instructors create nutrition plans and fitness routines for clients. The platform itself works great but when WP 5 came out, it required me to be there tweaking and changing stuff just because. And yeah I dislike the fact that WP is like a new software with every version, everything is constantly changing!
CP shouldn’t aim towards being something that is growing and include new features every day. Instead, if you want to have businesses in mind, it should actually be separated into Modules (Core Plugins) for the basic WP stuff we all know: Comments, REST, XML-RPC, and so on. And then build a solid ecosystem on the top of it. BUt it should stay as lean as possible, and that means → keep a lean and well-designed core and provide extensions for it (don’t back every new idea into core!)
A leaner core can then be better refactored and having separate extensions is better for maintenance.
2 Likes
Of course they matter. And they matter much to make the CMS and the project run smoothly. But they are the boring and tedious kind of work — not the fun parts that get people excited — and so they are often overlooked.
I won’t use it either, if maintenance can’t be guaranteed. Stability is a very big factor why I’ve chosen CP. And I’d rather stay in version 1 forever — which guarantees that stability — rather than risk later versions.
1 Like
Great
I am waiting for your GitHub username to add you with write access to the ClassicPress-next repo.
The same goes for anyone else who would like to explore this path.
2 Likes
Since we’re talking about v2 here, if for some reason @alvarofranz isn’t able to work on the “next” version, what would it look like to continue with the current development approach to create some form of v2 (whatever the breaking changes might be)?
We need to cover our bases and have a plan for v2, either way.
1 Like
It’s @alvarofranz, thanks again @james
I’m not only able but also willing to work on this. Currently finishing last year of university and also working. But I’ll arrange myself to find time. After university is finished, if this project is still backed by the cool community it is now, I definitely will be helping more.
The main problem I see here, is to keep progress for v1 and v2 in sync. Obviously not everything will be in sync, but changes to the UI, security improvements, WP backports are likely going to have to be in sync. Making the same PR for both versions isn’t very clean. What do you suggest?
Also, where do you suggest that work for v2 should start? I think that the most interesting realistic feature right now is regarding TinyMCE and separating the comments system into a Core plugin (trying to break as little as possible and keeping it on by default).
2 Likes
It’s not just being able or willing to do it. With pandemic around, you might not be able to work for one reason or another. So I’m just curious what would we do if for some unlikely reason that happens. Hope for the best, but prepare for the worst.
First, I would check with Joy to see where TinyMCE upgrade is and when it might be ready to be integrated into core. So you can plan that accordingly.
Second, before you dive into removing comments, test the waters of core plugins with existing work done by Matt. He’s created 5 core plugins:
- Customizer
- XML-RPC
- REST API
- Emoji
- Embed API
Probably starting with the easiest one, Emoji. Core plugins require some basic features like the ability for a plugin or theme to install and activate it if they require it. This applies to all core plugins. So you need to build that out first, before working on individual core plugins. Breaking it down into smaller, more manageable tasks will help you move forward easier and see your progress.
2 Likes
That’s a good idea. She and John have worked on it a lot as I see on GitHub. I am reading through the issueds so they don’t have to waste effort explaining all that again. I actually installed the plugin and TinyMCE won’t show when editing a post. So I have to figure out where they are and how I can help there.
Great idea too. The comments system is probably too big to start with that one.
3 Likes
There is an issue right now we’re trying to figure out on Slack, in accessibility channel.
1 Like
The plan for v2 if I am leading it is for v2 to include the directory integration. v2 and future versions would still follow the plan outlined at ClassicPress Roadmap | Planned Improvements to ClassicPress, and possibly the next “big” new feature after that would be the upgrade to TinyMCE v5. That would change if TinyMCE (or another “big” feature) becomes production-ready before the directory integration.
This isn’t happening as quickly as some people in the community would like, so I’m also open to other people taking the lead there, and me continuing to focus primarily on the v1 branch. Under this plan, I would also take responsibility for a reasonable upgrade path from v1 to future versions that include breaking changes.
Either one of these plans is viable, as far as I’m concerned the first one to be production-ready and get community acceptance should be shipped as a new major version.
If you are starting “from scratch” on v2 with breaking changes, then please join Slack, attend core development meetings there, and ask questions - you will still need to interoperate with various already-existing parts of the ClassicPress project. It will also benefit you to learn how to use git well, and we can help there too.
Anything that is intended to go into the version 1 branch should go into version 1 first, then be git merged (or git cherry-picked) into the version 2 repo. The reverse approach is also possible but it seems less elegant given that we already have a well-established development and release process for v1.x.
I still think the most valuable feature for the CP community is the directory integration. However, we are here on this thread in part because people don’t seem to agree with that approach anymore. So, if you are willing to do the work to build what you want to see, then it is up to you
Added, you should have an invitation in your email and if you visit https://github.com/ClassicPress-research/ClassicPress-next.
If anyone else is also interested in working on a future version of ClassicPress with breaking changes here, then let us know so we can coordinate work and access.
2 Likes
James is right. Directory integration should be prioritized. The main roadblock here is directory API.
@wadestriebel is there an ETA on a directory API that can be used to integrate directory with the core?
If API won’t be available any time soon, core plugins would be the most logical next step.
2 Likes
no one uses CP for business
Actually, I do!
5 Likes
This still makes sense to me (both as a prerequisite to core plugins and in general), but I have been thinking lately about what it should mean to be “community-led”. We have a couple people who are working on v1 and towards our previously set goals, and if others want to try another way, then letting both projects proceed independently should be a great way to let the community lead. Since these are mostly new contributors who want to work on “breaking changes” instead of other existing projects that are “boring and tedious”, then this shouldn’t be too much of a drain on our existing resources.
This does already exist, but I am not sure how complete it is. A good next step would be to look through the existing directory endpoints and the endpoints that ClassicPress calls out to for WP.org plugins, and identify any differences/gaps.
4 Likes
You mean you sell websites or customize ClassicPress sites?
I also use cp for business - for my business thou
The clients don’t want to hear about it. “Are there plugins? No? Ok then why would I use it. I can’t hire a programmer for everything” is the Standard answer …
1 Like