Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

WordPress importer

未关闭
  • 哪里不对？
#90 0 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
django, python
领域
backend, content

调研方向

首先检查需求中引用的 WordPress XML 导出格式以及 Wagtail 的页面、图像和文档模型。在实现之前，定义一个用于导入博客文章的 MVP，包括内容类型、媒体、URL 和重定向；当范围和映射工作流达成一致时，即可视为完成。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Python
星标
761
派生
153
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

coderedcorp/coderedcms 的其他 Issue

查看 coderedcorp/coderedcms 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。