我的天

花了一整天都没搞懂的事情，突然晚上用了大概半个小时就开窍了。当然，其实功劳不在那30分钟，而是在前面的一直摸索积累。郁闷得要死要活，当然要总结一下经验，免得老是掉坑里。

上回说到自定义小工具时灵时不灵。通常，当我把网上的自定义小工具脚本（1，2）贴到functions.php，然后在小工具那里把相应的东西拖放到合适的位置，刷新前端就能看到。当我在functions.php修改代码，修改到一定程度的时候仍然可以看到，但改着改着，前端就没了。当我把改到最后还能显示的版本再贴回去，依然没反应。这到底是什么问题呢？后来我意识到不会是某些默认参数缺失导致。我不知道为什么在小工具的后台预览就没有这种缺失问题，但前端显示就有。非常有可能刚好碰上5.9前端和后台默认参数不完全一致。当我把所有之前空着，理论上应该自动带入默认参数的函数都补充为默认写法之后，奇迹发生了！所以折腾了一大轮非常有可能是5.9删掉了某些前端的默认参数，因为他们从这个版本开始可以使用区块进行全站模板编辑，既然所有东西都源于区块，所有东西都不是从自定义代码开始，在区块那里写入默认参数自然就不会有小工具默认参数缺失的问题。但是，他们万万没想到我这个从WordPress大概2.*版本就开始用的老土鬼依然在用很久很久很久很久很久以前的自定义小工具写法，而当时，当自定义小工具参数缺失时估计有默认参数补全……

要创建一个自定义小工具，可以在模板functions.php文件里通过代码方式实现。下面讲的只是创建小工具本身，有些模板没有自带容纳小工具的箱子，导致创建好的小工具后无法让其在前端显示，这里就不继续探讨了。

写一个自定义小工具主要有3步，其中第1步里有4个步骤需要完成：
1 创建小工具
1.1 设定小工具基本参数
1.2 设定小工具前端输出
1.3 设定小工具后台更新参数
1.4 设定小工具后台输出
2 注册小工具
3 激活小工具

转化为代码大概是这个样子：

class widget-ID extends WP_Widget //创建widget，widget-ID必须唯一，必须小写
{
	public function __construct() //widget基本参数设定
	{
		parent::__construct(
			'widget-ID',
			__('widget name'), //后台widget标题
			array('description' => __('widget description'),) //后台widget描述
		);
	}
	public function widget($args, $instance) //widget前端输出
	{
		echo $args['before_widget'];
		********** //要输出的全部放这里
		echo $args['after_widget'];
	}
	public function update( $new_instance, $old_instance ) //widget后台更新设定
	{ 
		return $new_instance; //public function form里更新了这里就更新，因为form没有内容，照抄默认写法
	}
	public function form( $instance ) //widget后台输出
	{
		echo '<p class="no-options-widget">' . __( 'There are no options for this widget.' ) . '</p>';
		return 'noform'; //因为是自定义小工具，参数都已就位，照抄默认写法
	}
}
function mi_register_widget() //注册自定义widget，mi_register_widget函数名随意
{
	register_widget('widget-ID1'); //多个自定义widget在这里全部列出
	register_widget('widget-ID2');
	register_widget('widget-ID3');
}
add_action('widgets_init', 'mi_register_widget'); //激活已注册的全部widget

之前我遇到的时灵时不灵根本原因在于public function update( $new_instance, $old_instance ){}和public function form( $instance ){}虽然我的确不需要表达什么，所以{}直接留空，于是就撞板了…… 所以这两个组后台参数设定可能对自定义的各位来说的确没啥用，但默认写法还是得继续保留，不能留空。

如果有人像我那样在WordPress 5.9之前自定义小工具好好的，但5.9后就前端不显示了，按照上面步骤对照修改后，还需要在后台小工具页面把之前失效的小工具从箱子里删除，然后重新拖放小工具归位。相信我，这个步骤非常重要！！！虽然看上去还是那个模样，但实际上拖放一圈的确就能解决修改代码后，前端无论如何仍然刷新不出来的问题。

撞板是痛苦的，但摸爬滚打后重新站起来的感觉非常好！

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

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

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

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

昨天我实现了前天还不能实现的功能，用起来果然很爽。Power Query拯救了用vlookup公式导致源数据界面输入卡顿的问题。关于vlookup的卡机，据说用Power Query或者Power Pivot都能实现，而且据说PP的效率比PQ还要高。PQ现在我知道应该在哪里写代码了，但PP的DAX到底在哪里写，至今我还没找到。相对来说，我觉得PQ界面的按钮多一些。PP的按钮感觉跟数据透视表很类似。这就意味着，厉害的功能就隐藏在普通的东西之中。PP跟PQ比起来，函数的数量少了很多。用过的人都说，PP要比PQ简单，PQ就像一个谜一样。

