Add --importer argument to specify alternative importer class

[Copilot]

Plugins like Polylang ship a custom WP_Import subclass (PLL_WP_Import) that handles their data correctly during import. The CLI had no way to use such a class — it always instantiated WP_Import directly.

Changes

• New [--importer=<importer>] option on wp import. Defaults to WP_Import (no behavior change for existing users).
• Validation before instantiation:
  • Class name must match valid PHP identifier syntax (guards against injection)
  • Class must exist
  • Class must be a subclass of WP_Import
• Dynamic instantiation in import_wxr() using the provided class name, with a @var WP_Import annotation to preserve static analysis coverage.

Example

# Use Polylang's custom importer to preserve translation metadata
wp import content.xml --authors=skip --importer=PLL_WP_Import

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add argument to specify alternative importer class (e.g. PLL_WP_Import)</issue_title>
<issue_description>Hi WP-CLI Team,

While working on a multi-language site which uses Polylang I noticed that translations get damaged after running import via CLI. The same WXR works fine from admin UI (Tools -> Import). Polylang leverages heavily custom taxonomy and custom post types to store translations and trac related posts and terms (i.e. variants of the same entry in different language). After a short investigation I figured out that Polylang comes with a custom PLL_WP_Import class [1], derived from the regular WP_Import, which implements the special handling of Polylang entities during import.

In admin page the standard WP_Import gets swapped with PLL_WP_Import by removing the regular WordPress action and adding Polylang variant in the same place [2]. In CLI there doesn't seem to be any API which would allow for that.

I came up with a rather rudimentary patch [3] which will fork fine for my project. I wonder if you'd be interested in pulling it. Anticipating your question - I didn't investigate other translation plugins or run any tests except smoke-testing it against my development instance.

Cheers,
Bartosz Moczulski

References:
[1] PLL_WP_Import = https://github.com/polylang/polylang/blob/master/integrations/wp-importer/wp-import.php
[2] WP_Import -> PLL_WP_Import replacement = https://github.com/polylang/polylang/blob/master/integrations/wp-importer/wordpress-importer.php
[3] my humble change = bmoczulski@e493025
</issue_description>

Comments on the Issue (you are @copilot in this section)

@danielbachhuber Thanks for the suggestion, @bmoczulski !

I don't think we want to add a hardcoded reference to PLL_WP_Import, but we could add an optional argument to specify an import class to use (assuming it subclassed WP_Import).

Feel free to submit a pull request, if you'd like. Here is some guidance on our pull request best practices, if it's helpful.
You can also stop by the #cli channel on WordPress.org Slack if you'd like help further.</comment_new>

• Fixes Add argument to specify alternative importer class (e.g. PLL_WP_Import) #64

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!