基本上每过一段时间，就会对自己的Wordpress主题和代码进行一些优化，很多时候是因为系统版本的升级要进行一些代码的微调，还有一些则是之前忘记优化的地方，现在顺便一并给做一下，写这篇文章是怕忘记了这两天完成的代码调整。

主要影响的代码是网页版主题V3.2-V3.3的变化，涉及的升级优化包括下面内容：

• 新版本的WP修改了编辑器，老版本编辑器以插件的形式继续存在
• 新增了插件P3用来检测插件性能，用完就禁用或者删除就好
• 改用WP Fastest Cache来进行缓存优化，并进行一次清理
• 修改了JS调用方法，去除了版本号的方式
• 修改了Ngnix的vhost的配置文件，增加了头部缓存设置
• 增加了更多浏览器USER-AGENT判别（在插件部分）
• Google Analytics插件设置，将代码插入到页面底部
• 将Lazy-load的一段代码直接插入到footer，减少一次文件调用

从优化以后的结果和测试来看，现在后台的插件只有两个插件会影响前端页面的调用，将影响减少到最少，然后PageSpeed的评分也到了98分,Pingdom评分到91分，剩下的几个优化点我懒得去弄了，包括优化CSS.JS之类的，我没有压缩CSS是为了更方便阅读，压缩掉几个字节其实意义不大，所以就留着好了，包括小图片也是一样的道理。

中间出现了两个小插曲，第一个是修改jQuery到外部指向的时候弄错了版本结果导致在IE下显示异常，差点让我整个回头弄一遍，还有就是弄完所有之后，发现移动端首页图片不见了，后来才想起来是因为修改了Lasy-load的代码的缘故，在移动主题中也加上就好了。

就先暂时这样吧，应该已经在我能力所及优化到极限了~

昨天晚上在WordPress后台的时候，突然看到一个叫做CDN Enabler的插件，点开一看，原来是一家叫做KeyCDN公司做的插件，取了这么一个含糊的名字，难怪我莫名其妙装上了，这也算是一种不错的营销方式吧！既然这样，不如就来看看怎么用好了！

其实，国内也有很多CDN的服务商，比如：阿里云、七牛云什么的，不过由于政策监管的关系，这些网站无一例外的需要进行ICP备案，我这个域名一直放在国外，所以自然就没有进行 备案了，这个叫做KeyCDN的网站在自己网站上吹的各种屌，我们况且试试看好了。

一、注册KeyCDN账户

这个就不用解释了，大家按部就班注册就可以了

二、添加Zone

登陆到KeyCDN的后台，在Zones的菜单下，新增一个网站即可。一般默认采用pull模式就可以。设置完成之后，你就可以在后台看到一个叫做 axmemo-abb7.kxcdn.com 的网站。接下来系统会进行缓存操作。如果你的网站是http模式访问的，那么等缓存完成之后，你就可以直接通过浏览器访问这个地址了。

三、添加Zonealiases

在这里我们要对之前申请到的zone增加别名，比如新增一个cdn.axmemo.com 的CNAME解析，指向到前面申请的那个 axmemo-abb7.kxcdn.com 的网站上面。这个操作需要在你的DNS服务器上进行操作，至于在KeyCDN上的操作，只要填写以下就可以了。等DNS生效之后，你通过命令行ping一下，看到跳转就没有问题了。这时你可以用cdn.axmemo.com 来进行网站的访问。当前前面这一切都是基于你采用的是http的方式访问。如果你和我一样使用了lecsencrypt的证书，那么你同样要为你的CDN网站也进行相应的SSL配置，使之支持https访问请求。

四、增加https支持

这时候我们要重新回到Zones设置的地方，点击之前我们配置好的Zone，然后选择Edie，然后再打开Advanced 模式，我们这时候就可以看到SSL选项了。这里，我们要选择 lecsencrypt模式，就是现在网站用的这个免费ssl证书的模式（使用lecsencrypt证书必须启用别名模式，也就是前面的第三步操作，否则证书会被判定不安全）。等设置完成之后，进行保存，之后系统会自动再进行一次配置操作，等待它完成就可以了。等SSL证书生成完成之后，你就可以通过 https://cdn.axmemo.com 来进行访问了，顺便看一下证书内容是否正常。

五、配置Wordpress后台

在WordPress后台启用CDN Enabler插件。然后在CDN URL里面输入之前配置的别名地址，也就是，cdn.axmemo.com，然后单选框激活HTTPS支持。至于下面的两个框，API KEY你可以在keydns后台的Account Setting 下面的 Authentication Settings 里面可以找到，你选择刷新一下API Key就可以获取了。而Zone ID，可以在之前的Zones管理中找到，保存设置就可以了。

