Problem/Motivation

Many WordPress sites have Custom Post Types (CPT) beyond standard posts and pages. It would be useful to be able to import these natively.

However it might require interpreting the contents of the XML file to read from it, and offer additional import wizard steps. Otherwise the machine name attribute, and other attributes, could be manually entered in a set of form fields.

See also #3489999: Subtle wizard pagination bug posts/pages, remove "empty" regarding these wizard steps. This was discussed in 7.x but no patches: #1580412: Custom post types

More about WordPress "post types":

Proposed resolution

Implement some kind of CPT import. It should refactor the existing way that "post" "page" and the others are generated if possible, not be tacked on separately.

Remaining / possible tasks

  • Determine if it can be read from XML file, or defined in another way, or both.
  • Possibly change YML files to 'genericize' more
  • Possibly change how this module works in other ways, eg "plugin derivers"
  • Update WordpressMigrationGenerator.php
  • Alter the wizard steps to include the input format picker.
  • Add test suite and test XML files for parsing.
  • It could also improve import toggling interface, for other types of entities from WordPress such as comments. ( see also #3390758: Add option to disable creating comment migrate plugin)

User interface changes

Additional wizard step pages. At least one per custom post type.

API changes

Removing hard coded "post" and "page" references to replace with something more scalable.

Data model changes

Additional config entities created.

Comments

hongpong created an issue. See original summary.

hongpong’s picture

Issue summary: View changes
hongpong’s picture

Title: Implement custom post type support » Implement Custom Post Type (CPT) support
Issue summary: View changes
hongpong’s picture

hongpong’s picture

I have at least started in on this by adding the page / post defaults to the config.yml. from there the default selection could be removed from its various hard coded places.

User Interface wise I think a textarea where one content type machine name per line can be added and that would replace the page / post prefixes on the migration incoming content types.

(currently there are migrate entities created with those page post prefixes and it is hard coded in various places)

so it might not actually be terribly difficult to implement further when migration creation happens. we need example xml files to work with however.