博客程序由Typecho迁移到WordPress的原因分析

在前面的博文中，我提到，由于插件的原因我将博客程序从Typecho换成Wordpress，今天我具体分析一下这件事。并讲述一下这几年使用其他博客程序的情况，分析一下为何庆幸没有用其他博客程序，为各位博友提供参考，也为我的折腾史画上句号。

（1）

Typecho程序的主题有很多，虽然不像Wordpress那样拥有海量的主题，但还是给博主们提供了可选择的空间。然而，Typecho的插件就不那么完善了。

2013年我的博客数据丢失时，只有唯一的一个数据库备份在我邮箱里，是Wordpress自动备份数据库的插件发送的。之前邮箱里有上百封数据库备份邮件，被我全删了，而最后一封邮件发过去以后，主机就崩了，因此只有这一个数据库备份。数据丢失让我长了记性，数据库一定要及时备份。不能依赖本地备份，因为几年前的移动硬盘损坏事件也让我长了记性。

Typecho有个插件叫Autobackup，用于数据库自动备份并发到邮箱。我下载到的是1.1.0版本，于2012年6月15日发布，从此以后再无更新。目前没有其他插件可以实现这个功能。

插件是这样实现功能的：在博客后台对该插件备份的数据表、备份间隔时间、发送邮件的方式和接收邮箱进行设置；插件包含一个config.xml文件，里面记载上次发送邮件的时间，当博主发表或更新一篇文章，或有访客在前台提交评论，则会触发插件计算此时的时间与上次发送邮件的时间之差是否超出了备份间隔时间，如果是，则插件会压缩数据库并发送到指定的邮箱。这样有个缺点，博主提交文章或访客提交评论时，需要等待10-15秒的时间。

这个插件在php7.x下是可以运行的，但会产生如下5种报错信息，每次插件被执行时都会被记录：

PHP Deprecated: Non-static method AutoBackup_Plugin::SendMail() should not be called statically in /usr/plugins/AutoBackup/Plugin.php on line 172

PHP Deprecated: Non-static method AutoBackup_Plugin::create_sql() should not be called statically in /usr/plugins/AutoBackup/Plugin.php on line 112

PHP Notice: Undefined variable: config in /usr/plugins/AutoBackup/Plugin.php on line 212

PHP Notice: Trying to get property 'pass' of non-object in /usr/plugins/AutoBackup/Plugin.php on line 222

PHP Notice: A non well formed numeric value encountered in /usr/plugins/AutoBackup/pclzip.lib.php on line 1972

尽管报错，但能用。如果将主机的php版本升级到8.x，则彻底无法运行。Typecho程序会直接在网站主页显示：

Error: Non-static method AutoBackup_Plugin::create_sql() cannot be called statically in Plugin.php:112

要想博客在php 8.x下能正常运行，就必需禁用该插件。我想向作者反馈这个问题，但是作者的博客早就打不开了。我通过web archive查看，发现该插件发布时作者使用的是静态博客，且他的博客在2015年以后就再也打不开了。

在迁移到Wordpress之前，我利用测试站进行了相关测试。Wordpress下的同类插件有很多，我测试了三个：UpdraftPlus、WP-Db-Backup和BackWPup。UpdraftPlus太过于复杂，不推荐使用；WP-Db-Backup依赖wp-cron定时任务进行数据库备份，但当前2.4版本不支持php 8.x；BackWPup可用来备份数据库、网站文件、已安装的插件列表、Wordpress XML输出等，可使用wp-cron备份，也可以访问特定的链接备份，我使用后者，将链接添加到免费的海外网站监控服务中，每24小时监控一次，相应的数据便定时发送到了我的邮箱中。

当主博客使用的程序迁移到Wordpress以后，我便直接利用BackWPup进行相应备份，心里踏实多了。

（2）

由于Wordpress相对Typecho来说臃肿很多，因此有必要进行一些优化。我使用的虚拟主机是Cloudlinux+Cpanel+litespeed，针对Wordpress有专门的优化，可安装Litespeed cache插件进行优化设置，加快wordpress网站的访问速度。目前，本博客的访问速度和之前使用Typecho时相差无几，而且后台速度也是很快的。

另外，在迁移至wordpress以后，smtp异步发送评论提醒邮件再也没有失败过。

（3）

2016年底博客重建时，考虑到Wordpress已经没有新鲜感，我让主机商客服帮我安装的zblog php。安装的当晚和第二天上午，zblog经常出问题，我的博客没办法正常运行。随后，我看到有博主用typecho，我便删掉zblog安装了typecho，一直用到2021年6月8日。在前面的博文中我提到，这几年，为折腾Typecho及其插件，我付出了很多精力，付出了很多心血。学到了很多东西，也付出了很多代价。这里就不讲述这些年的折腾史了。

这几年，除了zblog，我也测试过emlog、flatpress、movabletype等程序。emlog几乎已死，flatpress是文本数据库，movabletype不开源，因此我还是以zblog来说一下吧。

让我庆幸的是，幸亏我没有坚持用zblog。如果我用zblog，即便不考虑数据备份到邮箱的问题、不考虑其他任何意外情况，zblog的数据迁移问题也早晚会被我遇上。

将数据迁入zblog，可以用插件进行，相关的插件有好几个，网上也有大量的帖子介绍如何将wordpress迁移到zblog，尽管我测试失败了。然而，zblog迁移到wordpress的帖子极少。2009年之前的帖子说，可以使用zblog迁移到movabletype的插件，导出movabletype格式的文件，再利用movabletype导入wordpress的插件（wordpress后台可以一键安装）导入wordpress，但是，2009年之前的帖子中所说的插件在zblog应用中心已经搜索不到了，这个方法已经不能再使用。除了插件以外，只能对数据库进行操作，这需要非常专业的知识和能力，我看不懂。印象当中我看过一个博主说，他从zblog转移到wordpress时，zblog交流群里的人可以提供数据库转换操作，几十篇文章收费大概五百元，于是他放弃了所有的数据。

前几天安装zblog进行研究时发现，在2020年11月5日，开发者沉冰浮水发布一个插件可以将zblog数据导出为Movabletype 格式。这样便可以用Wordpress后台的Movabletype导入插件将数据导入wordpress。这可能是2020年11月以后唯一能将zblog数据转移到其他平台的插件。但经过我的测试，数据转移不完全，页面、评论、分类是无法被转移的。

zblog上至今还未发现数据库自动备份并发送到邮箱的插件。

所以，幸亏博客重建伊始安装zblog以后总出问题导致我换成了typecho，我非常庆幸一开始没有用zblog。

当然，这里有必要再提一个问题。我知道有些博主用VPS，上面安装的某些面板可以将数据库备份到需要你提供隐私信息的对象存储平台上。但我用的不是VPS，我的VPS被我用来建独立邮箱了，我也不考虑把主博客放在VPS上，原因在前面的博文中说过，这里不再赘述。

就这样吧。多思考、少折腾。