(一)静态博客文件头问题

在2019年4月6日发表的《静态博客搭建方法》中,我曾提到,主流的静态博客系统Jekyll、Hexo、Hugo是互相高度兼容的。Jekyll、Hexo针对markdown文档的格式是100%兼容,Hugo则有个别地方不兼容。例如,Jekyll和Hexo的:title在Hugo中对应的是:slug;Hugo需要在date里标注时区。

为了保证静态博客之间互相迁移时不出现问题,我建议在静态博客写作时,对文件头格式进行兼容。常见的文件头格式包括titledatecategoriestags,我建议再增加slug,以便迁移到hugo时能够不改变文章的永久链接,除非你给每篇博文都使用了permalink参数来自定义永久链接。

个人建议的文件头格式如下:

title: 题目
date: 2019-04-25 10:20:00+0800
categories:
- 分类
tags:
- 标签1
- 标签2
- 如果有更多标签,按格式添加
slug: ti-mu

可以在文件头中使用permalink参数来自定义永久链接,强烈建议使用相对路径;如果不需要评论,使用comments: false;如果不需要使用主题的页面格式,而是自定义,使用layout: false,然后在md文档的正文中来写有关的css、js等定义页面格式和有关的页面外观。更多的文件头参数,可参见静态博客程序的官方文档;部分主题模板也有自定义的参数,可见模板的官方文档。

(二)Typecho邮件发送问题

Typecho目前有三个SMTP邮件发送插件,按发布的时间顺序排列,分别为:CommentToMail、LoveKKComment、Comment2Mail。用户在安装插件时,通常会先安装第一个。

有些博主安装第一个插件后,发送邮件可能会失败。再安装后面的插件则成功了,于是认为是插件问题。这个思维没什么问题,换做我,也会直接这么想。后来有一天,给主机进行维护时,我发现,插件在背锅。最近,经过多次测试,我认为,如果出现这种情况,很有可能不是插件的锅。

在使用插件之前,我们要选对邮箱。这几个插件都依赖一个库:PHPMailer。这个库,对邮箱的安全性要求较高。中国大陆的电子邮件服务商中,QQ邮箱广为人知。但据网友反映,QQ邮箱的安全性低,无法达到PHPMailer的要求,邮件不会发送成功,我也亲自试验过,确实不成功。腾讯域名邮箱,是QQ邮箱内的功能,因此安全性同样不达标,我也试验过。网易邮箱安全性达标,但对发送频率做了限制。海外的Outlook、Gmail这些可以满足要求。我推荐腾讯企业邮箱、Zoho商务邮箱(国际版和国内版只有数据存储位置的差别,也就是是否会被审核过滤的区别)和Yandex。

下面,我简单叙述对三个插件进行测试的过程。我建立了三个typecho博客,已启用我常用的一些其他插件。

我测试所使用的主机是VPS。运行环境:PHP 7.2,Centos 7.3。邮件服务商:腾讯企业邮箱。分别给三个博客后台上传CommentToMail、LoveKKComment、Comment2Mail这三个插件。这三个插件中,每个博客第一次启用的插件均不同。分别启用插件后,进行有关信息的配置。经确认,信息输入无误。对LoveKKComment进行配置时,如果发现网页卡死、崩溃,按照这篇文章(点击查看)的方法进行操作。

接下来,分别在三个博客进行几次的评论和回复评论操作,每次间隔3分钟。这时候发现,这三个博客都没有发出我们想要的邮件。CommentToMail有个邮件发送测试功能,通过这个功能可以发出邮件,但评论和回复评论的邮件没有发出。

登录腾讯企业邮箱账号,在已发送—登录查询—最近30天登录记录中,可以看到“esmtp登录”的记录,还有类似于“(20:15到22:17,共15次)”这样的文字。这就说明,插件连接腾讯企业邮箱没有问题。

在三个博客分别禁用这三个插件,再启用另外两个插件的其中一个,三个博客分别启用不同的插件。再次重复上述操作。结果:三个博客的邮件发送均成功,收件人收到了相应的电子邮件。

接下来,在三个博客分别禁用这三个插件、启用之前的那个插件。重复上述操作。结果:三个博客的邮件发送均成功了。

为了验证这个测试结果的准确性,我将Apache换成Nginx,然后再换回Apache,或者更换PHP版本(均在5.6以上),另外还在虚拟主机上面重复测试。结果均是如此。每次更换运行环境时,各个博客均在删除文件、数据库后重装。

综上得出结论:无论这三个插件中的哪个最先安装,都可能存在邮件无法发出的问题。但,即便是PHPMailer版本相对较老的CommentToMail,也是能成功发送邮件的。这个插件如果安装在PHP 5.5及以下版本的主机上,后台的配置界面会变形,但不影响邮件发送。

