add: created a new CLI cmd to backfill missing author terms for posts.

[eddiesshop]

Description

This is a new, more efficient, command to help backfill author term data for any posts that are missing it. The new command was based off of the old one. The key differences between that command and this one are:

1. If, for some reason, the command were to get killed while it was backfilling data, re-running wp co-authors-plus create-terms-for-posts would always start back from the first post. For sites of a certain stature, this could create a situation where this command would never finish executing. Instead, this new command only looks for posts that are missing the requisite author term in the relationships table via SQL.
2. Since only posts that are missing the author term are pulled, once the missing data is created, any subsequent command execution means that you will be processing a smaller and smaller list of posts that need to be addressed, unlike the existing command.

Deploy Notes

Are there any new dependencies added that should be taken into account when deploying to WordPress.org?
No, this is an entirely new command.

Steps to Test

1. Check out PR.
2. Take a DB backup.
3. Execute this command with wp co-authors-plus create-author-terms-for-posts
4. Once complete, run the old command: wp co-authors-plus create-terms-for-posts. Notice that no new author terms are being created.

[leogermani]

@GaryJones do you know why we have these failing tests here? I see that we no longer support php 7.1 (

Co-Authors-Plus/co-authors-plus.php

Line 16 in 37065d2

* Requires PHP: 7.4

) and for some reason these integration tests are not running in other open PRs

[GaryJones]

do you know why we have these failing tests here?

Since https://github.com/Automattic/Co-Authors-Plus/blob/develop/.github/workflows/integrate.yml use PHP 7.4, it looks like this PR branch should be targetted to develop (not main, since that's our production release branch).

[leogermani]

Looks and tests well.

Can we just add a comment to the command description highlighting the difference between this and the old command?

I also think we could add a comment in the old command, saying that we should give preference to this new and more robust version of it.

And a NIT, not blocking: since the batching occurs on run time, there is no real difference from a user perspective running the command with or without it, from a functional point of view. The only thing that can happen is an OOM if you run without batching... In other words, there is no reason to have an option to run this command without doing batches. Is there? We could leave just the option for the batch size and always run in batches... WDYT?:

[eddiesshop]

Can we just add a comment to the command description highlighting the difference between this and the old command?

I also think we could add a comment in the old command, saying that we should give preference to this new and more robust version of it.

Great idea! Done here.

And a NIT, not blocking: since the batching occurs on run time, there is no real difference from a user perspective running the command with or without it, from a functional point of view. The only thing that can happen is an OOM if you run without batching... In other words, there is no reason to have an option to run this command without doing batches. Is there? We could leave just the option for the batch size and always run in batches... WDYT?:

That batching approach really comes from a L&I point of view. Often times, our migration commands can be interrupted due to memory constraints or we can cause MySQL binlog replication issues. Although not a perfect approach, tackling a certain amount of records at a time usually mitigates those problems. I don't mind removing it though, since the command should operate just fine if it were restarted due to an interruption during execution.

[leogermani]

That batching approach really comes from a L&I point of view. Often times, our migration commands can be interrupted due to memory constraints or we can cause MySQL binlog replication issues. Although not a perfect approach, tackling a certain amount of records at a time usually mitigates those problems. I don't mind removing it though, since the command should operate just fine if it were restarted due to an interruption during execution.

I don't mean removing the batching approach. I mean making it the default and only approach. There is no benefit in not using it

[eddiesshop]

I obviously need some more coffee today!

I think we shouldn't remove the batched flag, but we should make it true by default. That way, if anyone wants to let it rip, they have that option.