View in #core on Slack
@Matt_Robinson: Who is available for a PR meeting? @Viktor
@Álvaro_Franz: I’m in for the discussion of v2.
@Matt_Robinson: First up, 1.5.1 was release yesterday. We could consider updating the migration API now if we are happy with stability of the release.
https://github.com/ClassicPress/ClassicPress-APIs/pull/66
While there we can also test and allow migrations from WP 6.1.1 (after testing)
@Viktor: Sounds good. 1.5.1 seems solid.
@Matt_Robinson: Not issues hit the forum it seems.
@Simone_Fioravanti: For me good.
@Matt_Robinson: Okay, I’’’ merge that now, test migrating from 6.1.1 and then update the API in the next day or two.
I used a slightly amended release script that updated package-lock.json as well as package.json, seems to work fine:
https://github.com/ClassicPress/release-builder/pull/7
@Viktor: Did you see my note about ClassyBot account?
@Matt_Robinson: We could merge that too but there may be more to consider with the git-flow user and also the step that install grunt-cli could check for it first.
So, it it worth merging what we have an making a new PR for the other issues?
@Viktor: Sounds reasonable.
@Matt_Robinson: Great, I’ve a few things to sort there then - now the main event - v2!! 
We have an experimental repository thanks to @Viktor that currently just contains the src/ from WP-CMS.
There are a lot of open issues already detailing some of the work that needs to be done.
@Viktor: Before merging any of my PRs, @Álvaro_Franz mentioned that WP-CMS has had updates. main branch hasn’t had any merges, so it might be prudent to update the branch before starting merges. Some of my PRs might not be necessary as the changes already in WP-CMS.
@Álvaro_Franz: To specify, those changes are basically keeping up with WordPress and the removal of more block related code.
Highest priority should be, put the tests back into place so we can actually test stuff, and not blindly pushing code into the repository.
@Matt_Robinson: I’ve been playing a little and we also need to get QUnit and PHPUnit tests added and working locally, then automated.
There is also work around the JS locations and build processes.
And as things stand it seems WP-CMS is reliant on some WordPress pacakges - namely @wordpress/i18n and @wordpress/date
@Álvaro_Franz - can you comment here, are those packages needed in your testing and use of WP-CMS?
@Álvaro_Franz: I am not using those two packages for tests.
I am now working on a whitelist for plugins and themes that filters the WordPress results to only contain whitelisted results. I know there is a directory being created, but we can still benefit of having the native directory present if the whitelist works fine. Users will see their favorite WordPress plugins which are compatible with this new version as long as they don’t use blocks functions.
Said whitelisting already works, btw. For plugins and themes. I need to push it to the repo once I remove the popular and featured tabs.
@Simone_Fioravanti: Do we have track of removed functions?
@Álvaro_Franz: No. It was a huge lot of functions. All blocks related.
I also adapted tests, all are passing.
@Matt_Robinson: The WP packages are all still listed in the wp-cms package.json and will be pulled in a built into the distributed code as I understand the process:
https://github.com/wp-cms/wp-cms/blob/7a1124e6a17eb68f401310e85cfbf2d7d4554717/package.json
@Álvaro_Franz: Yes, JS is something I still need to clean up. Most npm packages are gutenberg related. If not all. That’s something I have to confirm.
@Matt_Robinson: In my local attempt at testing, and this needs checked and confirmed, but the date and i18n packages may now be required in the media scripts
@Álvaro_Franz: Yes that’s why I didn’t remove them. Also I’m afraid that some Gutenberg packages will be extended into other non Gutenberg areas of WordPress in the future.
What I still don’t understand is… what’s the problem with using the tools that exist now? Docker, npm, …?
@Matt_Robinson: I suspect you are correct, so the question here is to we rely on those packages, or find another way?
@benlumia007: not everyone like docker
that’s my main guess 
@Álvaro_Franz: I would rely on the packages that make sense. Those that are general and useful.
Not liking it is a good point. Now… go build the whole automated process with alternative tools… try it.
@Viktor: It will only get worse with time and Gutenberg. They had a post about it recently.
@benlumia007: i don’t complain cuz im using docker and build my entire LEMP stack automation
@Álvaro_Franz: @Viktor They are breaking down Gutenberg into multiple packages, that’s good. It keeps things manageable. I don’t see it a bad thing.
We use what we need we don’t what we don’t.
@Matt_Robinson: There is no issue at all with npm - ClassicPress already uses it.
WordPress moved to Docker as there is a certain level of building needed to run a localhost from the source code.
We already have a build and release process that works from the ClassicPress code, which can run locally without any build steps.
If we move to using Gutenberg packages we may well need Docker - and I don’t know enough about it to get that all working.
It may also require an overall of the existing release builder scripts.
@Álvaro_Franz: @Matt_Robinson You don’t need to know anything about Docker. I know very little. The release script is already written and maintained.
@benlumia007: Docker is pretty much an easy tool to use… no ned to configure anything jsut run the script and docker up
@Álvaro_Franz: If v2 is going to be refork, I wouldn’t even question that, and move on.
It’s modern standard tools, first time in WordPress history.
@Matt_Robinson: You are both missing a major point here - using Docker is simple - setting up a repository where all the configuration files exist and work is not - who is going to check over those files and make sure we have what CP needs?
@Simone_Fioravanti: I’m for having CP continue to run without build steps.
@Viktor: We have to stick with the resources we have available.
@Álvaro_Franz: The repository contains all the Github actions too…
What else does CP need?
@benlumia007: that was my question too?
@Matt_Robinson: Github actions on wp-cms is missing JS tests, PHP compatibility and coding standards.
@Álvaro_Franz: It is now, it wasn’t last week. Those files exist in the original repository, and just require to set them up.
I am locally testing for now that’s why I removed them.
It uses online open source code, all there needs to be set up is the secret keys for each thing
But, if we can find an easy way to not use Docker… fine. But that will require a setup too.
Using what already exists is easier.
@Matt_Robinson: With ClassicPress you can use Docker, and any other local AMP stack. With WordPress Docker, env, npm and lots of build and watch scripts exist and are maintained to support the development environment. Docker isn’t compulsory with WP - as you say it’s just easy. Again, the issue is not really with Docker, it’s with the build steps needed for WordPress that ClassicPress does not need, and without reliance on GB packages etc, it won’t ever need.
@Álvaro_Franz: Good. But what to use instead?
I don’t care about that, at all. It’s just ready.
No need to waste time redoing something that works fine.
I can give you a fresh build and you set it up the way you want into a new CP v2 experimental repo.
And we go from there.
Everything else is just fuss…
@Simone_Fioravanti: Most of my work is done on live sites, with docker this can’t be done.
@Viktor: Update src in the main branch before PR merges is a good next step. I can clean up PRs after.
@Matt_Robinson: If someone coming into development and want to just make a few changes here and there it’s all easy. We are talking about maintaining a complete development environment for or core developers and any future. Whatever we adopt has to be maintained.
If you give me a build that does help ClassicPress as we need to make the build from our fork - we need the build steps - that is where the development environment is coming in.
@Viktor: Just because we can get a free tank doesn’t mean we know how to use it or have anyone to maintain it 
One thing I’ve learned with Docker, it’s easy to use until its not. And you spend a day Googling how to fix something on Windows
@benlumia007: i feel like this conversation is pointless at this point. if a complete development environment should be a set a tools that can be use with any kind of environment.
WP uses docker, is what the developers uses and they force other people to use it if they want to contribute
u don’t wanna force people to use somethign they don’t like
@Matt_Robinson: This is something James used to say a lot when he was around - it’s all fine using something, but to develop and maintain it you need a deep understanding of what it is doing. The scripts that run through the WordPress code for Docker are in multiple locations - exactly the same as the build and minify steps for the javascript files. If we are going to adopt them, someone needs to have a deep understanding of it all.
@Viktor: Getting Docker env to work with CP by people who don’t know how to use it well will end up costing us a lot of time, time that can be spent on adopting CP tools to v2.
@Álvaro_Franz: Next step would be to adopt CP tools into v2 then.
How?
What needs to be done I mean.
So we can start acting towards it.
@Matt_Robinson: I have started dropping in the CP tools with updated Unit and QUnit tests, but I have lots of failing tests now, QUnit may be due to needing upstream packages - really not sure at this point, And PHPUnit is working but failing over 100 tests.
I could push a PR for other eyes to see if I doing something stupid (quite possible)
@Viktor: I think that will be good. More eyeballs is good.
Maybe creating an issue with a list of tools we need ported to v2 would be a good place to keep track of these?
@Matt_Robinson: I can check on my branch before I open a PR but I think I have pretty much everything.
@Álvaro_Franz: For me, If I am going to put time into this, I prefer to just understand what is already there. But cool, it’s clear that is the next step into v2 (the env and automated processes). What else?
Understanding more about those npm packages.
What else?
Did anyone test wp-cms per se and find other problems I can work on?
@Viktor: As I find issues, I create issues in Github and let you know.
@Matt_Robinson: From the wp-cms we need to know a lot more about all of the “@packages” and what can be dropped.
Avoiding the Javascript build processes would be great if that is possible.
And with that in the script-loader.php file there are specific functions that local things like react and all the GB stuff, we need to decide what to do with those.
@Álvaro_Franz: Okay, @Viktor I will send you a fresh build to update the src in the repo, cool?
@Matt_Robinson I am going to look into those npm packs in depth now.
@Viktor: Yes, pelase.
@Álvaro_Franz: @Matt_Robinson I agree with your point. It’s more freedom for the devs to use traditional more simple tools. I just don’t want to waste time with that. But I agree it’s a valid point.
@Viktor: Also, I think I got all the v1 features that need to be ported as issues in the repo. If anything else is missing, let me know or open an issue.
@Simone_Fioravanti: I have not seen the Require CP header addition but can be wrong.
Oh sorry!
@Viktor: So the next steps:
• Alvaro will send me updated files and review packages
• Matt will create a PR with tests and tools
• I will update main branch and check my PRs in case some of them are not necessary anymore
Anything else?
@Matt_Robinson: In my tests and tools PR I’ve removed the minified files, I think we already have a PR for that so shall I reverse that?
Other than that the list is pretty much what we’ve discussed today.
@Álvaro_Franz: Sounds good Viktor. i am now looking into npm. Will try to remove the dependency on those before sending you the fresh build.
@Viktor: Productive meeting everybody! We got our work cut out for us but we have a path forward.