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":
- https://developer.wordpress.org/plugins/post-types/registering-custom-po...
- https://developer.wordpress.org/themes/basics/post-types/
- Extremely common plugin in WP: https://wordpress.org/plugins/custom-post-type-ui/ So we could import sites that use this plugin for example.
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
Comment #2
hongpong commentedComment #3
hongpong commentedComment #4
hongpong commentedComment #5
hongpong commentedI 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.