Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

WordPress importer

Ouverte
  • Quelque chose ne va pas ?
#90 0 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
django, python
Domaine
backend, content

Piste de recherche

Commencez par examiner le format d’exportation XML de WordPress et les modèles de pages, d’images et de documents de Wagtail référencés dans les exigences. Avant l’implémentation, définissez un MVP pour importer les articles de blog, notamment les types de contenu, les médias, les URL et les redirections ; le travail sera considéré comme terminé lorsque le périmètre et le workflow de mapping seront convenus.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Needs Research Sprints Type: Enhancement Wish List

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.

Langage dominant
Python
Étoiles
765
Forks
154
Aucune PR mergée en 30 j

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de coderedcorp/coderedcms

Toutes les issues de coderedcorp/coderedcms

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.