The Future of ClassicPress Discussion

Projects Core Private
18

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
19

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?

20

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
21

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.

22

What is the full list please?

Custom login screen, “anonymous” API calls, an extra column in the posts table which shows the post ID, a security screen (which doesn’t do anything), … something else?

Users who NEED WordPress, should just stick to use WordPress. Period.

Only concern is, plugins like ACF… will they eventually stop working because they NEED block-related functions? We don’t know… but for a few fundamental plugins we can actually make some pressure and ask that they add some conditionals. It’s not going to work for most cases, but… at least maybe for the fundamental ones like ACF.

Docker is the standard today. Wasting time for the sake of using something else is… well, that, a waste of time. Docker works perfect, no need to hate on it. Plus… if it’s not Docker, it’s going to be something else which you also HAVE TO SETUP. It’s never going to just work magically, you always need a server, PHP, a database… so yeah, installing Docker is a no-brainer.

So, the point is:

  • Is it harder to now go and chase PHP 8.1?
  • Or is it harder to now go and fork WP-CMS and rebrand it into ClassicPress?

…

23

I’ve been doing some early work on looking at a re-fork. My feeling is we should maintain our current infrastructure - no need for creating Docker images or any alternative. Our src code runs fine on a local *AMP stack.

I have started the process once already and paused pending this discussion.

The issue for me is that there are enhancements and features currently in WordPress 6.1.1 that at worth considering, for example some changes we almost certainly don’t want:

  • Block Editor
  • JSON based Themes
  • Application Passwords
  • Textdomain registry

Some changes we probably should now adopt:

  • Sitemaps (can be disabled if desired)
  • Error recovery (helps keep sites functional trapping and bypassing errors)

One other small but possibly significant change would be in the documentation block, dropping the WP- prefix used in the @since markers for upstream code and instead marking our additions with @since CP-1.1.2 for example.

There are still a lot of files to update and review, as well as file and references to delete with this work. But if we can agree on a starting point at least we can create a branch and begin the work.

24

What’s the reason for not including application passwords? We’ve had petitions in the past asking for API auth.

And also textdomain registry?

The less features we remove, the easier it will be to backport stuff. We can also disable features by default, allowing users to enable it if needed.

Site Health is another feature to keep. I find it very helpful for debugging, at least the part where you can see current server resources, permissions, etc.

As a sidenote, I would like for us to adopt conventional commits for writing commit messages so we can try to automate release notes and changelogs. It would be ideal to start with the new branch. If our release process allows for this:

25

We can include Application Passwords if that is the consensus, again I suppose it can be disabled. My personal issue is opening another potential surface for infiltration, especially when it isn’t something I can envisage ever using. (But I can disable it).

I suppose the Textdomain registry is linked to API privacy issues and reliance on upstream translations that may not work 100% in ClassicPress - but again I have no major opposition to including it.

Site Health is a helpful addition - I agree with that.

Also, commit messages based on convention makes sense - we have always tried to make useful commit message with no more than 72 characters, further conventions could well prove helpful.

