Bug: --only flag silently drops custom post type IDs from migration queue #251

Description

When running wp convert-to-blocks start --only=<ids>, the query filters results by post_type => ['post', 'page'] by default. Any IDs belonging to custom post types are silently excluded from the migration queue, so fewer posts are migrated than expected with no indication of why.

Use case

I had a large set of previously-migrated pages — custom post types — that I wanted to pass directly to the migration command using --only. The expected workflow is: query the IDs with WP-CLI (wp post list --post_type=resource --field=ID), then feed them into wp convert-to-blocks start --only=<ids>. Instead, the custom post type IDs were silently dropped and the queue only contained standard posts and pages.

Steps to reproduce

1. Create or identify posts of a custom post type (e.g. resource, event).
2. Collect their IDs via WP-CLI:

   wp post list --post_type=resource --field=ID --format=csv
   

3. Pass those IDs to the migration command:

   wp convert-to-blocks start --only=1,2,3
   

4. Observe that the migration queue contains fewer posts than the number of IDs supplied.

Expected behaviour

All IDs supplied via --only should be added to the migration queue, regardless of post type. When the caller provides explicit IDs, the post type constraint should not apply.

Actual behaviour

IDs belonging to custom post types are silently dropped. Only IDs matching post_type IN ('post', 'page') are queued.

Environment

• Plugin version: 1.3.4
• WordPress: 7.0.0
• PHP: 8.4