我的天

自从更新了WordPress 5.9以后，我的blog的自定义小工具在前端一律不显示，可以显示的只剩下系统自带的小工具，这到底是为什么呢？当我在后台用小工具实时预览界面的时候，我的小工具一个都没少，全部都有，为什么预览界面没有问题，实际上前端又有问题呢？5.9是我在春节放假之前更新上的，好长一段时间更新都没有任何问题，所以我根本没想过更新一个大版本会导致这样的事故。WordPress这个东西默认没办法回滚，要回到之前只有手动在服务器操作，而且还不一定兼容。到底是哪里出了状况？

可以肯定的是，5.9和之前的版本最大的区别可能在于全站都可以用可视化的方式用区块编辑，设计模板也不需要写代码了。但显然，对我这种人来说，我不太相信区块可视化编辑，我还是相信我的代码，但自从更新上这个版本以后，我的代码估计跟他们默认理解的有差异，所以就导致了这个问题。我觉得会不会是代码的某些钩子发生了变化，有些失效了，所以就导致我的自定义小工具失效呢？一开始我是这么认为的，但是当我研究过最新的那些模板后，却发现他们的模板里基本不自带小工具。我之所以要自定义小工具，是因为一般的模板、官方的模板通常不具备我需要的功能，所以我只能自己写代码实现。我从前的代码到底跟现在有效的那些语法在什么地方有冲突呢？我必须得找出来。让我觉得很困惑的是，如果是我代码语法有问题，理论上应该无论后台预览还是网站前端出来的效果是一样，也就是我的小工具应该都不起效才对，但实际上两个界面不一样。

当我好不容易找到了一些自定义小工具的脚本，当我把那往我的模板里贴了以后，的确一开始的时候是可以的，但改着改着就不行了。一开始我用的是正向修改，就是对比我自己的脚本跟可以显示的那些脚本，后来发现我觉得自己已经把需要改的地方都改完了，但还是没反应。于是我就开始反过来改，把我自己的东西贴到可以显示的脚本里面，结果发现依然没有问题的。起码可以这么说，核心部分的代码一点问题没有，但到底是什么地方出了问题呢？最后我修改到只剩下函数名称。一旦我把函数名称，东西就失效了。当我把没有失效还能显示的脚本贴回去以后，东西依然是失效的。所以到底怎么整才有效，怎么整会失效，到底是哪里的问题导致我的东西不能在前端显示呢？我花了一整天的时间都没找到原因，因为当我把可以显示和无法显示的脚本放在一起对比，除了自定义函数的名称以及缩进以外没有区别，而那个可以显示的脚本贴进WordPress里有时可以，有时不行。行就行，不行就不行，我写了那么多年的blog模板，无论是WordPress还是其它，从来没遇到过这种有时可以有时不行的情况。之所以这样，我猜他们是在某个地方用了缓存。那个缓存不是我浏览器的问题，因为这边我换浏览器问题依然存在，所以他们为了提高WordPress的运行速度，到底在这个5.9版本里做了什么呢？春节期间我一直没有主动修改，因为我希望过一段时间他们就会出一个新的版本解决前端和预览不一致的问题。如果我的小工具在预览界面也无法显示，我会心安理得。我不会像现在这样知道有问题，但完全不知道问题出在哪里。

可能当新版本出来以后会发现其实根本不是我的问题。

我终于做到了用模板的方式以及我自己的数据生成静态网页。暂时我还不知道，那些放进去就能用的格式类东西应该怎么在生成网站的时候顺便一并放进去。肯定是有方法的。虽然现在我手动挪一挪也无所谓。我觉得那大概是一个获取文件，然后解压到目标位置的操作。

