实战：Drupal迁移到WordPress
文章目录
- 为什么要迁移
- 方案
- 准备工作
- 建立测试用的WordPress站点
- 建立临时Drupal站点
- Blog转Article
- 恢复原图
- 数据导入
- 中文文件名图片的问题
- 修改数据库
- 链接重定向
- 教训
- 参考
使用WordPress的插件 FG Drupal to WordPress可以将Drupal站点迁移至WordPress。使用插件本身是很容易的，烦琐的工作在迁移前的准备及迁移后的一些处理。本文从实战角度讲述了整个过程，一些解决问题的思路可供参考。
为什么要迁移
简单地说，是因为WordPress的阵营比Drupal大得多（份额：59.8% 比 4.6%）。使用Drupal十几年，见到许多模块后继无人。而我自己的站点只是一个图文混排的Blog，用到Markdown、代码语法高亮、图片自动水印、文档自动目录（TOC）等（详见这里)。Drupal虽然能做到，但总还有些问题，模块成熟度不够。表现在效果差一点或易用性不够。
方案
基本方案是使用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的临时站点，用于导出。导出并不一定是只读的，根据导入的要求，有可能对原始数据进行修改。所以克隆的不仅是数据库，最好将附件也进行复制。以免因误操作破坏原站点。
Blog转Article
因为FG Drupal to WordPress不支持Blog类型的导入，于是在Drupal站点里将Blog类型转为Article。这需要使用Convert Bundles模块。
但它对VBO的支持似乎不好，因为我的Blog数量不算多，所以就手动点了几十页，没再折腾VBO。
恢复原图
Drupal中呈现的是缩小并加水印的图片，如果直接导入得到的将是这种图片。为了把原图导入到WordPress，我们可以在Drupal中去掉Large style图片的缩放及水印处理，然后重新生成Large style的所有图片。使用drush命令：
drush if large
数据导入
在WordPress站点里安装FG Drupal to WordPress插件。
导入的设置如下：
- 把Drupal的Summary导入为摘要（Excerpt）
- 不设置Featured image
导入的结果类似这样：
注意检查导入图片的数量和 Drupal 的 style/large 目录的是否一致。如果发现有问题就重新导入。我实际导入了几十次。所以设置为每次导入前就自动全部清除。
中文文件名图片的问题
似乎FG Drupal to WordPress并不能很好地处理中文文件名。中文字符被忽略掉了。比如"汉字abc123.jpg"将被重命名为"abc123.jpg"，而全汉字的文件名将被重命名为"unnamed"。于是就会出现下面的问题：
如果同一个月份里有好几个全汉字的文件名，则它们都会被最后一张覆盖。数据库里看每张图片都被导入过，只不过文件名都变成了一样的unnamed.
因为数量不多，而且是后面才发现这个问题，所以就手动删除，重新上传，手动修改文章中的链接了（试过几个 replace image 类型的插件，因为和我用的其它的Image缩放、水印之类的插件在一起，容易出错，就放弃了）。
修改数据库
因为原Drupal站点文章里的内容，有些不是纯Markdown的语法（比如插入的图片链接，代码语法高亮），于是趁这个机会一并改掉。
去分析数据库结构并用SQL语句修改不一定容易，我简单地导出整个数据库为SQL语句，并用全文查找替换，然后导回。使用强大的正则表达式。事实证明，简单粗暴有效。因为要替换的字符串的pattern是唯一的。下面是Perl的写法。
s#\\n\]+?src=\\"(http://nuc.+?|/sites/default/.+?)\\".+?(alt|data-caption)=\\"(图：)?(.+?)\\".*?\>#\\n#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)