I do also wonder about the replacement of WordPress with ClassicPress in the core documentation blocks. Is that something we can leave (apart from file headers with the @package tag where we should probably keep it. Could the document website parser then be extended to replace WordPress with ClassicPress when parsing the documentation?

26

I don’t know what the solution is, but it would be nice to provide some form of API auth. Initial petition, probably before application passwords were introduced, did gather a lot of votes (60).

So it’s another API? I don’t think I’ve heard about this. I’ve only seen information in the code reference.

27

It may not be quite the same thing but REST-API can be blocked for anyone who is not logged in as follows:

add_action( 'rest_api_init', 'rest_redirect' );
function rest_redirect() {
	if ( ! is_user_logged_in() ) {
		wp_safe_redirect( home_url() );
		exit();
	}
}

And looking at the Text Domain Registry - perhaps it isn’t a new WordPress API, ticket is here:
https://core.trac.wordpress.org/ticket/39210

Perhaps something we should keep as it seems to fix a multilingual problem.

28

I would definitely like to see Application Passwords included. At present I use the plugin on which the core code is based.

This is the sort of thing that would be perfect for a core plugin. But it seems that (for a variety of reasons) we’re dropping that idea (or, at least, delaying it indefinitely).

1 Like
29

It sounds like text domain registry might be good.

I would say we should keep application passwords just up eliminate additional merge conflicts removing it would create. We can keep it as is or disable it by default, so it can be enabled with a filter or option.

I think focusing on blocks and JSON themes would be a good start. We can always decide to remove something later, which might be easier once blocks/JSON themes stuff is already gone.

And for the docblocks, whatever you think is the easiest option for us is good with me. The phpdoc-parser isn’t really working, I’m trying to figure out why.

30

Considering that reforking also mean deciding if a functionality is needed, this can be the right moment to add “switches” where possible.

if ($i_need_it) require_once 'feature.php'

For me using constants, filters, “hidden” options or even a new setting page it’s the same.

This way we can also avoid many discussions on each feature.

3 Likes
31

I think adding a switch should be based on the feature’s intended users.

  • Application passwords (developers) - use a filter to enable it. Can be left enabled. Plugins that may need it should be able to enable it, something similar to add_theme_support(). Enable it if plugin/theme declares support for it.
  • Automatic webp generation (users) - add a checkbox to enable it under Media settings.
  • Sitemaps should be left as is. They are important and with Classic SEO unmaintained at this time, that’s good to have.
  • Site health should be left as is.
  • Error recovery should be left as is.

Anything else we’re missing? We don’t have to decide every feature’s fate at this point. We may come up on a feature we want disabled or add a switch while working on the fork. At that time we can figure out what the best option is.

Since it’s a major version, I would recommend dropping official support for PHP 5.6. It may still work, but we shouldn’t waste our time chasing it. Any issues coming up with 5.6 will not be fixed.

Our primary focus should be the removal of blocks and JSON themes code. Any additional changes should be made after unnecessary code has been removed. Mixing things will cause problems debugging issues.

@MattyRob do you think we should proceed with your approach, applying changes one file at a time? Or should we take Alvaro’s WP-CMS, ensure blocks and JSON theme code is removed, and then begin applying any CP related stuff?

You’ll know better than me, but from my end, it seems that using WP-CMS as a starting point and making it into CP would be more efficient:

  • We don’t have to remove any CP features we’re not keeping, we just bring in what we want.
  • All the docblocks are already back to the original WP docblocks, so we can add CP stuff.
  • Blocks (and maybe JSON theme) code has already been removed, so we just need to check if anything else is left.

Is there anything I’m missing?

As a side question, should we drop composer.json? We are listed on Packagist, but I’m not sure if we have access to that account.

1 Like
32

I’ve been thinking about attracting more core contributors and this issue with Docker started to bother me a bit. Since WP uses Docker, wouldn’t it make sense to keep the process/tools as similar to WP as possible for anyone familiar with WP process to be able to contribute to CP?

For example, if a WP contributor decides they want to contribute to CP and they are familiar with WP process, it might make them re-think contributing to CP if they see the process is different and tools used are different.

This aligns with one of my other hopes for re-forking, an updated codebase might attract core contributors. So it only stands to reason the tooling might play a role here too.

Something to consider.

1 Like
33

I suspect any WP contributor will find it much easier to build and test on ClassicPress. Docker is used due to the complex build needed due to the Block Editor code.

Personally speaking, if Docker becomes a necessity for ClassicPress it is going to put me off developing for CP.

34

That makes more sense. Thanks.

Any thoughts on this? So we can try to move forward in some way:

35

So after further discussions today on Slack, I think we agreed on a tentative plan to proceed with re-fork.

  1. We will begin work in an experimental repository using WP-CMS codebase only.
  2. A separate repository will allow us to do the work without polluting main repository and history of v1.
  3. When v2 is considered ready we will branch v1 and drop v2 codebase into develop branch.
  4. When changes from v1 are brought in to v2, the commit should follow this structure:
  5. Next, we will need to come up with a list of features (and their PRs) to migrate to v2. This should be done as an issue in Github with checkbox tasks to keep track.
  6. We need to make a list of APIs that need to be updated.
  7. We need to make a list of branding changes that need to be done.
  8. We need to review the code and remove/update any WP-CMS specific code (for example, core update and translations have WP-CMS specific code)
  9. We need to make a list of new changes that we may want to implement. (Ex: disabling WEBP by default.)
  10. We need to review the core code/files for any remnants of block code. I saw at least one so far /wp-includes/theme.json.
  11. Once we break down the work into a manageable list, we will need your help to start! With a clear list of tasks to complete, I would like everyone interested in helping to claim the tasks they wish to complete. Even if you can only complete one task, that’s a lot of help and we will appreciate it!

We may find additional work that needs to be done as we begin forking.

A blog post announcement will be published for the general public once we get some feedback on this roadmap.

Anyone willing to help either leave your GitHub username here or private message me to be invited to the repository.

4 Likes
36

Since there haven’t been any additional comments on the tentative plan, the discussion can now be completed and will close in 3 days.

@Core_Committers interested in helping with v2.0 can join us on GitHub. The list of issues is beginning to grow and PRs are being submitted. If you don’t have time to submit PRs, help review them!

We welcome all the help we can get! Including writers to help write/rewrite documentation, translators helping with translations, and anyone else willing to help! Message on Slack in the #community channel, start a discussion on the forum, private message me, or join us on GitHub.

v2.0 repository:

v2.0 project to track progress:

Thanks to everyone who participated in the discussion:

@MattyRob
@Simone
@timkaye
@wadestriebel
@alvarofranz
@Mte90

2 Likes
37

This topic was automatically closed after 3 days. New replies are no longer allowed.