我的天

花了一整天都没搞懂的事情，突然晚上用了大概半个小时就开窍了。当然，其实功劳不在那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后就前端不显示了，按照上面步骤对照修改后，还需要在后台小工具页面把之前失效的小工具从箱子里删除，然后重新拖放小工具归位。相信我，这个步骤非常重要！！！虽然看上去还是那个模样，但实际上拖放一圈的确就能解决修改代码后，前端无论如何仍然刷新不出来的问题。

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

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的，因为python的转换过程中没有出错，这就证明没有遇到奇怪的事情。用别人脚本的时候，把转换好的文件上传到WordPress，我总会担心不成功，但我自己写的脚本，我知道该注意些什么，哪些参数是现在的WordPress必须要求有的，所以只要python的转换不出错，我的WordPress导入就不会有问题。因为点点的文章有9000多篇，要从后台管理界面导入到WordPress，会非常耗时间。如果一篇文章需要两秒，完全导入就需要5个多小时，所以我没有做这种事。我挑选出22篇，各个类型都有的，试验导入，结果非常成功，网页的效果也很好，完全按照我的意思生成了。我觉得如果要快速解决问题，估计我得在数据库端导入。之前把文章导入到WordPress，因为要尝试不同的版本，我得不断地导入删除，但删除的文章太多的时候，速度很慢。后来我暴力地在数据库那里直接写删除语句，结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉，这也是一个秒杀的过程，而且绝对不会留下任何的手尾，比如文章删除了，但是分类和标签仍然在那里。可能某些东西已经不存在了，但是计数还停留在一个很大数值，之所以这样，肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西，还不如直接把数据库清空。因为我这是单机上的WordPress，我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周，才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签，是因为不能删掉一些不应该删掉的东西，但我没有这个顾虑。既然在数据库层面可以快速的删除，那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法，是因为我发现WordPress的插件有些是针对数据库的，有些是针对WordPress自带函数的，数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法，貌似之前我还没有听说过。在网站迁移的时候，的确是把数据库打包，然后重新放到别的地方的，但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方，原封不动地，但是我却要把大量的数据以快速的方式导入到数据库，并且还得按照WordPress的脾性建立各种关联，显然这貌是非常不简单，但理论上应该可以做到。

我不知道我的python到底学成怎样了，但起码我可以用那个东西实现我自己的愿望。相比于书本的习题，我觉得实现自己的愿望更有成就感，虽然其中有很多问题完全只能靠自己，没有参考答案。虽然总的来说，脚本不是我一个人写的，我是站在巨人的肩膀上修改而成，但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了，接下来我要把脚本优化，一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化，应该泛化到什么程度，这个我还没有想好。昨天之所以可以这么迅速地完成任务，大概是因为在我开始之前先做了个思维导图，明确了我到底要做些什么。基础数据有哪些，应该在哪里取数，需要判断的参数有哪些，各自的参数有什么特性，能不能合并同类项。之前我就写过类似的东西，但是跟思维导图比起来，之前我写的那个真的很水。有思维导图、有专业的思维导图软件，人的思路可以非常快地展开。整体定下来，下面的事情就只剩下一步一步地实现。我做梦也没想到，自己这次居然这么高效。某些我没有把握能快速解决好的问题，昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件，我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快，但怎么才能更快呢？文件里的数据结构是我没有考虑过的，我是不是应该从那里入手？一些相同的判断，大概我应该做一些合并。

追求更好是没有尽头的。

用了一天时间，我熟悉了社区动力的后台。又用了一天时间，我把社区动力的一些DIY模块自己玩起来了。这种神速的掌握，让大家惊讶不已，但我觉得这其实是理所当然的。虽然以前我没玩过论坛的后台，但是博客、轻博客的后台我可是玩了不少。

中国现存的论坛，绝大多数都是以社区动力为驱动，这个东西已经有很多年历史了，有很多代产品，功能非常强大。无论是我想到的还是想不到的。也不知道是不是我正在用的那个版本太老，所以存在一些我感觉是逆天的设计。比如说他们会有一个清除所有未使用插件的按钮，但却没有一个，针对单个插件删除的按钮。无论什么系统，论坛也好博客也好，其实无非控制几个页面。主要分为主页、导航页，还有文章页。后台的框架是我们没办法定规则的，但我们可以通过后台以各种方式控制前台的表现形式。最基础的控制手段是CSS和HTML，当然也有特效，但那是后话了。在控制论坛角色行为方面社区动力的后台的确很厉害，但在控制基础制网页方面，我真的觉得他们很让我觉得无语。明明是很简单的修改，他们却搞得很复杂，大概因为这样复杂化了，一般人就不会想到要亲自去修改，而直接去购买他们的后续产品。他们最神奇的莫过于修改最基本的CSS和HTML，居然还必须使用FTP。这都什么年代了？！他们那可视化编辑界面是弱智低能的，因为上面的功能非常不齐全。说明是有等于没有。你把里面的功能全部都试一遍，还是不知道那是干嘛的。可视化的，也就是所见即所得不是这么弄的。而之所以有这样的吐槽，大概是因为很多年以前我就已经在使用世界上用户最多的后台产品WordPress。这个东西除了支持最基本的博客以外，还支持论坛，甚至网站。只要你脑洞足够大，它可以实现你想实现的功能。唯一区别在于，社区动力很多设置考虑的是人与人的交流，人对人的控制，但这不是WordPress的长处。WordPress主要是用来发布东西的。那个公司也有交流互动的功能的产品，那是专门留给论坛用的，但是知名度却远远不如WordPress，因为它们的功能的确不怎么全。

