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

事情的起因还是之前的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”的插件来解决这个问题，不过我觉得这个插件插入了太多的结构化数据，想想还是自己手工来写好了。

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