jinja的模板套用比我想象中简单。在进行我自己的操作之前，我复制了网上的一个教程的代码，发现真的很容易。模板本身也可以通过浏览器查看效果，这个非常棒。从前BSP不就是干这种事吗？无论是可视化编辑的，还是纯代码操作的，其实都是在设计模板。现在我也终于明白，为什么相比于其它核心功能，在模板方面，我为什么总感觉自己有那么多的经验，因为实际上，我的确在那个方面花了很多时间。现在我已经不记得BlogBus的模板是怎样的了，唯一的印象是他们用的是代码编辑。他们会给你一些核心代码的封装，你可以把那些东西放在指定的某些模板里。封装的东西以外的部分，你可以通过css，或者js去控制，但是封装在里面的，基本上就是一个无药可救的状态了。所以有些格式你觉得你应该可以控制得了，实际上你却做不到，因为封装在里面，已经把格式给写死了。不知道如果我在css那里强行加个important，能不能扭转局面，但显然，当时我根本不知道有important这种东西。css的important的确威力无穷，但是important如果经常用，就会破坏规则，也不好维护。不得已我才会用，即便用了，一个css文件里面，通常不会超过三处。

以前的模板设计，我只是能处理一些格式上的东西。现在，我自己写脚本生成静态网站。无论前台后台，我都玩了，我得顾及前台的模板形式。也要考虑后台的数据整合以及数据的架构类型。在用jinja模板之前，我用的是人肉低端的字符串合并。虽然实际上，我做的低端操作也是实现模板的功能，但就维护来说，这实在太困难了！如果一个网页里面有很多数据是动态的，我就不得不把网页切分为很多份。切着切着，我都不知道自己切到哪里了。就数据生成效率来说。我的低端做法效率会更高，至于为什么，我不知道。9498个页面，我的低端做法转化需要22秒，jinja模板只需要32秒。这个不是偶然事件，在进行9498个页面转化之前，我先进行了一个只有几个页面的测试。结果跟大数据的很类似，低端做法，要比高端做法快1/3。这其中的原因是什么呢？据说jinja已经是个生成速度自称为“快速”的脚本，如果是另外一些，可能更慢。9000多个页面才多10秒钟，任何人都忍受得了。就维护的便捷性来说，低端拼接的维护成本随便超过10秒,所以用jinja模板绝对是值得的。这让我想起了我最在行的邮件合并，用word和Excel联合起来批量生产东西。我不知道其他人玩这个能溜到什么程度，反正这个东西一直都是让我引以为傲的，当然了，这种技能，也是后天逼出来的，工作使然也。

一些我觉得可能挺不容易的东西，居然很轻松就被我攻克了，感觉非常意外。接下来，生成搜索引擎所需的索引，估计不是件容易的事。生成索引，最重要的是思路，而过程不过是一些机械操作而已，我必须掌握好那个思路！

当我把电子书的列表从800多KB改成几个以后，整个静态网站的生成速度就从之前的120秒降为20多秒。20多秒的生成速度跟生成markdown文件没什么区别了。准确来说，生成速度更快了，因为少了一个markdown转换的过程，我猜可能是这样吧。虽然我已经绕了一个大圈又重新做了一个判断，如果我直接从点点转换成静态网站，而不是先格式化为wordpress标准的XML格式，估计速度会更快，但可以肯定的是，如果那样的话，我还是得做不少的判断，因为点点的文件里面不同类型的核心内容是不一样的。其实最简单的方法，是我生成wordpress格式文件的时候把分类继续放在分类，不把博客的名字放在分类，不把分类作为其中一个标签，相对来说这样的改动是最简单的。其实现在我绕了一个圈再回去，也没麻烦多少，因为那个标签是第1个，而我的判断是，如果找到了某个标签，就马上停止循环，所以虽然每篇日志的标签有n个，但判断第1个以后就结束了。就循环来说，没耗多少时间，只是代码会显得又长又臭。

近段时间我一直在纠结如何把手动输入的字典搞得好看些。除了好看，也要容易维护。最明白的方式当然是自己写键值对，但是那么多的引号，那么多的冒号，那么多的逗号，想想都觉得好疯狂。最整齐最不容易出错的方式是一行一个，但那样的话，好像有点奢侈了。所以有时我也搞不懂自己，到底是想节省空间，还是维护容易。