六、验证系统是否正常运行

在激活CDN插件之后，你可以访问一下网站的首页，然后查看一下源代码，你就会看到在头文件和很多图片调用的地方，已经改成了CDN地址，这样就说明你的CDN已经完全生效了。

经过上面这么一番操作，终于完成了CDN的配置操作并且正常运行了，但是最后我并没有选用keyCDN这家网站的服务，因为经过我的测试，这家网站到大陆的主机质量并不是特别稳定，而且在不同网络环境接入的时候，效果不是特别好。总体网络质量还不如我现在正在用的CN2线路的VPS主机，所以设置了以后反倒速度还更慢了。

不过怎么说也是折腾了大半个晚上，总要写点东西下来作为纪念的，也希望这篇文章可能对你会有所帮助，今天就写到这里，下次见！

之前也对自己的网站进行了几次优化，其实网页的功能代码已经被精简的差不多了，所以按理来说打开页面时间应该会蛮快，但实际使用起来还是会有些卡卡的。今天在逛网站的时候，发现了WordPress中有关emoji表情的优化，试验了一下效果很好。

简单来说，就是WordPress在头文件中，会加载一个s.w.org的站点，然后去调用其中的图片来选择文章内容以及评论中的标准emoji图标，而这样的访问请求势必会影响整体站点的加载速度，而且这个地址国内是无法访问。

解决的办法很简单，就是直接禁用emoji功能就好了，只要在当前主题的functions.php中，加入下面代码进行屏蔽就可以了。

remove_action(‘admin_print_scripts’,    ‘print_emoji_detection_script’);

remove_action(‘admin_print_styles’,    ‘print_emoji_styles’);

remove_action(‘wp_head’,        ‘print_emoji_detection_script’,    7);

remove_action(‘wp_print_styles’,    ‘print_emoji_styles’);

remove_action(’embed_head’,        ‘print_emoji_detection_script’);

remove_filter(‘the_content_feed’,    ‘wp_staticize_emoji’);

remove_filter(‘comment_text_rss’,    ‘wp_staticize_emoji’);

remove_filter(‘wp_mail’,        ‘wp_staticize_emoji_for_email’);

add_filter( ’emoji_svg_url’,        ‘__return_false’ );

相关技术资料，感谢水煮鱼提供整理，原始链接在：这里。

这两天的WordPress折腾之旅即将画上尾声，前面根据Google的网站分析工具，进行了不少的优化和修复，不过Insights测试的分数还是没有很高，但也无所谓了，最后要进行优化的，是其中图像存储和显示部分。目的是通过对WordPress的服务和图像的优化，提升页面响应速度和用户的访问感受。

优化的参考来自于Google 的PageSpeed，里面可以对当前页面提出了很多优化建议，经过我一阵折腾以后，还有下面一些问题是无法解决的：

• 网页中的JS和CSS嵌入：这部分问题在桌面版上还好，只是两个jquery和一个CSS，我之前把其他几个小的CSS都进行了合并，如果全部嵌入页面显然不现实。这部分可以通过服务器缓存来进行提升速度。不过在移动版的网页中，由于又调用了遮罩脚本，所以多嵌入了几个js代码也没办法了。
• 网页上图片的优化：这部分工作，我是用WP的插件来完成的，经过对比，我最终选择了“Compress JPEG & PNG images”这款插件。注册完成以后，每个月可以进行500张图片的优化，而且无缝的整合入媒体库中，还可以对历史文件进行优化，其实，你只要选择优化大图就可以了，所以每个月的额度绰绰有余。不过实际使用下来，相较我用PS保存的文件，只有10%左右的优化空间。
• 使用浏览器缓存：这个需要在nginx上面进行新的缓存策略设定，我开始以为是设置在nginx主配置文件里面的，后来发现是要设置到vhost的虚拟站点配置文件里面，设置完成之后，重启一下服务就好了，为了方便调试，我还是把css的缓存时间给设置小了一些，而其他的都设置的比较久。
• 缩减CSS：其实CSS本身尺寸就很小，所以无所谓缩减了，因为缩减完成以后，在阅读性上面会差很多，我还是喜欢按自己的习惯来写。

另外，就是写一下关于Lazy load的设置，这是一个针对图片显示的插件，在WP上用的很多的一个就是这个，另外一个就是 Infiniti Scroll，不过因为我设置了分页，所以的话我觉得只要配置Lazy load就好了，有很多不同的Lazy load插件，其实只要选择最简单的那个就可以了，所实现的效果就是：当页面需要显示图片的时候再进行加载，然后用fade的方式进行显示，感觉效果还是不错的。

