View in #core on Slack
@Viktor: Anyone around for the meeting?
If I’m not mistaken, the items on today’s agenda are:
- Notice widget in 1.6.0
- Media JS branch
@Matt_Robinson: In your order then - I have a Dashboard widget working locally and perhaps ready for a PR to be made.
It displayed a notice warning about PHP deprecation and v1 of ClassicPress being in security maintenance mode only until Nov 2023 when PHP support for 8.0 ends.
It displays 4 different levels of message (hopefully) depending on whether the user seeing it can update core or not, and whether version 2.0.0 is released using the get_core_updates() function in core that stores update information in a database transient.
If it helps I can drop some screen grabs, or shall I just create the PR based on the individual feedback received so far?
@Viktor: Probably PR is best, so we can test.
@Simone_Fioravanti: I’m ok with the PR.
@Matt_Robinson: Working on the PR now.
https://github.com/ClassicPress/ClassicPress/pull/1244
PR is here
@Viktor: Great job. I’ll provide some suggestions to the text. I think we should link to the testing blog post, so they know they can test 2.0 now if they want to.
@Matt_Robinson: I did have a look for the testing link, happy to add it. Shall we review that next week after a period for review and change?
Okay, to the Media JS then…
@Simone_Fioravanti: About PHP deprecation?
@Matt_Robinson: @Simone_Fioravanti - do you want to suggest additional content to the dashboard notice?
@Simone_Fioravanti: Can’t do a good wording job, but we have to say that CP 1.6 deprecates PHP < 7.4.
@Viktor: If we want to add that, I can provide wording.
@Simone_Fioravanti: > When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
From SemVer.
Can also be somwhere else, but we have to do this.
@Matt_Robinson: Wording needs care, CP 1.6 will stall work down to PHP 5.6.x, but I see the point, as PHP < 8.0 won’t be supported from November we need to warn that from V2 we won’t support PHP less than 7.4 - is that about right?
@ElisabettaC77: This means deprecation notice in 1.6 and deprecation in 2?
@Simone_Fioravanti: Deprecation in 1.6 and removal from 2.0.
@ElisabettaC77: Ok. For deprecation you mean the notice…
@Simone_Fioravanti: Yes, right. Before removing support in v2 we have to deprecate it in a minor.
@Viktor: Once 2.0 is out, I will make necessary changes to Requirements page. But we should add this notice to the dashboard widget to warn users in 1.6.0
@Matt_Robinson: It is kind of implicit in the major release version bump but I still agree that we need to warn users.
@ElisabettaC77: So I agree we should have wording, in a way that is evident. Not everybody reads docs but they have a site and see dashboard
@Viktor: Won’t hurt to have a short blog post about it too.
@Simone_Fioravanti: Agree that it’s implicit, but SemVer asks to do that.
@Matt_Robinson: Okay, so we can review the wording on the PR over the next week then.
Media JS now?
So, it became apparent that the Media library browser used in core in multiple places was not working too well - in part due to changes having been made in the PHP refork but not matched in the Media JS files.
When CP was originally forked, webpack was replaced but a different method of creating the Media JS production files. I considered reverting to webpack so sticking with the current process.
A manual diff of the Media files was actually pretty clean and quick and seems to be working. Some changes I made initially in the hopes of an easy fix I have very recently reverted so it still needs a good shake of the tree, but is keeps our repository fairly clean and the build process can remain the same.
As picked up earlier I think we need to commit Clipboard JS are a core file for easier testing to avoid 500 Server Errors when resizing images and probably more.
@Viktor: I have not seeing any errors resizing images using media-template branch, while clipboard and X were fixed.
@Simone_Fioravanti: I’ve done some tests and for now everything seems working.
@Matt_Robinson: Looking on the GH repository all the vendor js files are present so was probably a local glitch then.
Shall I create the PR then and we can get a bit more testing done?
https://github.com/ClassicPress/ClassicPress-v2/pull/135
@Viktor: Would it make sense to merge and let people test? Since we’ve already done basic testing to make sure it works and doesn’t cause any major problems.
Only a handful of us know how to test PRs.
@Matt_Robinson: It’s a big PR so worth an eyeball review and rapid test by us first I think.
I’ve requested reviews on the PR, from @Viktor or @Simone_Fioravanti, once either of you are happy we can merge and it’ll go into the next nightly.
Okay, is that all for today?
@Viktor: That’s it from me.
@Simone_Fioravanti: Nothing to add.
@Matt_Robinson: One thing I must remember to do is make the PHP 8.1 tests not experimental, they are passing cleanly now as I recall.
And the API and nightly-builder PRs too! 
Maybe in the next week……