昨天晚上，我纠结一个问题，如果某个单词被我用作变量，在字典里那个单词又是一个key，同时这个单词也是个文本。有没有某个函数能把某个变量只当作是某个名字的字符串呢？如果这样，我的某句话就可以写得很简洁。否则的话，当我调用函数的时候，我就要把这个单词写一遍，当作字符串再写一遍。或者你会说，我直接把这个变量等于这个字符串不就好了吗？显然，我之所以把那个单词当作变量，肯定是因为其内涵跟字符串不一样。所以我试试是不是自己挖了个坑给自己跳呢？我明明不应该把这两个东西命名成一样。

有些时候我会问一些很弱智的问题，明明我是知道的，但是一下子就是想不起来。归根到底，我觉得是我的基础还不够扎实。在完成了静态博客的部署以后。我还没想好我是继续把Think Python那本书从我中断的地方继续看下去，还是应该从头开始，复习一遍，加深印象，因为那些很基础的东西在用着用着的时候，我觉得自己已经忘光了。所以到用的时候，我又得翻箱倒柜。那些东西，我明明应该已经掌握的。

现在的静态网站转换，我是用很低端的字符串连接整出来的。有些字符串是一成不变的，有些字符串是变量。我就在变量的之前之后把静态字符串断开，储存在某个文件里。最后就像穿珠子一样，把动态和静态的东西连在一起，最终合成一个网页。实际上，这是一种模板的思路。接下来，我要利用python的模板引擎，把静态的东西写在模板里，把动态的东西放在某些参数中。这才是我的网页转化应有的方式，但我不确定，这样的转化效率会不会比我现在的低端做法还要低。对我来说，那是一个未知的世界，我非常想，立马通过实践得出答案。

人在求知的路上会越发明白到自己的无知。

又花了一个下午的时间，我总算把超链接给搞定了。之前我就已经发现了那么个现象，如果我为一个图片做超链接，而那个超连接的默认的格式有悬停背景色的时候，无论我怎么整，图片下方都会有一条线，问题只是，那条线是粗还是细。昨天我遇到的问题是我需要在三个64*64像素的小图片上面做超链接。三个的图片完全没有文字，让人很绝望的无论我如何操作，那三个图片下面都有一个64*17的超链接方块，从颜色看来，那就是我在那个区域设定的超链接背景颜色。无论我怎么设置，分辨出来的东西还是会有那个颜色。之所以会是17，是因为我把文字的高度设定为16px。最终我终于记起了一条规定，如果之前你没有对某个元素设定规则的话，后面你可以重新为这个元素设定格式，但有些如果前面你已经设定了格式，后面，你又要推翻这个格式，并把它变成无格式的话，这是不可能的，除非我祭出大招“!important”。我在某片区域对超连接设定了背景颜色。但是在某些特定的情况之下，我又要把背景颜色去掉，单纯的background-color:transparent做不到的，但假如暴力的“!important”就可以。要去掉那个背景颜色，在不加“!important”的前提下，我把超链接的颜色设置为和那片区域背景颜色一致，所以颜色虽然存在，但就不会被看到了，但这么低端的做法CSS维护的时候就麻烦了。这个让我纠结了一个下午的事从前我也就结果，但因为太久远，已经忘记了。

昨天我匆匆把翻新过的COLOR3模板上线，感觉还不错。其实我也没改什么，主要是一些功能完善以及格式上的东西。我还专门找了一个色卡的网站去研究到底背景要用什么颜色。最普通的是浅灰色，但是那实在太普通了，然后我把黄色，橙色，粉色，蓝色，绿色，这几种很浅的马卡龙颜色都试了一遍，感觉有点怪怪的。说不准到底是为什么，反正就是和主体区域的白色混搭起来会有点刺眼。另外一个让我纠结的就是版头的颜色，之前我用的是纯黄色和纯橙色。这两个颜色加起来会让人有酸酸甜甜的热烈感觉，但是跟那些浅色混在一起，会莫名地让人觉得刺眼。以前模板的背景颜色是白色，同样也是橙色和黄色之所以没感觉刺眼，是因为我在所有板块外面都加了5px的边框，而这一次我把5px的边框全部都去掉了。之所以要去掉边框，是因为某一次，不知道谁留言说，我那些黑色的边框让人觉得辣眼睛。看到那条评论的时候，我马上实验在网页上实时修改掉那些边框，但只是单纯去掉边框，就像PS掉大熊猫的黑眼圈一样，怪怪的。当我对版头和背景颜色一筹莫展的时候，我顺手写了个纯黑色背景上去，出乎我意料，效果非常好，简直是让人有惊艳的感觉！外围黑色让核心部分的内容更加突出提神。因为高对比度，5px的黑色边框根本不需要存在。除了黑色以外，我也在网站上实时测试了其他颜色，发现用深色效果都挺好，所以我可以根据心情，随便换颜色。比如喜庆的时候换个纯红色。几乎可以这么说，只要是偏深的颜色都适合当我的背景颜色，因为主体区域我用的是鲜艳的颜色。

