WordPress importer

Inizia esaminando il formato di esportazione XML di WordPress e i modelli di pagine, immagini e documenti di Wagtail a cui fanno riferimento i requisiti. Prima dell’implementazione, definisci un MVP per l’importazione dei post del blog, includendo tipi di contenuto, media, URL e reindirizzamenti; il lavoro sarà considerato completato quando l’ambito e il workflow di mapping saranno concordati.

Yes, the holy grail of wagtail, a complete WordPress importer. Opening this issue here to jot down notes and learnings from various site migrations, so we can figure out what a WordPress importer actually needs to do. For reference, WP=WordPress and CR=CodeRed CMS here.

The WordPress site importer would probably be run first, before populating any content or pages on the site. I would not imagine supporting a use-case where the importer is run after you already have content. It would be much simpler to run it on a clean slate.

To avoid over-engineering, the main goal or minimum viable product would be importing blog posts, as there are usually usually hundreds of them and it is a tedious process to manually replicate.

Base requirements:

• Use the XML format created natively by WP from the "export" functionality. This file should contain all of the information needed.
• WP has two content types: Posts and Pages (which are actually posts). But many plugins create custom post types, so there is no easy way to handle this. So I'm thinking the first step would be to analyze the XML file and determine what types exist. The user would then somehow specify or map which WP post types in correspond to which CR page types or snippets. The importer should probably handle this analysis and provide some sort of template or UI for the user to map the content types. An easy assumption to make would be that all WP pages map to CR WebPage, and all WP posts map to CR ArticlePage.
• The importer would then use the user mapping, to run that against the XML file.
• During import, media would be downloaded from the old site and saved as a wagtail image or document. The reference to that media would also need to be updated within the post content so wagtail knows which image to use.
• During import, the URL of each page would need to be set, and if the old URL is different from the new URL (possibly specified during user mapping?) then a redirect should be created.
• As a baseline, content of WP pages/posts could be saved in a CR rich text field in the body, or even more of a baseline, as an HTML field directly in the body. The HTML field would be the easiest to implement, with the assumption that a content editor would have to go through the pages and manually "massage" the content into a new format. Older blog posts etc could simply keep the content in HTML for posterity.

Possible advanced features:

• Ability to handle shortcodes. Most likely this would work that during XML analysis, a list of shortcodes would be presented. During the user mapping process the user could specify how to handle each short code. I.e. a shortcode could get mapped to a specific block, or could simply be deleted or ignored.
• Special handling of Yoast SEO data, this would get mapped into the appropriate SEO fields in CR.
• Special handling of form plugins. It would be nearly impossible to support them all, but Contact Form 7 is a big one.

Other notes or major concerns: WordPress 5.0 has introduced Gutenberg editor, which I'm quite certain stores the data in a completely different format than the old editor. I'm sure this will need to be accounted for in the importer.