View in #core on Slack
@James_Nylen: !channel letās have a core development meeting. Iāll wait a couple more minutes to see whoās here.
@Joy_Reynolds: 
@Michelle_Coe: 
(observing)
@Simon_P: cough (@ here - not @ channel) if pos 
much love and thanks
@MattyRob: 
@James_Nylen: we use @ channel infrequently to announce and start meetings. seems like a decent use of it to me but will talk it over with some ppl here.
https://forums.classicpress.net/t/classicpress-release-plan-version-1-2-0/2123
ā¢ Full compatibility with PHP 7.4.
ā¢ Allow setting a custom image on the login screen. This will implement a relevant petition 5. This was planned to be included in version 1.1.0 but was rolled back due to some issues discovered in the rc1 release.
ā¢ Other small changes and bugfixes that generally do not warrant a new release by themselves. The current list is available on GitHub.
This is still the plan for v1.2.0. The largest change this release has been the custom login image, which Iām now putting through another iteration.
You can see the progress on that here, at least how I think the UI should look: https://github.com/ClassicPress/ClassicPress/pull/601
There are a number of other open PRs which I will be looking through to see what should go into v1.2.0. https://github.com/ClassicPress/ClassicPress/pull/594 is another one Iād like to include, to allow updating plugins and themes from zip files.
@fwolf: is watching from the sidelines
@James_Nylen: If there are any other issues that are affecting your sites then please help test the fixes and let us know. Otherwise probably not all of the PRs that are currently open will make it into this release.
Questions/suggestions/complaints about any of the above? Iāll wait a couple minutes to give folks time to digest.
@Joy_Reynolds: The custom logo PR build failed?
@James_Nylen: It did. Havenāt looked at why yet, but that change is not finished anyway.
@Laurence: Seems good for the minor release.
Does this have to go through the committee since some extra things have been added in comparison to earlier plan?
@ElisabettaC77: How can I test the logo thingy? I have a possible need for it so makes sense. I already have a staging site with the site I need it on half builtā¦
Never tested for open source. So need to know if there is a tutorial
@James_Nylen: > Other small changes and bugfixes that generally do not warrant a new release by themselves.
Everything that is new in v1.2.0 would fall under this, except for the change to allow upgrading plugins and themes from zip files.
Since the committee has not met since January (if I recall correctly), I am not sure how to handle this. I now think it was a mistake to require committee approval for release plans. Open to suggestions.
@Wade_Striebel: I agree that committee signing off on releases doesnāt really make much sense
@Tim_Kaye: I agree too.
@Michelle_Coe: I also agreeā¦
@James_Nylen: @ElisabettaC77 basically you need to clone ClassicPress from git and checkout the branch youāre interested in. Or wait for a build - Iāll do a preliminary build when the PR is working, and then there will be a 1.2.0-rc1 release with the changes.
@Laurence: For major releases I think it makes sense to a certain levelā¦
@James_Nylen: It would make sense for major releases if the committee were actually meeting.
@ElisabettaC77: I think it makes sense for very big things. But the above does not fall under very big.
@Wade_Striebel: I mean, for example, as Community Team lead, should I be able to vote against a release that I havenāt had much to do with?
I think the Core team should just make those decisions
@James_Nylen: I think yes actually. Iād like to know if Iām making decisions that might not be in the best interest of the community.
That was the original intent of having the committee involved, but I donāt think thatās the right mechanism.
Something like me posting the plan for each release on the forums for all to comment would work better, I think.
Alright, so Iām thinking we can put a committee vote on the forums to rollback that rule.
@Laurence: For now, since the decision is binding, minutes of this meeting will be shared. Committee can make a decision on release plan adjustments and a new take on that proposal above can be considered.
@James_Nylen: At this moment the target audience for the custom login image PR and the rest of the 1.2.0 changes is people who have a development install set up. If you are interested in contributing to ClassicPress I would highly recommend doing this.
Basic steps are as follows:
ā¢ git clone the ClassicPress repository
ā¢ create a database and a working wp-config.php that points to that database under src/wp-config.php
ā¢ point your webserver at the src directory
Unlike recent versions of WordPress, ClassicPress does not require any build steps to develop this way.
If someone wants to submit a PR to document this process, ideally based on their own experiences setting it up, then that could go at https://docs.classicpress.net/developing-classicpress/ or https://github.com/ClassicPress/ClassicPress/blob/2f660154991ca29075ee814e448383f836eeb4dc/.github/CONTRIBUTING.md.
Another thing weāll need for the v1.2.0 release is a documentation page specific to the new ācustom login imageā option, including the different modes (square logo vs wide banner) and when to use each one.
Before ābanner modeā: https://forums-cdn.classicpress.net/file/classicpress-forum/original/2X/d/dc2f6eeb96268a1a2d841531dad8129d43a04892.jpeg
471x652px image
After: https://forums-cdn.classicpress.net/file/classicpress-forum/original/2X/4/4941f4856f60bb3355eb36182630cdcaed26b921.jpeg
466x668px image
@Laurence: Banner might be misleading a term. Maybe use wide and square fit logo?
@Joy_Reynolds: Looks like your PR documents it, along with these screenshotsā¦
@ElisabettaC77: I will try the above in about half an hour and will write a post about the process on forums so if itās ok it can be moved to the docs
@James_Nylen: perfect @ElisabettaC77
@Joy_Reynolds: So, minor releases are whenever WP has a security release, or when we accumulate enough small fixes?
And then major releases have their own roadmap?
@James_Nylen: WP security releases can be patch releases
semver is major.minor.patch
@Joy_Reynolds: Oh yeah, three parts to a version numberā¦
@James_Nylen: otherwise yes
āBannerā is still the word I would use here, along with a link out to the documentation page to explain exactly what that is, with examples. Any other opinions on that?
[August 6th, 2020 11:58 AM] laurence: Banner might be misleading a term. Maybe use wide and square fit logo?
@Joy_Reynolds: If my logo is wide and tall, which would I use?
@James_Nylen: try both, I guess 
@MattyRob: A different logo 
@James_Nylen: or āa square is wide and tallā
@Joy_Reynolds: I just wondered, because in my theme, I donāt specify any sizes, so the user can use whatever they want. It seems like this would be the same.
@James_Nylen: currently the code will use the full image size for whatever image is chosen. I think this + explaining when each option should be used is a reasonable default.
@Joy_Reynolds: So, are you still on beta or RC?
@James_Nylen: neither one yet
some changes are on the develop branch and some other ones are in PRs
@fwolf: fullwidth, wide-screen ā¦
@Joy_Reynolds: I think the option is simply replacing the existing image, not redoing the whole page.
Is the jQuery upgrade part of the v2 roadmap?
@James_Nylen: the jQuery upgrade would be its own major version since it is a breaking change by itself, and in order for that to happen we need someone competent to see it through, and community interest and testing
I do not plan to take that change on myself but I can advise/guide/review when someone else does
@Joy_Reynolds: The first step (as recommended by the jQuery team) is to remove the jquery-migrate script.
@William_Patton: 
It is a 2 step process - remove migrate and break a bunch of stuff. Then update a break more stuff 
Also hi all!
@James_Nylen: Hi William, long time no see!
@William_Patton: I see that planning and prep for your next LTS release is underway so Iāll just watch and listen in.
But the jQuery change is a big one so probably not an LTS thing
@James_Nylen: yes, exactly
but that is as good a segue as any into future releases
in a future 1.x release we will need to add a system to notify sites to upgrade their PHP version, like what WP has done
https://github.com/ClassicPress/ClassicPress/issues/438
a good next step that anyone can take on there is to find the first WP ticket/commit that introduced their version, and then find all the commits that modified it after that
we should be able to backport those in one go and then modify to use our API servers etc
@Laurence: WP take is intertwined with servehappy and site health if I am getting the terms right. Maybe a discussion on the plan for that could go to the issue highlighted on GH.
@James_Nylen: servehappy is the name of their initiative for that (if I remember correctly)
sounds like we need to take out the bits related to site health
@Joy_Reynolds: > find the first WP ticket/commit that introduced their version
not sure I follow this
@James_Nylen: what WP commit introduced their āupgrade PHPā notice
then there were a bunch of commits that changed/added things to that feature, we need those too
@William_Patton: Do you think cherry picking the commits is the best idea? I do think Laurence is right about it being heavily intertwined with other systems. It could be a better approach to find the module and then rewrite it for CP directly.
@MattyRob: This help:
@Laurence: Ideally the upgrade notice is a dashboard widget that checks the server PHP version and throws a message and guides. Forgive my simplistic approach.
@MattyRob: https://make.wordpress.org/core/features/servehappy/
Make WordPress Core: Feature Project: Servehappy
@James_Nylen: that could also work @William_Patton
@Joy_Reynolds: But if 1.x is supposed to reflect WP 4.9.x, then it should be the older PHP, since thatās what that is (and plugins too).
@MattyRob: In fact I may have found a commit that introduced a dashboard widget
https://core.trac.wordpress.org/changeset/42832
@Joy_Reynolds: This is the complication of CP version number and WP version number, in regards to what is checked by a plugin.
@James_Nylen: alright, last topic from me: version 2
so far we have been thinking that version 2 would be the version to introduce the plugin directory and also split some features off into core plugins
weāll need to keep discussing and planning this but Iām thinking it might be better to just launch the plugin directory at first, and then look at removing features in v3
however, we now have 2 possible approaches for core plugins
@ElisabettaC77: Makes sense to start with the directory and then go from there.
We wonāt start to split unless there is the directory, as far as I can understand. Correct?
@fwolf: totally agree with that ā¦ the micro-cosmos of extensions is what made WP become so big, so its essential to get that thing done ASAP
@James_Nylen: 1. https://github.com/invisnet/ClassicPress/commit/0526af5f5774520f9c48808055d0cf98f67cfac2
2. https://github.com/ClassicPress/ClassicPress/commit/15c5b8f6232c49c3d177fbeaa4bdf87bc9cbfa23
yes - we canāt split anything out into core plugins until our directory exists, so it also makes sense to have that stable first
so that would mean that we are looking at launching the plugin directory in v2, and then probably some core plugins in v3
one thing Iād like to see out of the core plugins is that we actually remove the code that is being disabled, rather than just returning early
at least in the release builds
anyway that is just for some thoughts about the future, 1.2.0 and the plugin directory will come first
Iāll be around for ~10 more minutes if anyone has any other questions
@MattyRob: Launching a plugin directory and populating it with āextensionā plugins first seems like a good plan to iron out any kinks before then splitting core code into plugins.
While more work is bing done on the custom logo changes and plugin directory, a few of the current pull requests are small changes or bug fixes, are any of the current list of pull requests possible for inclusion in 1.2.0?
@James_Nylen: Ideally I would like to see some evidence that some of these are issues affecting existing ClassicPress users. Otherwise I would prefer to wait on most of these, since we need to finish 1.2.0 with things that we know our community wants/needs.
Per the established review criteria for minor changes: https://github.com/ClassicPress/ClassicPress/blob/2f660154991ca29075ee814e448383f836eeb4dc/.github/CONTRIBUTING.md#review-criteria
Also note there are already a lot of small changes slated for 1.2.0 (basically everything that has been committed to develop since the 1.1.0 release).
@Joy_Reynolds: Seems like old WP tickets indicate a need, instead of trying to find bugs in the small pool of CP users.
@James_Nylen: Iām not sure I agree with that completely. Itās good to see those fixed, and Iām happy for CP to include the fixes, but we do need to prioritize.
@Joy_Reynolds: Anything fixed in a WP ticket that is older than 4.9 seems like a good use of the WP user base for testing.
@MattyRob: I can understand the rationale of fixing things when we know they are broken for users, but equally a lot of developer frustration with the WordPress system is when issues and tickets sit for years before a fix and commit is made. Should we therefore consider being more proactive at fixing upstream issued before they become a problem for users? (Accepting completely that we need some priority of the time and work involved)
@James_Nylen: Sure, and you can argue that any older WP issue affects CP users by definition. Another thing that helps me a lot with these PRs is having them tested on a ClassicPress site with instructions and screenshots. For example:
ā¢ Create 40 approved comments in a loop with wp comment create ...
ā¢ Create an unapproved comment with wp comment create ...
ā¢ Observe the following error in the comments list before this change (screenshot)
ā¢ Apply the changes in this PR and verify that the error is fixed (screenshot)
This is towards review criterion #4 āWe understand the code change very well or can ask questions of someone who understands it very well.ā
Honestly if I have to go figure all of that out myself, I am probably going to prioritize a feature that existing CP users have told me they want.
@Laurence: Thatās a good concern @James_Nylen Let me see some GitHub templates that help with this. I have seen some that address this very issue.
@MattyRob: Okay, that seems fair enough, there is no way any one person can totally understand how all of the pieces of WordPress or ClassicPress fit together. Iām going to try an upskill myself on WP-CLI now and see if there is a way to do some testing on some of the current PRs.
@James_Nylen: itās really more a question of doing the testing, and telling others how to do it, than which template you use
@MattyRob do you have a development install set up like https://classicpress.slack.com/archives/CCCF22HG8/p1596729206228800 ?
[August 6th, 2020 8:53 AM] jnylen: ā¢ git clone the ClassicPress repository
ā¢ create a database and a working wp-config.php that points to that database under src/wp-config.php
ā¢ point your webserver at the src directory
testing doesnāt necessarily have to be done via WP-CLI either
depends on the issue, but āhereās how to reproduce this issue ā¦ hereās proof that this PR fixes it (and an explanation of how and why it works)ā
@fwolf: as long as tests a replicable and valid ā¦ I guess? I do have both a WP nightly AND a CP dev install sitting around (not locally), for this very purpose(s)
@Joy_Reynolds: There is a Beta Tester plugin for WP. Could we modify it to get CP versions from GitHub?
But it looks at the WP API.
@James_Nylen: something like that would help for testing but not so much with development
setting up a development install and learning how to check out the branch you want is really the ārightā way to do that
otherwise, a tool that generates a build from a GitHub branch or PR could be useful, but that would also be a potential attack vector
@ElisabettaC77: Letās think numbers. You are right on the right way, but we will grow. And having that maybe can help to engage people?
@James_Nylen: I hope so
I think the biggest draw to our numbers so far will be letting developers publish their plugins and themes
@ElisabettaC77: This for shure
@James_Nylen: Alright, Iām closing the meeting thereā¦ Iāll post a transcript on the forums in a bit, and further questions are always welcome of course