实战:Drupal迁移到WordPress

文章目录

    • 为什么要迁移
    • 方案
    • 准备工作
      • 建立测试用的WordPress站点
      • 建立临时Drupal站点
      • Blog转Article
      • 恢复原图
    • 数据导入
    • 中文文件名图片的问题
    • 修改数据库
    • 链接重定向
    • 教训
    • 参考

使用WordPress的插件 FG Drupal to WordPress可以将Drupal站点迁移至WordPress。使用插件本身是很容易的,烦琐的工作在迁移前的准备及迁移后的一些处理。本文从实战角度讲述了整个过程,一些解决问题的思路可供参考。

为什么要迁移

简单地说,是因为WordPress的阵营比Drupal大得多(份额:59.8% 比 4.6%)。使用Drupal十几年,见到许多模块后继无人。而我自己的站点只是一个图文混排的Blog,用到Markdown、代码语法高亮、图片自动水印、文档自动目录(TOC)等(详见这里)。Drupal虽然能做到,但总还有些问题,模块成熟度不够。表现在效果差一点或易用性不够。

实战:Drupal迁移到WordPress_第1张图片

方案

基本方案是使用WordPress里的FG Drupal to WordPress插件。这个插件支持文章和图片的导入。但是免费版的不支持评论的导入。另外,各种版本好像都不支持Blog类型内容的导入。

还有一个CMS2CMS的插件,但评价不高,而且需要注册。试了一下就放弃了。

另外,我的服务器都是基于Docker的,所以测试的和正式的站点都会基于Docker,安装和配置会比较省事。

准备工作

建立测试用的WordPress站点

这个站点用于导入数据,也是为了体验功能,验证WordPress是否能实际满足自己的需求。

因为FG Drupal to WordPress需要用到MySQL PDO,而官方docker image没有安装,所以自行修改一下,顺便使用国内的镜像会快很多。

下面是 Dockerfile。

ARG VER=5
FROM wordpress:$VER
MAINTAINER loblab

ARG APT_MIRROR=mirrors.163.com
ARG DEBIAN_FRONTED=noninteractive
RUN find /etc/apt -type f -name "*.list" -exec sed -i s/deb.debian.org/$APT_MIRROR/ {} \;
RUN find /etc/apt -type f -name "*.list" -exec sed -i s/security.debian.org/$APT_MIRROR/ {} \;
RUN apt-get update --fix-missing && apt-get -y upgrade

#RUN apt-get -y install php-mysql
RUN docker-php-ext-install pdo pdo_mysql

创建一个空的数据库以及用户tmpwp,给站点使用。配置写入 docker-compose.yml 里。

services:
    wp0:
        image: loblab/wordpress
        hostname: wp0
        container_name: lab-wp0
        restart: "always"
        ports:
            - "8039:80"
        environment:
            WORDPRESS_DB_HOST: mysql5
            WORDPRESS_DB_NAME: tmpwp
            WORDPRESS_DB_USER: tmpwp
            WORDPRESS_DB_PASSWORD: password
        volumes:
            - "./wordpress/php-upload.ini:/usr/local/etc/php/conf.d/php-upload.ini"
            - "/var/lib/sandbox/wordpress:/var/www/html"

WordPress的安装确实很容易,从 pull/build docker image 到安装完成,总共不到10分钟。

建立临时Drupal站点

克隆一个Drupal的临时站点,用于导出。导出并不一定是只读的,根据导入的要求,有可能对原始数据进行修改。所以克隆的不仅是数据库,最好将附件也进行复制。以免因误操作破坏原站点。

实战:Drupal迁移到WordPress_第2张图片

Blog转Article

因为FG Drupal to WordPress不支持Blog类型的导入,于是在Drupal站点里将Blog类型转为Article。这需要使用Convert Bundles模块。

实战:Drupal迁移到WordPress_第3张图片

但它对VBO的支持似乎不好,因为我的Blog数量不算多,所以就手动点了几十页,没再折腾VBO。

恢复原图

Drupal中呈现的是缩小并加水印的图片,如果直接导入得到的将是这种图片。为了把原图导入到WordPress,我们可以在Drupal中去掉Large style图片的缩放及水印处理,然后重新生成Large style的所有图片。使用drush命令:

drush if large

数据导入

在WordPress站点里安装FG Drupal to WordPress插件。

实战:Drupal迁移到WordPress_第4张图片

导入的设置如下:

  • 把Drupal的Summary导入为摘要(Excerpt)
  • 不设置Featured image

实战:Drupal迁移到WordPress_第5张图片

导入的结果类似这样:
实战:Drupal迁移到WordPress_第6张图片

注意检查导入图片的数量和 Drupal 的 style/large 目录的是否一致。如果发现有问题就重新导入。我实际导入了几十次。所以设置为每次导入前就自动全部清除。

中文文件名图片的问题

似乎FG Drupal to WordPress并不能很好地处理中文文件名。中文字符被忽略掉了。比如"汉字abc123.jpg"将被重命名为"abc123.jpg",而全汉字的文件名将被重命名为"unnamed"。于是就会出现下面的问题:

实战:Drupal迁移到WordPress_第7张图片

如果同一个月份里有好几个全汉字的文件名,则它们都会被最后一张覆盖。数据库里看每张图片都被导入过,只不过文件名都变成了一样的unnamed.

实战:Drupal迁移到WordPress_第8张图片

因为数量不多,而且是后面才发现这个问题,所以就手动删除,重新上传,手动修改文章中的链接了(试过几个 replace image 类型的插件,因为和我用的其它的Image缩放、水印之类的插件在一起,容易出错,就放弃了)。

修改数据库

因为原Drupal站点文章里的内容,有些不是纯Markdown的语法(比如插入的图片链接,代码语法高亮),于是趁这个机会一并改掉。

去分析数据库结构并用SQL语句修改不一定容易,我简单地导出整个数据库为SQL语句,并用全文查找替换,然后导回。使用强大的正则表达式。事实证明,简单粗暴有效。因为要替换的字符串的pattern是唯一的。下面是Perl的写法。

    s#\\n\]+?src=\\"(http://nuc.+?|/sites/default/.+?)\\".+?(alt|data-caption)=\\"(图:)?(.+?)\\".*?\>#\\n![$4]($1)#g;
    s#\(http://nuc.loblab:8039/(.+?)\)#\(/$1\)#g;
    s#\#```$1#g;
    s#\\n\#\\n```#g;

因为WordPress很多地方把域名hard code进了数据库,所以在改变域名时(测试站点变正式站点时),也要用类似的办法处理(UI上重新设置似乎不彻底)。

链接重定向

考虑到搜索引擎收录了以前的文章链接,而新站点的链接地址和以前的不同,所以需要使用301做重定向。

先在Drupal里,做一个View,得到Node ID和文章标题的映射表。

1065  Redis 性能简单测试
1058  灯光控制器的硬触发测试
1054  Docker下使用GPU版TensorFlow

在WordPress里,则可以直接查询到ID和文章标题(WordPress的数据库比Drupal简单了一个数量级)。

SELECT id, post_title
FROM `wp_posts`
WHERE post_status="publish" AND (post_type="post" OR post_type="page")
ORDER BY `post_date` DESC

结果类似于:

1413  Redis 性能简单测试
1405  灯光控制器的硬触发测试
1394  Docker下使用GPU版TensorFlow

根据这两个对应关系,以文章标题为桥梁,就可以得到新旧链接的对应关系。类似于:

Redirect 301 /node/1065 /p/1413
Redirect 301 /node/1058 /p/1405
Redirect 301 /node/1054 /p/1394

Term/Tag 的链接重定向也可以用类似的办法。

最后将这些跳转项加入到web root的.htaccess中。

教训

迁移过程中的教训:

  • 不要使用中文文件名,即使你现在的系统支持,但很可能在某次迁移中产生问题。除了这次的迁移,当我尝试把图片迁移到Lychee(一个图片管理系统)时,中文文件名也产生了问题。
  • 使用文章标题作为永久链接也许是有道理的。如果两个系统都支持这种链接策略,在迁移后就不需要做重定向了。不过,文章发布后就宜修改标题了。

参考

  • WordPress vs Drupal – Which One is Better?
  • How to Migrate Drupal to WordPress (In 3 Steps)

你可能感兴趣的:(实战:Drupal迁移到WordPress)