View in #core on Slack
@Matt_Robinson: Who is available for a PR meeting?
@Viktor: I’m around.
Is 1.5.1 on the agenda today?
@Matt_Robinson: That was my plan. 1.5.0 contains a few bugs and we have some PRs with fixes.
I have tested this locally and it resolves the issue for me - origianl report had some issues editing files I suspect, awaiting follow up from them at the moment.
@Viktor: Hopefully he’ll reply. But I would ping him for an update.
The change itself seems simple enough.
@Matt_Robinson: I’ll leave PR for now then and add a comment pinging the reporter.
@Viktor: Change is simple, looks good.
@Matt_Robinson: I’ll merge then. Do I need to change anything with the merge message for the planned automated release note generation?
@Viktor: We haven’t done anything for that, so at this point it doesn’t really matter. I think when we start work on v2, that’s when we can structure commit messages correctly.
@Matt_Robinson: And the last PR pending for 1.5.1 at the moment is this:
A polyfill that is apparently needed for PHP 5.6.x (and the PR also includes polyfills affecting earlier version of PHP 7.x
It’s hard work testing but I have an existing install and have also performed a new install while using PHP 5.6.40 and it worked for me.
Propose we merge for wider testing.
@Viktor: It looks good, I’m not sure how wider the testing on 5.6 will be. Since CP was broken for 5.6 and we didn’t know, it’s likely nobody uses it. Which is good. Have we checked the code with PHPCS version compatibility checks just to be sure?
I complete forgot about readme update: https://github.com/ClassicPress/ClassicPress/issues/1210 I will try to get it done today.
It seems there has been a review - this PR certainly fixes one such issue.
@Viktor: OK, great. At least we cover our bases.
@Matt_Robinson: Looking at the
Throwable interface, it seems it cannot be polyfilled and it seems it would silently fail on PHP 5.6 as the code stands according to this:
Silent failure isn’t ideal but it’s better than throwing loads of errors.
@Viktor: Is that how WP handles it?
@Matt_Robinson: The usage is actually in SimplePie, WP use the same file as us, but they don’t state support for PHP 5.6 now do they?
WP has a requirement for PHP 7.4 and greater, we need to maintain support as best we can for PHP 5.6 due to semver - dropping support is a breaking change.
Re-forking and v2 will also us to fast-forward to PHP 7.4 up.
@Viktor: They do say it’s supported: “Note: If you are in a legacy environment where you only have older PHP or MySQL versions, WordPress also works with PHP 5.6.20+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities.”
@Matt_Robinson: Ah, I missed that - so CP is matching WP.
Are you in agreement that we can merge #1212?
That just leaves #1207 and we can then make a short cycle release of 1.5.1 unless anything else shows up in the next week.
@Viktor: Yes, 1212 is good.
@Matt_Robinson: Great. In terms of moving forwards, I’ve re-started work on updating core CP files based on WP 6.1.1.
I think we need to discuss a strategy and see if we can share the workload.
@Viktor: So you’re working directly with wp-develop, not wp-cms?
@Matt_Robinson: I’m working with a local zip of WP 6.1.1
I tried wp-cms and tried merging it is using git - it created conflicts in every file so no cleaner than what I’m already doing.
@Viktor: So if you’re merging with CP core, that means we have to remove CP features still? Or it would overide those files?
@Matt_Robinson: No, I’m basically manually
diff ’ing the file keeping all of the CP made changes.
It should preserve all CP changes and update everything else - provided I don’t mess up. It’s a lot of files though.
@Viktor: You don’t think it would be less time-consuming if we took WP-CMS as the base and simply added everything we need to it to make it into CP v2.0? Reviewing diffs is time-consuming for sure and poses the risk of hidden bugs.
@Álvaro_Franz: There also are a lot of files that moved from one place to another, and maaaany many other changes. I think the other way around is easier. But hey, you are the one doing the work so of course you decide how to go about it. I am keeping WP-CMS updated still.
And as I told Viktor, I can keep it updated so you don’t need to compare with wordpress-develop. I can do that work, and you take it from WP-CMS into CP.
I’m still thinking if I want to keep working on that project or not, but while I build myself an answer, I’ll keep doing it. It’s easy.
@ElisabettaC77: Seems more logic to take WP strip it of the unwanted and add CP stuff to it. If Alvaro’s fork is already stripped and stays current it make sense to try and add CP stuff to it instead of adding it to CP?
@Matt_Robinson: WP-CMS has js files in the same different locations as WordPress so that impacts on the build process we have. I’m not sure if that impacts on the release scripts.
@Álvaro_Franz: And just noting, I already put a lot of hours into that, and overcame a lot of obstacles.
@Matt_Robinson: WP-CMS was a great job, but when I’ve investigate it seems about as different to ClassicPress as WordPress is. Unless I am missing something (and that very well may be the case) WP-CMS as a base from GH is not any easier that WordPress.
Maybe I should checkout a build of WP-CMS…
I’ll ponder and maybe have a look, but anyone else is also welcome to have a look at which route might prove the easiest - everything I’ve tried so far has not been straightforward.
@ElisabettaC77: I can understand it’s different, but isn’t it easier porting few cp things to it than porting a lot of things from it to CP?
@Álvaro_Franz: hmm… you are right, that they are both different. But the main point is that WP-CMS comes from a very fresh version of WordPress. And I think it’s logical to assume that it will be easier to pick the CP features and move them into that codebase.
Not compare the whole CP codebase… that would be crazy. Actually, look for those things that have to be kept, and move them into the fork.
@Viktor: @Álvaro_Franz do you think it’s possible to take WP-CMS codebase without Docker build process? I think that’s the main question.
@Matt_Robinson: Sorry folks, I have to dash. I’ll leave you to debate