Lazy load的原理是先加载一个1*1px的透明图片，等需要的时候，再加载整个图片内容，我在实际使用的时候，在PC版本上面显示的很好，但是在移动版本上面发现完全没有用，我开始以为是Safari没有捕获到视窗口大小，后来发现是我修改了标准的文章展示模版，在标准模块之前提前加载了图片，导致插件的代码没有对这张图片产生影响。解决的办法就是手工把Lazy load的属性代码添加到手工写的代码当中，就好了。

后来又发现一个问题，在模拟页面加载的时候，手机端网页会先出现很长一块空白然后再进行回缩，以我聪明的才智，发现是css中的一个img属性出现了问题，默认的情况下，img的属性是 width:100%, height:auto; 结果那个1*1px的透明图片在撑满100%宽度的时候，高度也就变成了正方形大小。解决办法就是自己再写一个透明图片，宽度和当前题图一样，高度依然是1px，然后用来替换题图的加载。这个问题在PC版本里面并不会出现的原因，是因为在PC版的CSS中没有对img做这样的限制。

这次的WordPress终于告一段落了，这几天写的代码好像比我之前一年写的都还要多，下次不知道什么时候才有精力再来折腾这个了，要不弄个微信小程序玩玩？

最近这段时间，又心血来潮的折腾了一阵子WordPress，其实前前后后写博客也有十多年的时间了，从一开始的各种兴奋折腾，到后来的慢慢归于平淡，就像主题也是越变越简单，其实发帖也变的越来越少了不是么？所以其实已经好久没有折腾WordPress的插件了，作为全球最大的博客应用程序，有好多的开发者在此基础上进行了优化和改进，今天就给大家推荐一下当前自用的插件。

• AMP：这个不用说了，前面几天我折腾就是为了这个插件
• Antispam Bee：用于对垃圾评论进行屏蔽，这个反正一直都在用
• BackWPup：进行网站的全站文件和数据库备份，支持Dropbox存储
• Latest Comments：显示最新评论内容，可以用于首页展示
• Disable Google Fonts：禁用Google字体，加速后台管理页面显示
• Google Analytics Dashboard for WP：这个不用解释也知道
• Google XML Sitemaps：这个也不用解释了吧
• MobilePress：针对移动设备访问，设置不同的主题
• Server Status：在后台方便的查看系统参数和状态
• WordPress Importer：官方要求安装的导入插件
• WP Super Cache：用的人很多的快速缓存功能，摸索中
• WP-Optimize：WordPress的优化插件，功能不多但实用
• WPJAM：国内用户开发的优化插件，搭配微信机器人使用
• 微信机器人：支持微信公众号和Wordpress的对接功能

其他的一些插件我就暂时没有在用了，比如：图像优化之类的功能，因为毕竟网站上面用的图片也不是很多嘛，基于能简洁则简洁的想法，都没有使用。今天的文章就这么短，希望上面的推荐能给你带来参考。

在这个端午小长假里，我花了整整一天的时间，为我之前的一条数据库指令所造成的后果进行补救，这就再一次教育了我们，没事千万别乱动数据库。幸好，我每天进行了数据备份，所以可以有足够多的版本来进行重建和对比，最终找到解决方案，但整个过程还是付出了惨痛的教训。下面就说说事件的经过，让大家开心一下。

事情的起因还是之前的AMP页面结构优化，我发现其实只要指定了特色图片，AMP就能自动捕获到文件。但是，因为之前就没有设置特色图片，所以一直找不到。于是，我花了整整一个上午来研究如何批量的给历史文章重置特色图片，但后来，又突然发现，其实只要文章里面有图片，就能捕获到了，但为什么我一直不成功呢？经过一天时间的抽丝剥茧，终于把问题弄明白了，里面涉及了好几个和Wordpress有关的讨论，一并展开说明：

1. 关于文章ID不连续的问题：

之前，我们看到过关于Wordpress的文章标题编号不连续的讨论，很奇怪的是为什么Wordpress在生成文章页面的同时，会将上载的图片也生成一个post_id，这是一个让强迫症患者很不爽的做法，但是好像也没什么特别好的办法。

后来有一天，我看到了一个关于关闭Wordpress自动保存的帖子，帖子的里面除了说明加入一些函数以外，还有下面两条SQL代码：

• DELETE FROM wp_posts WHERE post_status = ‘inherit’;
• DELETE FROM wp_posts WHERE post_status = ‘auto-draft’;

就是前面这条红色的语句，让我陷入了万劫不复的深渊！