我不是一个美工，我总喜欢把东西弄得很整齐而已。真正的美工大概都很在乎意境，所以我永远都到达不了他们的境界。

时间用在查找代码上去得特别快。感觉问题还没解决，时间就已经溜了。大体上看，就只有几个大问题需要解决，但实际上那些东西是完全没有头绪应该怎么去做的。昨天我花了一个下午的时间去处理comments.php。那个模板用来设定在哪里显示评论，哪里显示评论框，这其中还不包括评论框里的具体格式。看上去这是非常简单的事情，实际上，还是要考虑好几个问题，但显然，10年前，做那个模板的时候，我没有在comments.php这个问题上纠结，我顶多是往里面放了一些我设定好的CSS，所以那个部分的逻辑到底是怎样的，我没去修改，沿用的是某个模板。实际上我用的那个模板是不是标准的，我也说不准，因为我实在不记得当年我用作改造的模板是哪一个。因为通常WordPress的官方模板都非常简单，甚至可以说简单过头，于是你不知道该如何在那个的基础之上改造。大概之前，我的那个comments.php测试的时候，我只是考虑了一般情况。但除了正常情况，WordPress里还是会有一些极端情况，比如说某篇日志被设计为密码可见。无论是日志还是评论，在输入密码之前都应该是一片空白。那个模板就很神奇，日志部分已经是提示输入密码才可见，评论部分直接不显示就行了，但实际上，那里居然在会提示一次输入密码才可见，显然这就是画蛇添足了。让我纠结的时间最长的是嵌套格式的代码。因为正文部分我分为左边和右边，左边是文章的主体以及评论框，右边是边栏。这两个板块，一个是float向左，一个向右，一旦代码嵌套不合理，右边的边栏就会进入左边，又或者直接消失，也有可能是因为缺少结束嵌入代码，所以网页底部的东西飞上去了。要解决这些结构格式上的问题，就首先要搞清楚，那些php代码的开始结束位置。比如说某篇文章设定了不允许评论，但是对于已经有的评论，你还是要把它们显示出来，然后在最后一条的那里显示不许再评论。之前我根本没有测试过不许评论这个功能，显然当我在撰写日志的时候设定了不允许评论以后，之前的模板相应网页会出状况。而之所以这样，是因为默认的模板里面我只在if下面添加了足够多的格式结束标签，在else里面没写。不许评论就是else的部分，判定函数应该是评论是否开放，但实际上，不允许评论这句话从结构看来，应该是放在评论列表的最后。这样的风格才会统一，因为有些时候，不许评论之前可能文章已经有评论了，如果硬生生地把那放在允许评论就有评论框，不允许评论评论框消失并写着不允许评论，那样就太生硬了。

我花了几乎一个下午的时间去处comments.php，最后终于搞清了里面的逻辑关系。为了让那些if跟else，以及endif能更好地维护，我在上面做了很多注解，基本上每个的那里我都会写清楚了对应的是哪个，同时我也进行了缩进。那么以后找的时候就不会那么头痛。如果写代码的人用的是大括号，显然就不需要纠结endif对应谁。我也不知道为什么那个人不用大括号，在没有标注也没有缩进的情况下搞清那些东西真的好费神。

纠结不是毫无用处的，这会让我变得更强大。