The Future of ClassicPress Discussion

This discussion will focus on the results of the poll and users’ feedback. It’s limited to core contributors (@Core_Committers) and will be kept private. Keeping this discussion on the forum, instead of Slack, ensures everyone can participate in the discussion without timezone limitations over the course of a few days/weeks.

The option to re-fork has 20 votes while continue-as-is has 18.

The goal of this discussion is to find a way forward.

ClassicPress can’t be WordPress without Gutenberg, but it also can’t be its own CMS with a small core team at this time. There are simply not enough developers to make progress without backporting code from WP to move away from WP.

An almost even split in the poll suggests the best option might be a hybrid one, find a compromise solution that will satisfy both sides.

With a small core team, we have to find ways to be more efficient, to get more done with less. The only way to do that is to leverage all the work that’s done by WP contributors. As the core team grows, we can always explore the possibility of splitting away from WP but at this point in time, it’s simply not feasible.

But, we’re also not going to be WordPress without Gutenberg. WordPress has shown a lack of care for the needs of the community more than once since Gutenberg was introduced. We have to make the right decisions for the ClassicPress community even if that means deviating from WordPress core at times.

We need to be our own community while leveraging WordPress core, we can’t let commercial interests controlling WordPress control ClassicPress.

For example, and this is my personal example, WEBP generation should be disabled by default.

The re-fork gives us an opportunity to do certain things differently and improve the processes.

  • For example, as suggested by Daniele, we can stop prefixing WordPress versions in docblocks @since with wp- and instead do that for CP versions.
  • Automate the replacement of static strings such as API endpoints in the code.
  • Automate the replacement of WordPress with ClassicPress.
  • Possibly automate replacement/rewriting of dockblocks as needed.
  • We also need to keep a list of any new changes that ClassicPress may introduce that deviate from WordPress core.
  • If I’m not mistaken, code_potent rewrote installation screen/steps, unless there’s something specific for CP, we can probably let that go and keep WP’s code.

These are items off the top of my head, there are more so please share what you know.

In addition, we need to figure out what changes were introduced by ClassicPress in v1.x that we would like to keep in the re-forked version.

  • Security page, post ID column, and customizing login page banner can be left out.
  • Privacy-oriented changes should be kept (anonymizing data CP sends to APIs).
  • All API endpoints must use ClassicPress APIs as in v1.x.
  • Documentation URLs should point to ClassicPress documentation if available.
  • News widget should be kept.
  • Petitions widget needs to be rewritten to use GitHub data, so for now it can be left out.

Next, coding standards and tests. Alvaro mentioned his fork uses WPCS and tests, and everything is working. We need to review WPCS and see if we want to stick with it or continue with our custom WPCS rules, which may need additional changes. This also applies to tests, when we introduce certain changes WP tests may need to be changed so they can pass.

The big question is, how do we proceed with the fork?

  • Alvaro’s fork WP-CMS can be a good start, it removes Gutenberg code and is up-to-date.
  • Matt has done some work forking WP’s develop branch, changing over 200 files, to see how hard it can be. He can talk about that more.

This also begs the question, who is willing to put in the time/work to help move ClassicPress forward and succeed?

2023 will be a great year for ClassicPress with your help! :tada:

5 Likes

Notification for core contributors to discuss the future of ClassicPress.
@MattyRob
@Simone
@timkaye
@joyously
@wadestriebel
@alvarofranz
@Mte90
@omukiguy
@williampatton

If I missed someone, please let me know.

1 Like

My two cents, after being on the sidelines for a while now I am happy to start helping where I can again. I can’t speak to re-forking and how much work it would be, my skills in WP and CP are real rusty now as 100% of my time is now in Laravel.

I will leave the re-fork decision to the rest of the tagged people here but will be happy to help with automation, and continue to help with accounting and forum management, and anywhere else that seems to fit well with my skills :slight_smile:

3 Likes

Like Wade, I am happy to leave the decision about whether to re-fork to the people who will be making the releases happen. I just ask that, whichever option is chosen, the process for adding changesets and making releases be documented in one place so that anyone new who’s interested and capable can join in easily.

2 Likes

Looking at the backport authors I’m also to let who contributed most decide the way.
Also waiting to read Matt about his proof of concept fork.
I’m quite happy with what ClassicPress is now, but in both cases I’ll support the project as much as I can.

3 Likes

Speaking with the kind of sites I run in mind, so other can have different needs.
If I have to build a site with many WP plugins and a pro theme like Avada… I go with WP.

The main point is that I don’t know if WP 6.1 without GB can still use those plugins or themes without errors.

This is the option we’re discussing.

1 Like

