Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

WordPress importer

Abierto
  • ¿Algo no está bien?
#90 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
django, python
Área
backend, content

Línea de trabajo

Comienza revisando el formato de exportación XML de WordPress y los modelos de páginas, imágenes y documentos de Wagtail mencionados en los requisitos. Antes de la implementación, define un MVP para importar entradas de blog, incluidos los tipos de contenido, los medios, las URL y las redirecciones; el trabajo estará terminado cuando se hayan acordado el alcance y el flujo de trabajo de mapeo.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
765
Forks
154
Sin PR fusionados en 30 d

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coderedcorp/coderedcms

Todos los issues de coderedcorp/coderedcms

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.