Bulk Migration Support via WP CLI

[dsawardekar]

Description of the Change

This PR adds support for bulk migration of classic editor posts to Gutenberg Blocks. The implementation provides a WP CLI command to start and monitor the progress of the migration. When started the CLI outputs a link that must be opened in a browser window. The browser window will convert classic editor content to blocks and then move on to the next post, and so forth until all posts are converted. Posts that are already converted to blocks are skipped.

The following screencast shows this in action.

Closes #56

Verification Process

To verify this you need a WordPress database with classic editor content. Then run the WP CLI as follows. The CLI will output a URL that needs to be opened in the Browser. (You should be logged in to the WordPress before hand.)

$ wp convert-to-blocks start

I've tested this on a recent production migration with <1000 posts. Larger migrations are also possible but will take longer to complete.

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Changelog Entry

Added - WP CLI based bulk migration support

Credits

Props @dsawardekar

[dsawardekar]

cc @jeffpaul @gthayer

[gthayer]

I think this would need to be updated to be a paginated loop.

[jeffpaul]

@dsawardekar if you agree on ^ this, mind a quick update to make that update?

[dsawardekar]

@gthayer @jeffpaul We do need the posts_per_page=-1 here because of the way this has to be structured. The WP CLI seeds the loop with the ids query and runs only once when the WP CLI command is started. Once the agent link is opened, the loop runs entirely in the browser via redirects.

[jeffpaul]

@dkotter @faisal-alvi looking to one of you to give this a review from the OSP perspective, please and thanks!

[faisal-alvi]

LGTM, it worked:

But I have noticed a couple of things:

1. It also runs through the posts which do not have classic editor content. Would be very efficient in performance and time savior if we only loop through the classic editor posts.
2. If the post is empty, the 'Classic Editor' mark remains as is, even after the migration is completed. For example, please see the post "test2" below:

Also, ran the phpcs check and found the following errors in multiple places, so just pointing here:

• Short array syntax is not allowed.
• Parameter comment must end with a full stop, exclamation marks, or question marks.

A question: can we pass a CPT slug in the CLI command to convert its posts?

And, just a few minor suggestions are posted below.

[faisal-alvi]

A minor alignment required.

[dsawardekar]

Updated

[dsawardekar]

@faisal-alvi I ran composer lint-fix and pushed the changes to this branch. The alignment issue was the only thing I saw when running composer lint on my local. After fixing that, I do not see any other linter warnings.

➜ convert-to-blocks (feature/wp-cli-migration-agent) ✔ composer lint
> phpcs .
➜ convert-to-blocks (feature/wp-cli-migration-agent) ✔ 

RE: Empty posts showing as CE after conversion

The only way to accurately check if a post has blocks is to check its post_content for the Gutenberg preamble, <!-- wp. An empty post has nothing to convert and hence is treated as CE content even after conversion.

The PR has the --only WP CLI flag which takes a comma delimited list of post ids. That could be used to customize which post_ids to convert if such flexibility is needed. Maybe it could be a filter hook that overrides the post ids lookup. Lets get user feedback to understand typical usage.

cc @jeffpaul