当然,还是有很多人,在使用支持SMTP的虚拟主机或VPS上,第一次安装插件就能正常发送邮件。

再顺便说一下:后两个插件发出的邮件,在手机端查看时,发现页面无法自适应。这是因为它们发出的邮件不支持自适应。这个邮件的页面是可以修改的:LoveKKComment在四个html文件中;Comment2Mail在plugin.php中。如需修改,可参照第一个插件的邮件模板(位置:博客后台—控制台—评论邮件提醒—编辑邮件模板)进行模仿。

三个插件的下载地址如下:

(三)图床问题

在2019年4月23日晚,开始有博主反映“新浪图床”防盗链了,部分博主遇到了上传到新浪图床的图片无法显示的问题,有博主开始替换图片。随即我提醒十年之约的成员,如果使用了新浪图床,请注意你的博客。当时,没人相信我说的话。4月24日,这一现象蔓延到了几乎所有使用新浪图床的博主身上,此时他们蒙圈了。

在这里我不得不夸自己有先见之明(斜眼笑)。其实这种先见之明是建立在已有的经历上。博客重建的时候,为了防止再经历2013年9月17日的意外,我决定将图片存储在第三方专业图床。可惜,某国的长城越建越高,一切的拦截“规则”均不透明、不公开、不可预知、变化无常。本博客引用的图片,也因此,于2017年9月2日上午开始,在中国大陆全部无法显示。因为我没有使用国际互联网的特殊技术手段,所以我无法从图床取回图片。由于没有备份(然后懂得了备份的重要性),部分图片就这样没了,部分图片我重新找来原图进行填补。

目前,我保存图片的方法是,在静态存储服务中开设存储仓库,通过浏览器在线上传图片,在接入全球CDN之前,使用其pages服务绑定的域名进行访问。图片所在的文件夹结构与目前使用的Typecho程序的附件路径结构完全相同,可以保证随时迁移回主机后台,并通过一条SQL命令一键替换所有的图片链接。2019年5月1日,我通过这种方式,帮助@汀彵の汐 博主搭建了一个图床。先帮助她把新浪图床的图片拉入本地,再导入图床。不过,因怕她不会用,我没有把她的图床的目录结构设计为Typecho程序的附件路径结构。

为了保证不浪费免费资源,并提高图片加载速度,我把每张图片都进行了高强度压缩,有不少图片从2M左右压缩到了200 KB以下,甚至几十KB。并且,为了减少对公共资源的计算能力及带宽的消耗,我给图床接入了全球CDN,由CDN存储全部数据,并全球分发,不再使用静态存储服务的pages服务。

备份图片时,在浏览器中访问自己的仓库,在线“打包下载为zip”,就可以下载到本地了。

当然,在未来,我可能会在博客引用一些视频数据。目前已经注册了Amazon S3,这部分视频数据我会上传到此。

我知道肯定会有人推荐什么oss、cos、七牛云、又拍云这些。这些我都用过。在不考虑实名认证和信息泄露的各种风险的情况下,我觉得这些服务当中又拍云的服务最好,因为支持FTP方式管理文件,我可以使用开源软件FileZilla的Linux客户端进行图形化文件管理,不存在其他国内对象存储服务针对非程序员群体“上传容易下载难”的现象。目前,账号也都在那放着呢,因为七牛云、又拍云等账号是无法注销的。另外,还有一个问题需要考虑:中国大陆以内的对象存储服务规则难以控制,已经发生的事情非常明显的表明,服务规则的变化会导致用户陷入被动。其中之一便是测试域名问题:目前提供测试域名且测试域名支持https的服务中,未来不一定什么时候出现像七牛那样回收测试域名,或者像又拍云那样关闭测试域名的https。

不过,我也考虑将部分数据上传到中国大陆的对象存储服务。我将使用手中当前正在备案的域名,在备案成功后进行连接。目前,又拍云已经冻结了我的账号,七牛云已经暂停了我的服务,腾讯云COS修改了服务政策。把中国大陆其他的几乎所有的对象存储服务平台全部注册了一遍以后,综合考虑之下,我计划使用阿里云OSS。阿里云OSS是个上传容易下载难的服务,那么多图片,对于不是程序员、几乎看不懂命令行的我来说,批量下载太难。而视频数量稀少,手动逐个下载即可。为了保险起见,我已经做好随时将视频数据撤离中国大陆的对象存储服务的准备,因为它只是个备用的服务而已。

我不针对谁,只是泛泛而说:某些人,你可以把你全部的图片、视频等放在国内的对象存储,你也许有能力用命令行工具批量管理他们,但这不是你秀优越的资本。无论每个博主用什么方式存储图片,都是个人选择,没有优越感可言。请不要秀你那自以为是的优越感,这只会刷低你的人品下限。