前几天当我搜索，PQ教程的时候，发现了里面居然有递归。在谈递归的时候，把迭代也放进去了。迭代跟递归有什么区别现在我还不知道，但我知道递归和循环有什么区别。当某个函数的控制可以把判断和循环都用上的话。再加上700多个已经事先设定好的系统函数。PQ要实现一些神一般的功能显然是理所当然的。只有你想不到，没有它做不到，但前提是，要做到某些功能，光靠可视化版面，根本不可能。要在高级编辑器里自行折腾，或者在自定义的地方选择性折腾。光靠鼠标点击按钮是没办法把PQ的函数层层套用的，没办法一次性套用多个函数，某些功能就比较难实现了。对小白来说，要掌握所有可视化的按钮，尚且没那么容易，但是真正的高手，是必须自己写码的。

PQ用的是M语言，貌似我在VSCode的插件里面没找到相关的东西。里面有DAX的插件，可以自动补全和语法高亮。M语言更需要这种插件，因为光是函数的大小写就会把人搞疯掉。英语输入默认全部都是半角，但是如果我们的脚本里面还有中文，那就意味着中文跟英文得不断切换。光是逗号这种东西就会搞死人。而且我们的脚本里面，还不可能不出现中文。的确，函数可以起英文名字，但是，要处理的数据的列名，必然有中文，因为表格的内容有中文。我不知道那些写码的人是如何克服这种中文英文切换标点符号的问题，反正我是觉得，双引号，逗号，小括号这种东西经常让我很烦恼。不过幸好，据说，Office 2016以后的PQ，在写码的时候有自动补全功能，的确现在我的Microsoft 365可以这样，不仅仅是函数可以自动补全，连变量也可以自动补全。我不知道其他人写码的时候是怎样的，反正自从我习惯了python以后，我实在不能接受没有规范缩进的脚本。也正是因为有了python的习惯，所以我也默认把缩进从tab换成了4个空格。习惯了在VSCode里4个空格是4个圆点，现在PQ里没有这种东西。总让我觉得很不智能。

所有office文件都可以修改后缀，变成一个压缩文件。里面你看得懂或者看不懂的东西实际上就是数据以及你执行的步骤，所以PQ虽然有可视化界面，但实际上，它的高级编辑器让我觉得，那东西还原出了office软件数据处理的本身。

今年我的计划是学R语言，但实际上，我迷上了python，接着现在，我又迷上了M语言。

习惯了用python以后要我写php的代码，我各种不习惯。为什么变量前面要加个“$”？为什么要写“{}”这种东西？为什么居然可以乱七八糟不缩进？python估计是不用数组表示东西的，但实际上，在历遍的过程里有数组，而php这东西貌似不像python那样分列表和元组，字符串是肯定有的，字典可能也有，但这个我不确定。在计算某个东西长度的时候还得纠结到底我要分解到什么程度，我不就是要计算一下数组里元素有多少嘛。可能是我使用的方式不对，print_r的确把数组表达出来了，但一坨东西各种嵌套，你给我个缩进好不好，我都分不清谁是谁了。python里计算长度用len()，我已经用得很熟练很爽了，到php里变成了count()，如果数组里还有数组，也要算出长度还得加参数。不得不说，数组这个东西挺让我头痛。记得从前学C语言的时候我就挺烦数组这个东西，我感觉自己一直没学好。当我接触了python，让我明白到其实数组不就是那些东西，为什么就非得用索引号把他们定位表示呢？直接把数据按照数组的排列方式直接表达出来是可以，json就是这么玩的，那是一个混合长度的数组，同样的事情也可以发生在python的列表、字典和元组里。好像在C语言里数组的长度得一开始就设定好，现在看来，我觉得这样不好，因为有些东西的确是很难一开始就想清楚的，搞太小了，放不下，搞太大了浪费空间。学习各种编程语言让我明白到原来某些我觉得参不透的东西其实可能没必要一定用那种思路。

之所以要死磕php，因为我有点讨厌WordPress里的垃圾评论。虽然官方自带的Akismet插件已经免去了我很多烦恼，但还是会有些漏网之鱼，所以我的垃圾评论列表里总有东西，看着心烦。那些垃圾评论虽然不在前台显示，但是在导出数据里会看到，浪费我的空间。对付垃圾评论的方法有很多，插件大法是最适合小白使用的，WordPress自带的规则也能让评论不被摆上台面，但我想做到的是根本不让那些东西写入我的数据库，没有写入就不需要删除，不适合的东西直接滚，减轻数据库的负担。虽然呢，我的小网站向来没什么流量，不会负载超标之类，但每当网站很慢，发布个文章都等半天都开不完的时候我就会暗暗觉得是不是被垃圾评论拖累了。综上所述，所以我选择的垃圾评论对抗大法是“Akismet + 自定义代码”。Akismet这个东西是安装完WordPress以后自带的官方工具，启用、填API就好。自定义代码需要在WordPress模板的functions.php里加入一些东西。网上有很多教程，但哪个才最适合自己得自己试过才知道。评论里可控的参数可以参考comments.php。我的防垃圾评论自定义代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function refused_spam_comments($incoming_comment) { 	
	preg_match_all('/http/', $incoming_comment['comment_content'], $link); // 有两条或以上超链接的，滚！
	if(count($link[0])>1) {
		wp_die("垃圾评论！！！"); 		 
	}
	$ruattern = '/[А-я]+/u'; // 俄语的，滚！暂时我还没见过大批量日语、泰语、阿拉伯语的
	if(preg_match($ruattern, $incoming_comment['comment_content'])){
		wp_die( "垃圾评论！！！" );
	}
	$name = '/Henrylix/i'; // 中文广告
	if(preg_match($name, $incoming_comment['comment_author'])){
		wp_die( "垃圾评论！！！" );
	}
	$mail  = '/(jjgfqijpo)|(.ru)/i'; // 其它广告
	if(preg_match($mail, $incoming_comment['comment_author_email'])){
		wp_die( "垃圾评论！！！" );
	}
	return($incoming_comment);
} 
add_filter('preprocess_comment', 'refused_spam_comments');