做了那么多年的网页，我觉得最让我吐槽的是社区动力的可视化DIY模块跟他们的脚本编写完全脱节。在DIY模块你只能用最基础的方式，进行拖拉，然后参数设定。接下来你却不能用纯脚本进行进一步修改。可视化和脚本修改应该是高度结合在一起了，不是吗？脚本编写对一般人很难，但对高手来说细微调整和重复使用只是弹指间的事。即便在十几年以前，那些现在已经倒闭了的BSP也能够实现很够意思的可视化编辑，为什么到现在为止要用社区动力要做那些东西还很困难呢？看过社区动力默认模板的CSS以后，我有种想死的感觉，明明不是一类的东西他们归为一谈，于是当你要控制某个参数的时候，其它的也被迫改变了。之所以这样，我觉得是因为做前台设计的那个人思路不清晰。他们也总喜欢用一两个字母的缩写当名称，于是一整CSS下来都是代码。当然，这东西不是人给人看的，而是给机器看的，缩写无所谓，但是在修改的时候，人肉读取就变得相当困难。为了解释那一堆缩写，他们还得写一大堆的注释，这又何苦呢？WordPress的模板不这样，无论是官方的还是民间的，你看到他们的英文名称就会知道那到底是干嘛的。他们只需要在某些地方做很简短的注释。研究社区动力的默认模板代码真的比我自己重新写一套更辛苦。

于是搞完以后，我感觉整个人都废了，躺在床上不想动，觉得身体不是我的。

昨晚我发了这么一条围脖“我的装扮和发型的确骗了不少人[偷笑] 除了多了点悲观和对人生的无奈，很多激情类的东西和我还和20岁的时候无区别，甚至，更强大了”。今天的某个时候，我在想，我哪里更强大了呢？主要是，我看到过的东西不一样，我知道的东西更多了，同样的竭尽全力，我做出的效果理所当然要比从前更厉害。

10年前，还没有完成高考的时候我就暗自想着为THE X-FILES做一个网站，但到底为什么要那么干？我的目的并不强，我只是觉得我喜欢，所以我得做点什么。到底是做独立的网站还是做对当时来说有特定模式的blog我纠结了很久。若不是有danzhu关于BLF的blog的存在我不会认识到世界上有blog这种东西，更加不会在这个非常有生命力的发布模式上走那么的远。一开始，我觉得blog就是一篇篇日志的集合，其表现模式比较单一，无非就分成2种——主页和文章页，与之相比网页的形式显然多样化多了，但随着认识的逐步深入，尤其当我开玩WordPress以后我终于有了这么个念头——为什么要用FrontPage，Dreamweaver之类的做网站呢？WordPress这种基于blog模式的管理通过变换前台就能设计出你能想出来的所有网页，问题只是WordPress用的是php语言，你得乖乖地敲代码而不是可视化解决一切。因为不懂所以觉得可视化更方便，但一旦懂了，代码才是最终拯救世界的杀手锏。无数个日夜我都在问自己/研究到底我需要什么样的前台表现形式，从一开始的直接套用，然后是逐步替换到最终的完全独立天马行空。我经历了Blogger，BlogBus，WordPress和diandian，这几个是主流，还有一些非主流不blogcn之类的连我自己都不记得了。因为不知道，所以以为不可以，但一旦明白了解了，你就会明白到世界均大同，问题只在于你怎么运用好手里的东西进行创造表演。这种深切的领会当你好好钻研过网页的前台和后台后就会明白，我足足用了10年时间去领会，但我并不是大师傅，我还有很多很多需要学习，尤其在现在这个智能手机/平板已经到来的年代，只守住我已经懂的东西远远不够。

写blog很简单，就是得有足够的时间敲键盘凑字数而已。但话题呢？怎么才能有每天各不相同的话题。blog可不是围脖那样突然兴起一句话或少于140字就打发走的玩意。如果只有短短的一条心情，何必写blog？社交网络（推特围脖微信之流）无法取代blog的位置，因为人不能一直只靠快餐文化过活。品牌不能只有社交网络的帐号而必须有官网来系统全面细致地介绍展示他们的商品。社交网络的某个新品发布/活动宣传非常容易就被铺天盖地地宣传开来了，但具体细节呢？你总不能每次都让人都凭借大概的印象去搜索吧。社交网络的信息流太多，要筛选出你想要的东西实在有点难度，但网站不同。

“会看的看门道，不会看的看热闹”，这是教了我高中三年的数学老师的一句口头禅，他老人家据说当年高考数学是拿满分的！他曾经一堂课40分钟就只给我们解答一道题，但用了N种方法。从我们耳熟能详到我们目瞪口呆的形式都有。作为一个自己也在关注网站前台表现和后台信息量的人来说，我自然而然就会对网站不由自主地进行各种比较评价。WWE的网站的设计是得奖的，我很庆幸Alberto Del Rio这个角色开始于那里，所以我就可以非常系统全面地把握摔角信息的方方面面。全世界最大的摔角联盟，他们有非常雄厚的资金力量，后台的工程师更加是多如牛毛，是他们让我在一开始就已经建立了一个该如何去了解摔角的框架思维，不得不说，他们的网站信息量真的非常大，信息更新的速度也非常快，没有足够清晰的思路和经过千锤百炼的准确分类肯定会一团糟。当你明白了网站后台信息其实都一个样以后如何分类标签信息显得非常重要。网站牛逼需要两点：足够多的后台信息量，足够合理的前台展示形式。离开WWE，开始AAA我简直有种倒退10年的感觉，但我理解明白，幸好是倒退了，如果是超前10年我必须的只可以理解无能。不过话说回来，摔角界的网站有比WWE更超前的？

强不强有时看外貌是看不出来的，但强不强自己心里清楚。