wordpress表单数据验证_实战：Drupal迁移到WordPress

使用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 loblabARG 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

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命令：

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的写法。

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

链接重定向

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

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

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

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

SELECT

结果类似于：

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)