WordPress自带的评论规则里有超链接超两条就自动不显示，自动落入待审核的垃圾评论，但这样我还得去清啊，直接不让进更好，貌似我没有在其它防垃圾评论代码里见过这条。很多教程里“wp_die”那里用的是“err”，我不知道其他人怎样，反正“wp_die”我用得挺好，前台后台都正常，但“err”前台后台都不行。有些人这样，有些人那样，是不是跟不同的WordPress版本有关呢？这个自定义代码只是暂时的，我还得根据垃圾评论继续调整，debug的过程永无止境。

我感觉会了代码，人生才算是有了主动权。

我感觉自己越发喜欢VS Code了，这个东西的确就是我想要的写码工具，如果早点认识它，从前我就不需要走那么多的网路了。用VS Code写过代码以后，我对它是一发不可收拾的喜欢，但我始终不习惯在暗黑界面码中文，毕竟写代码和码中文不一样，写代码的时候思路是自己的，但积木的类型是固定的，这就意味着写码的时候如果有Emmet会相当便捷快速不出错，但如果在写blog的时候，尤其不是写代码技术类的时候，Emmet会变得毫无用处。同样我不需要额外纠结的还有中文语法。写blog是很自由的事，试想一下满屏的各种颜色波浪线，侧面和下面还有各种数字圈圈那将多么的恼人，当然了，貌似VS Code还没有厉害到可以有中文语法自动检测这种功能，我估计英文可能已经有了，Office几百万年前就已经有的功能VS Code可能天生就内置了，即便没有，让你绝对想不到的插件也肯定能实现。Offcie有中文语法检查的功能，但那个东西，笑而不语就好，别当真。

写码为啥要VS Code呢？不仅仅是Emmet功能，写过的函数，设定过的变量往后再用的时候，敲几个字就能有提示，就更不用说，使用默认的系统函数时能马上显示出详细的函数说明。自己写的变量一个颜色，系统函数一个颜色，保存以后还能自动语法检查，妈妈再也不怕我会犯格式上的错误。但话说回来，格式不错，不代表代码就一定可以运行出你想要的效果。毕竟代码的核心仍然应该是你的思路。

我不知道为什么大家都说暗黑模式写码护眼，护不护眼我不知道，但我知道白色界面看五颜六色的高亮会刺眼，相对来说，背景主色调是深色就没有这种不和谐。是不是因为这样，所以一开始的电脑都是黑屏白字而不是反过来呢？因为他们完全可以把那个东西做成计算器那样白屏黑字。现在我的习惯挺奇怪，写码的时候我用黑屏，写blog或者写其它文章的时候用白屏。我感觉自己用白屏的时候字体大小得设定到起码是黑屏的1.5倍。

去年我第一次接触R语言，觉得那个东西实在太伟大了！今年年初我的计划是学习R语言，但结果Python捷足先登了。VS Code搭配Python那是爽得一逼的节奏，因为Python是很大路的程序语言，所以很多东西已经非常完备了，相对来说R语言小众一点。无论是官方自带适配的还是第三方插件都比较弱。我用过R语言写码，那个东西简直是太难写了！一大串东西写好，要修改其中的一些，还不能鼠标快速插入，只能用键盘光标移过去，实在太逆天！当时我用的不过是系统函数，很多参数的位置和写法都是固定的，无数次我运行失败都是因为我手贱敲错了。试想如果这放在VS Code，有自动的语法提醒纠正，这种烦恼根本不存在。同样比较烦人的写码还有Excel VBA。运行的时候他们会弹出一个代码告诉你出错了，代码到底什么意思呢？到底是哪里卡死了呢？他们明明都得出代码了，却不直接告诉你到底是什么意思，很多时候，运行卡住是因为我手贱把一些系统参数的名字写错了…… 又是参数名字写错！如果在VS Code，这种事情根本不会发生啊！

写代码的方法千万条，但能边写边提醒你不犯低级错误的通常都不是某个程序语言自带的编辑器……