View in #core on Slack
@Simone_Fioravanti: I will not be able to attend at today’s meeting.
So leaving here some notes.
PR35 for me can be merged. I’ve installed many plugins to test PR25 and the ones using
wp-date are missing a lot of other JS dependencies, so adding
wp-date will not have any benefit.
PR25 can be merged if the last change is ok.
PR36 is ok.
@Matt_Robinson: It is time for the weekly meeting - noted the comments above, there are a couple of PRs there ready to merge.
I’ve merged 36 as it was a simple change.
Is the approach we are taking in PR35 acceptable? We are dropping use of
wp-date in that single useful location (Application Passwords) for a simpler message saying “Just Now” when a new password is generated. The date is displayed after the page is reloaded.
@Viktor: I think it’s the right approach.
Unless we want plugins/themes to use it, we don’t need it in that specific situation.
@Matt_Robinson: It is packaged so any plugin that uses it can bundle it, or should be checking it is available IMO. I’ll merge that next then. And then perhaps #39 also.
While tests are running I opened this:
@Viktor: I remember seeing it. Have you submitted any PRs yet?
@Matt_Robinson: As per that issue there are some chunks of code that still relate to blocks, in terms of approach, are we better with a set of small PRs for this, or larger ones? I have a feeling we may get through it better with smaller PRs that can be reviewed and merged more quickly.
As such I have not created any PRs yet, nor even started looking in any detail.
@Viktor: Smaller sounds better. One issue won’t hold up other PRs from being merged.
@Matt_Robinson: That’s agreed then, I will start looking at creating a few smaller PRs tackling single issues.
Is there anything else for this week?
I saw your update blog - nice.
@Viktor: One thing I wanted to bring up, which we discussed when we created new repo for v2.
As I’ve been looking at the repos and researching it, we may have some problems to consider when we need to take v2 repo live.
- If we replace v1 repo with v2 repo (swap URLs), we will lose stars, watchers, forks.
- We will need to copy labels from v1 to v2 repo.
There might be something else I’m forgetting, but that’s the main points so far.
@Matt_Robinson: I hadn’t really thought that far ahead. I was beginning to look at nightly and hadn’t worked out a good way to create a night from 2 repos at the same time.
Perhaps we need to either move V1 to a new repository or maybe branch it. Then we copy the files from v2 into the v1 repository when we are feeling that v2 is ready for a wider audience - it would allow nightly builds to be used for testing which would be a plus.
@Viktor: I agree. We can create classicpress-lts (or classicpress-v1) repo to maintain and then archive v1 codebase. Then rebase
develop branch with v2 code.
@Matt_Robinson: Okay, let’s have that as the planned strategy then and as we get closer we can make sure it is still the best way forward.
@Viktor: Sounds good.
@Matt_Robinson: Anything else for this week?
@Viktor: I don’t think so. I will try to find some time to compile a list of URLs to change, so we can update that. A quick question about our gettext implementation. Would “https://google.com” be treated the same as “https://google.com/” when replacing URLs?
I noticed in WP core at least one instance of
<https://wordpress.org/support/forums> while usually it’s
Maybe we should just fix the trailing slash.
@Matt_Robinson: That reminds me, when I hacked the automated theme and plugin updates to work I got an email:
If you experience any issues or need support, the volunteers in the <http://WordPress.org|WordPress.org> support forums may be able to help.
We will need to check through for instances like that.
In terms of our filter, yes I think they would be treated the same provided we leave the trailing slash out of our list of items to replace - it’s then just a string comparison.
@Viktor: Thanks. I will look into it.
@Matt_Robinson: Okay, until next week then - thanks.