As soon as a block-related function is called, it will cause an error. Those functions may be shimmed… or better, “we” can make those products support the fork by conditioning their product to blocks being defined. That is a feasible option as long as the rest of Core stays relatively close to WP (meaning, PHP, dependencies, main core features…). I mean, open issues on their github repos and customer support, asking for this.

With updated code base this can be more effective now. With 4.9 code base it’s usually a no from them.

1 Like

Also, if you read recent threads, you find out that the community expects plugin compatibility with WordPress… another reason for the re-fork option.

We’re not discussing IF we should re-fork, we’re discussing HOW to re-fork in the best possible way:

1 Like

I think the poll and thread so far are interesting.

It seems clear that the CP community really like CP, but really have very little understanding of the work involved in some of the features suggestions / requests that are made - comments like “make CP PHP 8.1 compatible” are all well and good but the aspiration of that change and the work involved are not in the same conversation.

As Viktor has said, I took WordPress develop and am doing a manual compare to current CP develop. It a tedious and laborious challenge. I’m about 200 files in and have suspected further work while we discuss the subject. There are around 1400 files (PHP, CSS and JS) in src alone so reworking is no small task.

That said, the benefits of fast-forwarding may well help us play catch up to WordPress to take advantage of:

  • Improved efficiency
  • Improved code readability
  • PHP compatibility
  • Bug fixes
  • More up to date plugin and theme compatibility - hopefully such code will check if 'blocks` are available bit we cannot do much to protect again poor plugin / theme code.
  • Possibly easier future back-porting

It would be my suggestion that we review things we have added to CP that differentiate us from WordPress and see what we keep and what we could drop. The Security page didn’t ever gain traction for example so for me that can go. I like the the custom login logo for the Login page, however it is possible to do the same, albeit with a little more code / effort in WP so should that stay? Some of these changes could maybe be considered more plugin territory.

For me, the main changes we need to keep are the branding - so user screens showing ClassicPress rather than WordPress and the privacy changes to the API calls. Maybe there are other things too nothing is springing to mind right now.

4 Likes

I like the custom login logo, it’s something we can keep.
And of course agree with branding and API privacy.

What do you think about the build process and the requirement for docker? Is it something we can remove, is it something hard to remove or is it something we absolutely want to keep?

2 Likes

We don’t currently use Docker, and I’m not sure we should start either. I believe that the WordPress approach is to create and publish their own variety of Docker packages. We don’t have the team to do that unless I’m not understanding it correctly.

1 Like

I think Simone is referring to Alvaro’s WP-CMS build process, which uses Docker.

Branding changes, CSS, I can help with that. That’s relatively easy.

What about the backporting process? Do we use the same scripts or Alvaro mentioned his cherrypicking process?

For the login image feature, what if we introduced a filter to make it easier to work with? So a plugin could provide actual functionality, but the core changes would be minimal.

About Docker, it’s in wp-cms and wordpress-develop.

You will also need Docker installed and running on your computer.

What I don’t like (but it’s not a problem) is that now you can just fork ClassicPress, point web root to src/ and everything works well. This is no more possible with WordPress. But don’t know if we can get rid of that. My opinion is that the more tools needed the less people will be enticed to contribute.

Our backport script is a (pretty complex) wrapper for git cherry-pick.

1 Like

I’ll point out some extra potential issues, just to help out with the decision:

In addition to Docker, there are a lot of npm packages that started being specific for Gutenberg. I removed some of those dependencies from package.json, but still, some of those that started being Gutenberg specific, may end up being used for other areas in Core (the admin area).

The problem is, those are not independent open source packages, it’s a WordPress project…

See the full list here: https://www.npmjs.com/org/wordpress

I say this is a problem because eventually, the admin area may require some js that is specific to Gutenberg but then used by other non-gutenberg components. Maybe a datepicker or whatever JS utility.

In that sense, it should be a priority to stop depending on those packages as soon as possible, and pay special attention to how the admin area evolves for WordPress in terms of Javascript (eventually, the whole blocks thing will definitely take over the entire admin area).

Also, I agree with the idea that requiring Docker is a pain point. But… any serious developer should be familiarized with it, and in the end, you only need to have it installed, since the provided scripts handle everything on their own. Just need to run an npm command to have everything setup.

Also, cherrypicking gets harder the more changes are introduced! so… the more branding changes and custom stuff that gets into CP, the harder it will be to stay uptodate.

3 Likes

Would it make sense to have a “vanilla” branch of WordPress without Gutenberg, which we would use to apply backports and then have our “develop” branch which would have all the CP changes and the backports to this branch would be applied from “vanilla” branch instead?

A lot of things that I think it’s the case to moving to specific threads to not just confuse it, so there is my proposal.