2. 关于文章和图片的关联关系：

在后台的媒体库里面，我们可以看到，图片有一个属性，是是否和文章进行了关联，在后台的发文环境中，如果你在编写过程中上载了图片，这个图片就会被认为被上载并关联到当前文章里面。只要有这样的属性，就可以用很多工具来进行缩略图生成，或者是特色图片的指定，这一切都是依赖于图片和文章建立起关联关系的前提。

但是，特么我发现我的媒体库里面，一张图片都没有！即便用扫描目录批量导入媒体库，同样没法建立起图片和文章的关联，这是我今天折腾的最核心的问题。

而后来，我发现，正是因为我运行了前面那个红色的语句，导致了媒体库的清空，以及图片和文章关联的断裂。其中图文关联的原理如下:

• 系统正常发帖，生成帖子post_id和图片的post_id
• 帖子ID的状态是Publish，图片ID的状态是inherit
• 图片ID有一个属性是post_parent，会指向帖子的ID
• 帖子ID的post_parent，则显示为0

我之前那个致命的操作，就是在于删除了状态为inherit的post_id，然后就一次性把图片以及图片和帖子的关联关系全部删除掉了！杯具！

3. 重建以后的缩略图恢复：

由于我前面花了一个晚上配置短链接，所以恢复到老版本网站简直是悲剧，所以只能从老板网站中提取状态为inherit的post_id，然后导入回正式数据库中进行融合。在本地重建了一份老的数据库，发现受影响的有近700多条！

然后就进行逆向操作，把状态为非inherit的post_id全部删除，然后改一个表名之后导出，然后再在正式系统导入，再将数据（不含结构）迁移回正式表。

结果，后台的媒体库是能看到图片名了，但是缩略图没有了！这时候我特么的去找了一个重建缩略图的插件，结果又让自己悲剧了一把，重建缩略图导致把我的文件几乎全部清洗了一遍，我只能再次在服务器端删除所有文件，用备份再恢复一次。

看来还是要从数据库里面找问题，后来才发现，受到影响的除了wp_post表以外，还有一张wp_postmeta表也受到影响，这里面受到影响的字段主要是：

• _wp_attached_file
• _wp_attachment_metadata

这两个字段定义了图片和文章关联信息以及缩略图的特性，就像前面所说的，要用老数据恢复，就必须把自动生成的缩略图毁掉，重新恢复成老样子。经过对老数据表的清理，然后重新汇入到新的正式库中，终于，媒体库里面可以看到缩略图了。

这样一来，数据库后台的修复才算是大功告成，眼泪已经流了一地。

– – – 关于AMP的优化 – – –

最后说一下，在昨天基础上针对AMP的优化，既然有了图片和文章关联信息，之前我们所说的AMP插件就可以自动获取到图片信息了，不过这里有一个小问题，就是前面所说到的image的属性中必须宽度大于700px，而我的题图只有500多一点，这里的话就需要手工修改AMP插件的代码了，把系统读取的宽度改为等比例缩放以后的固定值，像我的网站题图缩放以后就是700*282的尺寸，要修改的文件位于：

• amp/includes/class-amp-post-template.php

具体怎么改我就不详细说了，看一下找到对应的字段直接写死固定值就可以了，然后再用google提供的结构化工具验证一下（在这里），就可以了！

前前后后折腾了一整天，也算是在端午节给自己的大脑做个头脑体操吧，还好最后的结果是完美的，以后再也不敢乱动数据库了。

这个事情首先要从AMP说起，AMP的全称是“Accelerated Mobile Pages”，它由AMP HTML, AMP Runtime 和AMP Components三部分组成，具体细节我们在这里就不展开讨论了，主要的意思就是它可以通过对HTML的精简，实现在移动设备上的高速加载，而另一方面，Google作为全球最大的搜索引擎，会对AMP网页进行优化抓取，并将AMP的页面结果缓存从而是实现对用户的更高效的推送和展现。

这些咱们都先放到一边，太高级的事情不用做过细的研究，我们可以在Wordpress的后台找到一款AMP插件，使得整个网站实现对AMP的支持，而激活这个插件以后，你可以从帮助中找到你的AMP站点链接。如果你是伪静态模式的话：

• 如果默认的页面链接是：http://server/page.html
• 那么该页面的AMP的地址就是：http://server/page.html/amp

你打开后面这个链接之后，就会看到一个干净无比的页面，也就是前面所说的实现在移动设备和网络环境中的加速功能。amp的站点链接同样可以被google所捕获到并收录，而我也就是在这个时候发现的问题。

