feat: handle user nicename change

[leogermani]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

This PR adds some special handling to allow for a safe change of a user's nicename.

User nicename is used to build the user author archive URL, and it's also what CoAuthors Plus use to create the taxonomy that handles posts authorship.

With this PR, when a user_nicename changes:

• It stores the old nicename as user meta
• It changes the taxonomy term used by CAP (author)
• It redirects visits to the old user archive page to the new one

How to test the changes in this Pull Request:

1. Activate CoAuthors Plus
2. Set up a user with a few posts (both as the only author and as a secondary author)
3. Visit the author archive page
4. Change the user nicename to something else: wp newspack nicename-change <user_id> <new_nicename>
5. Refresh the page and confirm you get redirected to the new URL, with the new nicename, and the same authors show up

Test check nicename

1. Run wp newspack nicename-check <nicename> with a username you know is in use and confirm you see the appropriate output
2. with CAP active, run the same command using a term slug that exists, with and without the cap prefix. For example, if you know cap-joe exists, run wp newspack nicename-check joe and wp newspack nicename-check cap-joe.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[leogermani]

Just found an edge case.

If the term slug we want to rename the term to already exists, the script will fail to change the term slug and the posts will no longer be assigned to the user.

This will only happen in a broken database... but that's the kind of database where we want to use this tool

[dkoo]

Works as described!

[leogermani]

Sorry @dkoo . I removed the Needs review label because I wanted to make some adjustments... I added it back again now.

The CLI will now check the availability of the nicename, including looking for CAP terms, before doing anything.

WP will already do it for the nicename itself, and add a suffix to avoid conflict, but it ignores the CAP terms... so I added this check

[dkoo]

Re-tested and it still works! Good call on adding the checks for preexisting nicenames.