Tasks list

  1. List of custom features of CP like custom logo screen, so we can see if we can keep those stuff and so on
  2. What stuffs to remove from WP for GB, from rest endpoints of blocks to JS stuff and stuff to be able to disable
  3. WordPress support
  4. What fork we want to use and why (Automation for patches)
  5. Docker or VVV

Let me discuss the various points (get ready a lot of words :rofl:).

Notes

  1. With the list of features and where is that code, we can evaluate if keep it or remove it. Probably to speed up is better to start from the list already done by @viktor. Honestly, I never used any of those new stuff, so I have no idea.
  2. This can be moved in two discussions too, like stuff we want to remove and stuff we want the user can be able to disable like for webp (with a filter or an option).
    About the JS stuff the npm packages they are parts of builds for other plugins, I mean they are not enqueued in the page, but they are part of the react package build. So in my opinion they can be removed from WP. As GB/WP updates so frequently, every plugin builds their versions to avoid conflicts as JS is easy to break (this helps us in this work).
    About the new options like webp, I think we have 3 solutions:
  • filters
  • create a new setting page with checkbox (and we have to maintain etc)
  • create option meta keys without a settings page something that wordpress already does but not a lot of people knows (there is also in CP), https://your-domain/wp-admin/options.php
  1. In my opinion, we don’t have to ask plugin developers to add CP support. Our marketshare is not so strong for them to evaluate it or invest time and money. I am a plugin developer to that sell them and if someone asks me I say No. Not because of the old codebase (I mean not just that) but because for me, it is another thing to test it and keep that support. So as I don’t have any list of plugins that doesn’t work and why they don’t with CP I cannot say anything. Probably have a list of those cases can help us to study and find a solution as for me CP should work out of the box for them, so we can be a real LTS but also a real experience with the new editor.
    Another solution can be a plugin that enabled will renable some things for GB, like the plugins to disable GB for WP, we have a plugin that renable some stuff to keep compatibility, but this will mean that we offer the new options and other things etc.
  2. I have no opinion about the fork to use, I contribute to WP with patches every year, so I know that is a huge mess. I think that before to talk about the fork we need to find a way that for us is easy to get wordpress 7.3.2 (an example) and with a command to generate classicpress 7.3.2.
    This opens few things, like a test system (we can use the one by WP with some changes there too), keep a list of our patches/tools that adds new things and remove other stuff.
    We need to be autonomous because as @alvarofranz wrote if stops working on his own fork we are like again in the same issue.
    Looking on how to do the fork I am looking to the experience not of LibreOffice that is a different whole project compared to OpenOffice but on how Debian and other linux distributions do their package versions.
    For who doesn’t know, they have their git repository and a set of diff that gets merged when they want to generate the package to be installed. In this repository, there are their own files used for the process in specific folders so their package maintainers need to just update their git version with the distributions files needed for the package and execute the process to generate the package and see what is getting broken (also after installing it and executing it).
    In this way they have a lot of people that keep a hundred packages with fewer troubles also with their own patches. In our case it’s not so simple but is something that we can get inspiration to find our why to keep also the codebase CP based (not a git copy of the WP repository but already changed).
  3. I am one of the maintainer of VVV that is the official solution to contribute to WP also if now it is used more docker. Years ago I did the template to contribute to the CP core with VVV GitHub - ClassicPress/classicpress-template-develop: Contribute to ClassicPress Core development with VVV.
    For who doesn’t know is a solution with Vagrant where you can have multiple websites in the same machine with a lot of settings for backup etc https://varyingvagrantvagrants.org/ I am also one of the contributor to the WP documentation on how to do a patch…

Next step

I think that we agree on many of those points/tasks (we need to see the details) and to move on we need for any task someone that want to focus on that.
Before to say X works on 1 etc (I have any authority for this) I think that we need to define some priorities and I ordered those tasks in that way.
So maybe the next move is to create a thread for the first step and work on this all together, when we defined move to the next one, so we can work on that based on our availability and not go on burnout because are too many things. In this way we can see if there are people interested also outside us and give an idea to the rest of the world how we are organizing the CP future. In this way, we can also be more tempting.
Developers like roadmap and when they are organized with tasks and everything is public and clear (not hidden like in WP).
The only things we have to do is to keep the participation in those tasks limited as we can have fanboys or other people we saw in the other discussion that have no clue of WP knows and aren’t developer but keep everything public (2 threads one just for “us” and one opened to everyone to participate).

PS: after all of this if starts in this way or similar, I think that I can find time to contribute CP again. I am wondering it is still the case to use Slack or to move Discord, but it is something for another discussion. I put too many things in a single reply :slight_smile:

3 Likes

Great points Daniele. I think if we break out into separate discussions, more specific to getting work done, it might be best to create them as issues in GitHub that we can use to track the work and do assignments. But the forum can work too if everyone prefers it.