前两天，在研究Google Webmaster Search Console的时候，看到在AMP的统计信息项中出现了“结构化数据元素无效”的非严重问题，作为强迫症患者，一定要去一探究竟没错，于是点开某个单独的告警页面，可以直接调用Google的结构化数据检测工具来进行检测，然后出现了下面错误：

关于结构化数据的讨论，在这里也就不展开了，简单的来说，结构化数据不是给人看的，而是给机器，给搜索引擎看的，优秀的结构化数据可以帮助搜索引擎更快的识别页面所包含的内容信息。

还是让我们回到这个报错本身：

• A value for the logo field is required.
• A value for the image field is required.

这是一个最终的访问页面，结构化数据报错告诉我们，缺少了两个结构化数据信息，一个是logo，一个是image。其实解释一下就是，缺少了一个网站的标志信息，以及当前文章页面的图片介绍。

后来，我在网上搜索解决方法，发现那个logo的报错，可以通过Wordpress 管理后台中的“Appearance-Customizing-Site Identity”，找到那个关于Site Icon定义的地方，上载图片之后就可以解决。不过那个image的缺失却没有解决。

再后来，只能到这个插件的开发者网站中，寻找相关说明。终于找到了结局的办法，其实就是需要修改当前主题中的functions.php，加上下面代码：

这些代码在前面提到的开发者网站中也有提到，为了考虑页面布局，我就直接用图片的方式插入了，大家直接去那边拷贝代码吧。

但是有一个地方要说明，就是按理说，这个image的结构化信息，最好是取当前页面的题图会比较好，但是，这个结构化验证工具对于这个image的宽度有最低要求，就是宽度必须大于700px，我看看我自己的文章题图，只有500px多，于是就干脆直接指定了一个静态的image链接地址作罢。

其实，wordpress上面也有类似的插件来实现相关的功能，你可以在后台的插件管理中搜索一个名叫“Schema”以及“Schema Default Image”的插件来解决这个问题，不过我觉得这个插件插入了太多的结构化数据，想想还是自己手工来写好了。

好吧，今天的帖子就写到这里，大家下次再见~

其实给网站加上SSL证书这个事情，其实以前就想做了，但是一直懒着。前两天看到有朋友说起微信小程序的事情，才又动起了这个念头。本文是记录了整个过程，以备以后参考，也希望能给其他朋友提供帮助。

1. 安装cerbot：因为虚拟主机是CentOS7，所以直接运行下面代码：

yum install epel-release

yum install certbot

2. 配置nginx准备验证：需要在虚拟主机配置文件里面加入一个目录进行验证，在我的网站上是在axmemo.com.conf 的文件里面

location ^~ /.well-known/acme-challenge/
{
default_type “text/plain”;
root     /home/wwwroot/axmemo.com/;
}

location = /.well-known/acme-challenge/
{
return 404;
}

3. 重启nginx，开始申请证书：根据向导完成证书的申请操作，申请完成的证书会位于/etc/letsencrypt/live/ 目录下面

certbot certonly –webroot -w /home/wwwroot/axmemo.com -d  axmemo.com

4. 修改nginx配置，改为SSL访问模式：在配置文件里面进行如下修改

listen 443 ssl;

….

ssl_certificate      /etc/letsencrypt/live/axmemo.com/fullchain.pem;

ssl_certificate_key  /etc/letsencrypt/live/axmemo.com/privkey.pem;

5.对原有的http访问增加301跳转：

server
{   listen 80;
server_name axmemo.com www.axmemo.com *.axmemo.com;
return 301 https://$server_name$request_uri;    }

6. 重启nginx，修改Wordpress配置：进入Wordpress后台，将站点的地址改为https://axmemo.com，然后再重新启动一次nginx

7. 修改数据库内部静态链接：把原来的http指向全部改为https就可以了。

8. 测试自动刷新证书的操作：运行下面语句

certbot renew –dry-run

9. 添加定时运行脚本，每周运行一次：

sudo crontab –e

然后添加下面内容

01 1 * * 0 /usr/bin/certbot renew >> /var/log/ssl-renew.log

06 1 * * 0 lnmp nginx restart

10. 到SSL检测网站去看看安全情况：咦，怎么是B等级？

https://www.ssllabs.com/ssltest/analyze.html

下面的步骤，是用于在网站上开启SSL的强加密步骤：

1. 生成Diffie-Hellman组：

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

2. 添加配置文件：也放到vhost目录下，nginx会自动加载，随便命名一个conf

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# disable HSTS header for now
#add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload”;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

3. 重启nginx，然后再试试检测看，搞定~

参考的文章：这里，还有 这里，以及这里！