坏蛋的博客 – 第 2 页 – 非淡泊无以明志非宁静无以致远

不匹配含有指定子节点的节点

e.g：不匹配子节点含有 ‘i’ 节点的 ‘p’ 节点

response.xpath('//p[not(i)]')

不匹配含有指定属性的节点

e.g：不匹配子节点含有 ‘class’ 属性的 ‘p’ 节点

response.xpath('//p[not(@class)]')

排除指定节点

e.g：排除名为style的节点

response.xpath('/*[not(self::style)]')

Jackson解析数据为空时字段类型产生变化的JSON字段

对于PHP、Python这类动态语言编写的API接口，其返回的JSON经常有这种情况：

1、字段有数据时：

{
    "name":"Test",
    "tags":{
        "caches":"caches",
        "caching":"caching",
        "feeds":"feeds",
        "late-caching":"late caching",
        "speed":"speed"
    }
}

2、字段无数据时：

{
"name":"Test",
"tags":[]
}

可以发现，tags字段有数据时其类型是个集合，而当tags字段无数据时其类型则是个数组……

这就导致无法准确的编写用于映射数据的实体类。

为了应对这种情况，可以在注入Bean时为Jackson配置选项将为空的字符串、数组都映射为空对象（NULL）。

代码：

mapper.enable(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT);
mapper.enable(DeserializationFeature.ACCEPT_EMPTY_ARRAY_AS_NULL_OBJECT);

Kotlin使用Java反射Api操作KClass时遇到的变量作用域问题记录

Kotlin本身带的反射Api依据官方文档来看貌似是残缺的，想实现完整的反射支持只能调用Java的反射Api，类似下面这样：

val test = Test::class.java

这样就可以通过test对象调用Java的反射Api了，这样在操作Java Class的时候是没问题的，但是操作Kotlin的KClass就会出现变量作用域的问题……

问题的根源在于Kotlin代码在翻译成Java代码后无论你先前声明的成员变量的作用域是公有还是私有，都会被翻译成私有，并辅以一堆Get、Set方法用来操作该变量。这似乎是挺符合Java世界的标准的，在Kotlin下访问一个变量会自动调用其Get、Set方法。但在反射的这个应用场景下就会出问题。看一下下面这个语句：

test.getFields().forEach {
    println(it.name)
}

上面这段代码会输出什么？

什么也没有……

包括你使用test.getField("testVar")时也会给你抛出一个找不到成员变量的异常。这就是问题表现。你不再能像之前习惯的那样直接操作字段了……

这个问题除了老老实实调用对应的Get、Set方法操作外还可以通过将成员变量声明为JvmField的形式防止其被翻译成私有：

class Test {
    @JvmField
    val testVar: String? = null 
}

不过我更建议还是老老实实麻烦一点调用Get、Set方法操作……因为直接操作变量的话将来一旦类的内部对变量的读写进行了一些预处理操作，直接通过访问变量字段的方式操作变量就无法触发这些操作，代码维护起来会很麻烦。

WP中国本土化社区发展计划（2020年6月23日修订）

需要特别说明一下，这里的发展计划可能随时会变更，因为在事情成型前，谁也说不准具体会怎样发展。当前的发展路线并没有国内外的成功案例可供参考，我是在一边走一边修正方向的状态中。当然，我会在标题中标注变更日期，同时在文章开头注明每次变更的主要内容。

修订记录

2020年6月3日，第一次公布方案。
2020年6月22日，本次修订对细节进行了大量的完善说明。
2020年6月23日，本次对有争议的部分增加了解释，附在文章末尾。

正文

承蒙各位朋友的帮助，WP-China-Yes项目在这近四个月来取得了不错的进展。目前有记录的共有115个网站为此写了推广文章；共14位个人和11个企业捐助了5,155.47元现金，和价值1万余元/年的服务器资源；共7人为项目贡献过代码；通过又拍云日志分析，目前用户数1.5w+。

WP-China-Yes项目诞生之初我是希望解决WordPress官方服务在国内访问缓慢的问题。不得不说，这个项目是被wordpress.org的429问题催生出来的，也是在429问题的推波助澜下才得以发展起来。也许429问题某种意义上来说，是一种机遇？

这个项目从插件第一版发布，到如今开始推本土化社区，我也遭到了无数人反对和批评。我对此一直是保持学习的态度，谨慎思考着每个反对的意见，则其善者而从之其不善者而改之。

WP-China-Yes项目未来的路在何方？项目一开始，只是做官方服务加速而已，设想推动整套本土仓库源基础设施的开发工作，之后召集一批企业自愿为广大WordPress用户提供免费的加速源服务。

后来随着接触了越来越多的WordPress从业者，听取了各方意见后，渐渐有了新的思考。WP-China-Yes插件的意义不止于是提供了加速服务。这个项目其实是为国内生态发展开辟了一条崭新的道路，第一次国人知道原来仓库不一定非要用官方的。这就为发展提供了一个契机——中国人可以把生态中涉及的内容握在自己手上，由中国人自己设计一套符合国人思维和使用习惯的社区规则，并把这套规则催发出的生态资源通过国区仓库的形式整合进国人的WordPress中。这样，一个中国版的WordPress就诞生了，核心还是原来的核心，只是附加在上面的生态被替换成了国内的。就好像安卓应用市场和谷歌服务框架在国内都被替换了一样。

将这个项目的意义做一个类比：文明的发展是存在瓶颈期的，整体上是一个阶梯性发展的过程，一旦突破了瓶颈就会产生科技大爆炸，短期内跃升至下一个阶梯，如果不突破发展瓶颈，文明将在很长一段时间内缓慢的线性发展。套用在人类发展史上，距今两百多年前珍妮机的发明，将人类带入了工业化社会，从此人类经历了几万年所未有的快速发展阶段。WP-China-Yes插件对于国内WordPress生态的意义恐怕和这是一样的。

在这篇本土化社区发展计划中，我将介绍目前正在推进的两个项目，他们一起组成了WP中国本土化社区的基本盘，未来社区将以此为基础为WordPress在中国的发展做更多工作。

首先是一个立足国情，允许上架付费和闭源应用的中国特色商城，这将是一个和国区仓库直接整合的公益性质的本土商城，不抽成也不做竞价排名。商城为用户提供沉浸式的选购体验，用户的选购、安装、更新推送都将在WordPress已有的框架体系下进行。是的，届时开发者的付费应用也可以通过本土商城为用户统一推送更新，而无需自己维护更新渠道，更无需用户手工下载安装包再覆盖上传……

WordPress应用商城，这十几年来无数人曾经或正在做。但是不得不说，大都没有起色……究其原因，无疑是陷入了怪圈：用户体验不够好+本身知名度不够高+用户知识付费欲望不够强且网上盗版横行 => 没用户 => 开发者没理由入驻或压根不知道平台的存在 => 没有足够的优质作品 => 没用户。

一个死循环，而且似乎很难找到突破口？

为了寻找这个突破口，在本土商城之前，一个铺垫性的项目会先上线。这个项目也是目前工作中的重中之重。

我认为，这个项目将会是一个撬点，一个足以撬动整个国内生态的撬点——i18n字符串的自动化翻译算法以及基于此开发的提供完整汉化支持的国区仓库。

有很多人质疑我：“机器翻译质量根本不行、机器翻译无法处理一些特殊标记，技术上不可行、如果机器翻译可行，官方早就做了”，如此等等……

对此，首先需要说一下，技术上已经验证过是可行的了，因为我已经做出来了，参考fanyitest.wp-china.org，对于质疑质量不行的观点，我尝试解释一下，完全指望机器翻译肯定是不行的，机器翻译只是提供了一个原始的驱动力，用来和其他优势一起聚集全国用户，并驱动用户来贡献翻译校准，这些相辅相成才能在短期内补足中国生态十几年来的遗漏。让我们来尝试捋一下整个发展思路：

假如我告诉你，现在有一个插件，可以本土化你的WordPress，为所有官方服务加速，并提供整个官方仓库的完整汉化支持，同时支持微调汉化结果。只需要安装这一个插件，就能解决WordPress在国内的各种水土不服，你会安装吗？

对此，我认为，也许大佬们看不上，但是对一般用户来讲是有足够吸引力的，机器翻译的结果虽不说质量多高，但是看懂是没问题的，这就够了。并且这个插件是唯一的，短期内不太可能出现山寨品，因为不像最初的WP-China-Yes插件，只要搭建个反代就能山寨一份出来，然后声称自己早就想到了（事实上，这样说的人一般忽略了跟在别人屁股后面抄袭无异于有人告诉他“沙漠往南有水”，如果前面没有这个领头人，这人大概是要迷失在沙漠里的）。机器翻译对i18n字符串的处理算法和自动翻译与仓库整合的整套解决方案是存在一定技术门槛的，不直接盗用源码的情况下想仿制一个出来有一定难度。当然，为了保持领先，我会暂时对源码闭源。是的，开发这个自动翻译，除了增加用户粘性外，最主要的作用就是防止抄袭了。抄袭的危害很大，抄袭使这个项目无法聚集全国用户，无法聚集全体力量。力量都被分散到各个抄袭者手上了，这事实上的阻碍了国内生态的发展。要知道，抱团才能干大事。

不过，也有人说全量汉化支持对用户的吸引力不够大。对此，我推荐你看一下这款插件：Loco Translate ，他的安装量是1000000+，这1000000都是非英语母语的人安装的。再加上那个养活了薇晓朵团队十几个人的薇晓朵数字商城，相信用户对本土化翻译的需求是超乎你我想象的。

刚刚有提到，说自动翻译是一个原始的驱动力，这个驱动力是如何体现的？那就是前面说的“支持用户微调翻译结果”，用户微调的过程其实就是翻译校准的过程，校准结果除了会在用户本地生效外还会被传输到“协同翻译平台”，经过管理员审核后会直接被用来优化机器翻译结果，日后机翻的时候如果刚好匹配上被校准过的字符串，会直接调用。是的，越用越准确。这就是原始驱动力的体现，这是在变相的引导用户贡献人工翻译，并且这个过程只讲利己。这样在被用户需要的同时，事实上的丰富了国内的生态资源。

好的，通过上面那部分的推导，我们暂且得出一个结论：这样一个提供服务内化&全量汉化的插件会有需求，用户会希望能安装上这个插件来帮助他更愉快的使用WordPress，并且这个需求具有普适性。

那么，接下来怎么做？用户换量计划！先由一些我所紧密联系的国内知名开发者牵头，将WP-China-Yes设置为其产品推荐插件，在有了大哥带头示范后，再向全国开发者复制这一模式。

用户换量是最快速且低成本的用户群体获取方式，大家先将各自的用户群聚集在WP-China-Yes插件下，由此换来日后国区商城的入驻名额。

经过前面的推论，我们知道，WP-China-Yes将会拥有足够的用户存留度，只要带来的用户，在将来都将是国区商城的直接消费群体，每个参与换量计划的开发者都可以享受其他开发者带来的流量，互相成就。

聚集全国用户群体，这就是本土商城的突破口，有了用户群之后才能拓展更多玩法。现在我们知道了，这个商城将会有足够的用户群体参与消费，但是然后呢？国内用户的版权意识并不强烈，知识付费意识也不高，这可怎么办？

由社区统一组织法律援助！有了用户基础，就有了谈判的资本，可以和律师事务所合作。统一为社区开发者提供无偿法律援助。就算谈不成，我也可以自掏腰包组织打一两场官司，之后相信大家都能预见到，只要成功了一两次，就会起到杀鸡儆猴的效果。之后只需要发发律师函就可以了。

好了，用户群体有了，用户版权意识虽然没提高，但是把盗版倒卖的商家给打掉了，这样用户也就无盗版可用了，算曲线救国。那么接下来就回到了比较重要的问题上：如何提升商城的用户体验？

我认为，无需做太多工作，因为必须要认识到，得益于本土仓库这个思想的诞生。本土商城一样可以直接整合进本土仓库，届时，用户会像安装官方仓库的包一样，方便的安装国区商城的包。只需要额外开发一套购买逻辑，并在官方仓库的菜单栏上增加“国区商城”的选项即可。

是的，所有安装了WP-China-Yes的用户，直接就是商城用户。只要不卸载WP-China-Yes，他们就将一直看到国区商城的优秀作品。

到这里，经过推演，国内商城无法成功的僵局似乎打破了？是的！至少我认为是的。

现在，我们得出了以下发展路线：

为WordPress提供服务内化&全量汉化的WP-China-Yes负责聚集和留存用户 => 国内开发者通过用户换量计划，将各自用户群体聚集在WP-China-Yes插件上，并由WP-China-Yes锁住用户，做到来多少留多少 => 社区统一法律援助，直接维护开发者利益，全国范围内打击掉盗版倒卖行为 => 商城前端集成在WP-China-Yes插件中，为用户提供沉浸式的选购体验 => 让开发者有钱赚 => 更多的人参与开发+质量更高的官方仓库汉化 => 生态资源的繁荣 => 更多的用户选择WordPress。

良性循环，国内生态被驱动起来了。

可以预见，这个项目需要一个官网，也需要一个交流反馈和信息发布平台，于是，就需要一个交流社区形式的网站。

好了，WP中国本土化社区(WP-China.org)诞生了，这个社区将集合全国之力繁荣国内生态。

为什么名字叫本土化社区？

因为现在和未来所作的一切工作，都是围绕着WordPress在中国的本土化而进行的……插件/主题包的翻译以及国区仓库、国区商城的建立等等的这一些工作本质上都是为了让WordPress在中国变得更好。社区的目标不是成为类似问答平台那样的互助交流网站，而是成为一个组织和推进本土化工作的工作小组，通过自成体系的生态不断吸引新鲜血液参与到社区发展和贡献中。

WP-China.org下有以下几个模块：社区论坛，供交流使用；新闻发布，见名知意；协同翻译平台，用来完善本土仓库的翻译质量；国区商城，这里主要是提供供给开发者们使用的相关后台服务，如作品发布等。当然，现阶段是这样安排的，未来还会有无数种可能，举个例子就是，统一组织文档的翻译引进等……

之前有人质疑我是在搞垄断谋利益。

其实这个大可不必这样想，这个项目的推进过程中我得到了很多人的帮助，大家有的提供想法供参考，有的直接贡献代码，也有的会告诉我一些问题已有的解决方案帮我消除信息差，还有的捐钱希望我坚持。

如果我将来有一天宣布这个社区以后不公益了，转商业公司了。这一些人会怎样想？我猜，此举必将反噬我自己。

况且其实我对钱没什么追求，从小到大爹妈就深度贯彻“穷养儿”的政策，我可以说是穷惯了。我直到现在穿的也是淘宝上百十块的地摊货，并没有对奢侈品有什么喜好，对金钱看的也很淡，我更注重的是个人的荣誉，在乎的是自己的名字会不会流传下去。金钱在理想面前，不值一提，它唯一的作用就是帮我调集资源去干更有意义的事情。

不过，这不是说我就是超人了，不用吃饭就能活得很好。或者说在投入大量精力维护社区的情况下还能接一份外包干点私活。于是，我个人生存所需的资金如何筹集，是未来不得不面临的挑战。

对此，我的设想是，这笔钱由每个通过这个项目获得实际好处的开发者自愿捐助，我会尽量为捐助的多的人提供曝光机会。至于本土商城，则完全不收费，也不做竞价排名，完全做到公益性质。

关于社区的资金用途安排，目前初步设想是除去社区运行开支外，余下的钱中我个人按量每月领取工资，再留一部分作为社区储蓄以便将来开展新的业务，同时做到每月财务公开。当然，这一块目前还是初步设想，还需要参考国外的成功案例再做定夺。

这一整套方案，我认为是国内这十几年来，振兴国内生态最详细、最切实可行的了。当然，具体执行过程中肯定会遇到各种困难，但是因为希望的存在，所以这值得一试。我这两个月来，每天都在这个方向上推进着也思考着。

如果你有建议，欢迎留言。每一份观点我都会认真考虑。

对一些争论点的解释

争论1：中国特色商城允许闭源应用上架是否有违开源精神

对此，我认为：不先吃饱饭不结合实际情况的前提下就直接谈理想的行为完全就是耍流氓嘛！开源运动应该是和经济发展一样，在有了极其丰富的原始积累后（软件技术的发展、人才的储备、用户群体对知识付费的认可程度），才能演化成共产主义（开源）。如果盲目的追求共产（开源），就会变成类似国内早期大跃进的那种情况。所以说，现在要做的，就是先允许闭源，壮大生态，大家都吃饱了，再去追求更高的理想以及更高级的生产形式。

争论2：基于WordPress开发的主题和插件应该属于GPL授权，不应该要求版权

这句话本身是没错的，但是不要忘了。GPL协议的核心是说“如果新的代码依赖于GPL代码，则该代码会被GPL传染”。这对于插件和主题的PHP代码当然适用，但对于css和js可就不起作用了。因为这二者的运行是独立的，并不依赖于WordPress的任何代码。所以说可以针对css和js要求版权。

Ubuntu 20.04安装MySQL 8.0.20记

很久没手工装过MySQL了，诸如AppNode这样的服务器面板很好的帮助开发人员屏蔽了琐碎的底层环境配置问题。不过AppNode支持的系统版本都很老了，其他面板又用不惯，于是打算手工安装一次环境尝鲜下新版本。

不夸张的说，我为了装一个MySQL昨天晚上从12点折腾到凌晨3点，今天早上11点起来又折腾到13点……于是今天打算把遇到的坑总结一下，免得后人再踩进来。

坑一

Ubuntu 20.04下安装mysql-server的过程中是不会要求输入root密码的，root密码被设置成了什么至今我也没弄明白。

看到网上教程以及官方文档都说安装过程中会生成一个默认密码，并被保存在错误日志里，然而我仔细翻过，发现并没有。

于是乎打算强制修改root密码，由此引出了坑二……

正确的查看管理密码的方式是：

sudo cat /etc/mysql/debian.cnf

上述文件的内容是：

可以看到user字段就是管理员用户名，password当然就是默认密码了。这个debian-sys-maint账号是Debian系Linux下MySQL的默认管理账号。

直接使用这个账号登录MySQL就可以愉快的玩耍了，如果你和我一样不幸的按照网上的坑比文章强制重设了root密码，请看“坑二”。

坑二

当时为了重置root密码，在网上搜了很多文章，大部分都是教要在/etc/mysql/my.cnf中添加skip-grant-tables;选项来跳过密码登录。

如果你这么做了，恭喜你，你完蛋了。

根据一篇台湾同胞写的文章来看，这个选项会修改mysql的用户表，造成不可预知的问题。

其具体表现的症状就是你在修改完root密码并登陆后，执行show databases;命令会弹出如下报错：

ERROR 1449 (HY000): The user specified as a definer ('mysql.infoschema'@'localhost') does not exist

这个报错着实让我头疼了一阵，谷歌搜、百度搜、官网搜，得出的结论无非就是执行mysql_upgrade -u root -p命令，尝试升级/var/lib/mysql下的数据库文件。

可是，这个命令在MySQL 8.0.16中已经被废弃了……执行后会出现如下提示：

Enter password: 
The mysql_upgrade client is now deprecated. The actions executed by the upgrade client are now done by the server.
To upgrade, please start the new MySQL binary with the older data directory. Repairing user tables is done automatically. Restart is not required after upgrade.
The upgrade process automatically starts on running a new MySQL binary with an older data directory. To avoid accidental upgrades, please use the --upgrade=NONE option with the MySQL binary. The option --upgrade=FORCE is also provided to run the server upgrade sequence on demand.
It may be possible that the server upgrade fails due to a number of reasons. In that case, the upgrade sequence will run again during the next MySQL server start. If the server upgrade fails repeatedly, the server can be started with the --upgrade=MINIMAL option to start the server without executing the upgrade sequence, thus allowing users to manually rectify the problem.

当然，更可笑的是，我压根没执行过数据库服务器的升级，为何要去升级数据库文件……

要解决这个问题，就得把整个MySQL完全卸载，并删除/var/lib/mysql目录，重新安装后再通过“坑一“中介绍的方式来查看管理员账号。

如果你必须要用root用户，可以使用这个命令重置其密码：sudo mysql_secure_installation

关于wp-china-yes插件被官方仓库下架的公告

很悲伤，插件被下架了，理由是官方不允许从其他来源安装WordPress程序及插件主题。

应对策略

用以实现在脱离官方仓库的情况下推送插件版本更新的解决方案已上线，代码仓库（普通用户无需关注，我维护的仓库源已经都部署好了）：

https://github.com/wp-china-yes/update-server

一些质疑

经过用户反馈，我发现貌似官方这次直接把带“china”关键字的插件全部毙掉了。这不禁让我怀疑，429问题还没解决，就先把解决问题的工具毙掉，还顺带把带“china”关键字的都干掉的操作是不是意味着官方在有意封杀来自中国用户？

一些承诺

无论如何，WordPress是开源软件的事实不会改变，WP-China-Yes项目将会继续为WordPress在中国变得更好而努力。

我们不会因为官方的所作所为就终止维护，相反，我们将通过技术手段保证用户正常平稳的接收更新并使用服务，同时一步步脱离官方的掌控，为实现一个完全为中国人服务的WordPress而努力。

第一时间获取最新进展

推荐加QQ群：1046115671

以下是邮件原文

We have been forced to permanently close your plugin due to our own mistake.

Your plugin – https://wordpress.org/plugins/wp-china-yes/ – allows for WordPress to be installed from places other than WordPress.org, which is a guideline violation.

We should not have approved the plugin at all. This is our mistake and we greatly apologize for misleading you 🙁

We do not allow plugins that install software as it poses a risk with security and trust. Our users must be able to trust WordPress.org as the source of truth for downloads, and plugins that intentionally circumvent that are not permitted.

Again, please accept our apologies on this matter. We should not have approved this plugin, and that is entirely our mistake.

2020年4月15日
孙锡源

如何关闭仪表盘上的赞助商名单列表

如上图所示，点击仪表盘右上方的“显示选项”，之后取消勾选“《WordPress中国区仓库源建设计划》赞助者”即可。

作者的话：

我非常不建议大家关闭该名单。仓库源的建设和维护需要消耗大量的人力、物力、财力，如果没有赞助商的支持，这个项目注定走不下去。

如果你觉得名单的展现方式特别碍眼，可以主动找我交流，咱们一起探索一个大家都能接受的方案^_^。

爱也许可以发电，责任感也可以驱使程序员拿出业余时间服务社会，但是爱和责任不能帮我交房租，也不能支付仓库源维系的固定费用支出>_<

目前赞助商们提供的服务器、CDN、云存储等资源折算为一年期的市价则已超过1万元，靠我自己每年支付这些钱维系项目怕是很难。而且目前来看该项目的维护还需要占用我和社区小伙伴很多的时间和精力……在仪表盘为赞助商冠名是目前探索到的最行之有效的造血方式了，恳请大家支持～

如果你有建议或者意见，请联系：

QQ：1642491905
微信/手机：17186788811

WordPress中国区仓库源建设计划

介绍

计划的目标是集合一批以WordPress开发及周边为主要业务的商业公司，由大家共同为广大用户提供WordPress中国区仓库源，我称之为“社区源”。最终彻底改善国内WordPress的用户使用体验，以求加速WordPress在中国的流行。

当然，用户也可以建立和使用自己的“自定义源”，在本篇文章中我将详细介绍仓库源的搭建方式。

仓库源所依赖的环境

一台境外的服务器（推荐美国的，带宽大）
国内的CDN（可选）
AppNode服务器管理面板
CentOS 7

AppNode面板介绍

可能有人好奇，我为什么不推荐宝塔面板？首先需要说明的是宝塔的功能是残缺的（此时的时间是2020年3月16日，宝塔以后可能会更新，但是至少到目前为止是残缺的），无法实现需求的功能。好奇的同学可以看一下宝塔的反代功能，他的页面内容替换只支持三个关键字并且不支持替换301响应中的URL。

当然，AppNode的确对该项目提供了赞助，不过这个赞助是因为我一开始就打算采用AppNode，所以才找他们谈了这件事，他们在给了我赞助后，一再要求我不要为其宣传，否则怕赞助“变味”了。

AppNode的前身是VPSMate，我是从VPSMate时代一直使用至今的，我对我的客户也是着重推荐AppNode。我个人觉得AppNode怕是现阶段最好用的服务器管理面板了，不过他的知名度非常低。

今天和AppNode的开发人员聊到知名度低的这个问题的时候，得到了他这样的回复：

总结一下就是：他们在静下心打磨功能，不鸣则已一鸣惊人。

源的实现原理

原理很简单啦，就是一台国外的服务器做WordPress官方服务的反代，之后再由国内的CDN做分发即可。

若是搭建来自用就可以不用套CDN了

搭建方法

AppNode面板安装

复制下面的命令到服务器中执行。

INSTALL_AGENT=1 INSTALL_APPS=sitemgr INIT_SWAPFILE=1 INSTALL_PKGS='nginx-stable' bash -c "$(curl -sS http://dl.appnode.com/install.sh)"

之后跟着提示走即可安装完成，这个和宝塔的装法是一样的。

注意：请在你的防火墙中放行面板的端口，否则面板将无法打开！

面板的初始配置

AppNode的面板的登录方式在安装完后会有相应提示，例如：

成功登录后就可以开始初始配置了，详见下方视频教程。

导入站点配置信息

为了方便大家，我把我的站点配置文件导出了备份，大家可以先下载下面的备份文件，再跟着后面的视频教程把配置文件导入到AppNode中。

20200316_165704.tar 下载

配置导入的站点

导入进来的站点主要需修改两个部分，一个是站点的域名，另一个就是站点的SSL证书。

注意：视频中遗漏了Body内容关键字替换和301重定向中的URL替换的修改方式。替换位置：站点设置-反代-文本替换，以及站点设置-反代-跳转URL替换。

CDN加速节点的配置

CDN不是必须的，自用的同学可以看一下百度云加速，他们提供每天免费10G的流量。

打算提供社区源的企业不需要自己配置CDN。《WordPress中国区仓库源建设计划》的CDN资源由又拍云统一赞助提供，各企业只需要提供一台国外的服务器做反代即可，最终架构图类似：

为什么会选择又拍云

和AppNode一样，又拍云也是我一直在用觉得很棒才定向的和他们谈了赞助的事。

我博客的CDN一直是用的又拍云，不过我是付费使用，并没有参加又拍云联盟活动，因为不想在博客上挂任何第三方链接和LOGO…→_→

这次之所以选择又拍云是因为又拍云的几个优点非常吸引我：

支持平滑迁移源站数据到云存储，下次直接从云存储读取，实现类似中间源的效果，有效减轻源站负担。
支持多个源站负载均衡、容灾备份，这个功能很强大很实用，我原本是自己开发了一个“仓库源调度服务”尝试达到类似效果，但是肯定是赶不上CDN层的实现来的彻底完善。
支持Let’s Encrypt证书，其他CDN配置的证书通常都是单次购买一年，若过期了只能重新购买，一旦忘记续期那就完犊子了……Let’s Encrypt的好处就是可以自动续签，放那就不用管了，省心呐。

以上三个优点中的第二个是最吸引我的，也是我最终决定选择又拍云的主要原因。

不得不说又拍云这家企业还是很有社会责任感的，简单聊了下，负责商务合作对接的同志就表示又拍云愿意承担《WordPress中国区仓库源建设计划》的所有CDN流量及数据存储费用。

其他仓库源搭建方法

【WP-ChinaYes】一个插件解决WordPress国内429（附反代配置）

使用方法

使用方法就很简单了，站长们可以直接在插件上填入API域名和下载域名即可，自定义源设置将会自动覆盖社区源的设置。

例如：

提供社区源

为保证可靠性，社区源目前只接受正规公司赞助。若贵司有意提供社区源请联系QQ：1642491905

提供社区源将会获得插件设置页、项目主页的引流信息、品牌信息展示的权力，这将提升贵司在WordPress用户群体中的品牌形象和信任度。

提供赞助支持

项目的维护需要耗费大量的时间和精力，如果你有意赞助我，请联系QQ：1642491905

加群交流

用户可以添加下面的QQ群，搭建过程中出现问题我会及时解答，后续有什么动态也会通过QQ群及时通知。

使用WP-China-Yes将WP站点与官方服务的通信切换到大陆节点

公告（2020年7月2日更新）

WP-China-Yes插件已于2020年4月15日被官方下架，请前往GitHub仓库下载安装，插件功能和本体的更新推送不会受此影响。

关于个别插件更新后还会重复要求更新的问题，目前已经部署了新的解决方案，彻底解决了这个问题，以后都不会再碰到了。

项目发展计划：https://www.ibadboy.net/archives/3864.html

有律师事务所，或法律工作者，有兴趣为社区提供法律援助的话请联系我。后面开始推本土商城后需要为开发者提供免费的法律援助，打击倒卖行为。WordPress主题和插件虽然基于WordPress，理应是开源软件，但其界面的CSS和JS却可以要求商业版权，所以倒卖是违法行为。

WordPress自动化翻译系统Beta版上线：fanyitest.wp-china.org，欢迎体验并反馈问题（如：翻译质量不佳，有符号被错误处理等问题）或贡献代码以帮助这个项目发展。

推荐加群，在群里大家可以一起讨论项目未来的发展方向，获得及时的技术支持，后续有动态也会在群里发公告推送。

群号：1046115671

介绍

因为WordPress官方的服务器都在国外，所以中国大陆的用户在访问由WordPress官方提供的服务（插件、主题商城，WP程序版本更新等）时总是很缓慢。

近期又因为被攻击的原因，WordPress的CDN提供商屏蔽了中国大陆的流量，导致大陆用户访问插件主题商城等服务时报429错误。

为解决上述问题，我发起了《WordPress中国区仓库源建设计划》，计划组织起一批热爱奉献、有责任、有担当的企业和个人在大陆境内架设基于反向代理的缓存加速源，用以加快WordPress官方服务在中国大陆及港澳台的访问速度，并规避429报错问题。

为使更多的使用WordPress的同学能够用上中国区仓库源，我开发了WP-China-Yes插件，以求帮助大家方便简洁的替换官方服务链接为加速源。

这个是一个公益项目，我始终都不会以任何借口对插件、加速源的使用权等进行收费。

现状

该项目目前由又拍云全力赞助支持——提供无限量CDN流量及数据存储资源。

后端由各个企业和个人捐助服务器组建反代节点，反代WordPress官方服务，前端统一接入到又拍云上，由CDN层实现负载均衡和容灾热备，保证高可用性。

目前官方插件、主题、核心程序、作品LOGO、作品横幅、作品截图、作者头像、主题预览等需要从官方调取的一切静态资源均会在第一次访问后被迁移到又拍云存储上缓存1年的时间，日后访问直接从国内云存储调取，速度飞快。

对于动态的API请求也有制定专门的加速策略，经测试：从河北秦皇岛移动带宽上直接调用WP官方接口检测插件更新情况平均需要耗费11秒的时间，而使用中国区仓库源加速后只需要1秒。

安装使用方法

GitHub： https://github.com/sunxiyuan/wp-china-yes

网络良好的同学也可以去WP插件商城搜索：wp-china-yes

下载并安装插件后直接启用即可，该插件会自动接管所有WP访问官方服务的流量。

插件不会更改你的WordPress程序，若不想使用大陆加速节点，直接停用插件即可。

另外，插件不会拖累站点的速度，她只有在需要访问官方服务的时候才会被激活，并且核心代码只有30行左右，不会对你的站点造成任何负担。

帮助推广

公益事业迫切需要每个人的支持与参与才能长久的发展下去。

从《WordPress中国区仓库源建设计划》构思开始，我就想达成：提供服务->用户自发推广->用户基数扩大->企业赞助->提供更好的服务……这样一个完美的闭环。在这个闭环中尤以用户自发推广最为重要！

千万不要感觉帮助推广是大V们的专利，如果每个用户都能把这个项目推荐给身边的两个人，那项目的用户基数将呈现指数级裂变发展。有了用户基数才会有与企业谈判的筹码，才会有更多的企业愿意投入资金赞助项目发展，大家才会有更稳定快速的仓库源使用。

如何推广呢？

你可以写一篇介绍WP-China-Yes插件可以解决429问题的文章，也可以写一篇介绍如何加快WP网站访问后台官方商城的速度的文章。甚至可以直接把链接甩到qq群上告诉群友们：429问题已经不是问题了~

寻求赞助

这里首先引用一份来自CardUi的市场调查报告：https://cardui.com/report/17。

报告中详细说明了WordPress在中国的市场占有率、发展前景等。

目前WordPress在国内占有近20%的建站份额，2019年市场规模首次突破90亿……

阻碍WordPress在国内进一步获取更大成就的难题主要就是——运行卡顿。

《WordPress中国区仓库源建设计划》就是想一定程度上解决这个问题，为WordPress提供像Linux一样的国内镜像源，帮助完善WordPress的生态环境，也使中国区仓库源最终成为国内WordPress生态圈中不可或缺的一环。

对该项目提供赞助，将会提升您的品牌在WordPress用户群体中的知名度，提升品牌价值认可度。

对于赞助者不仅仅会获得项目发布页挂名的奖励，未来赞助者名单还会出现在所有使用WP-China-Yes插件的用户的管理后台仪表盘上。

需要注意一下：只能提供挂名奖励，不提供广告投放。

我总结了一下，目前对该项目提供赞助的企业都具有以下特征：

发展健康，有余力
有责任感愿意承担更多的社会责任
心怀感恩，愿意回馈社会
理想主义者，相信自己的一份力量会使世界变得更美好
……

这其中尤以薇晓朵和AppNode二者最著，前者是在wp-china-yes插件刚发布2.0.0版本的仅仅半个小时后就主动联系我表示受益于该项目，想尽自己的一份力量提供些资金赞助。后者在提供赞助后甚至反复要求我千万不要为其宣传……他们害怕赞助变味了，因为他们认为他们仅仅是想尽一份力量，并不打算得到回馈……

其实我是不赞同AppNode的这种做法的，所以我坚持为他们宣传，因为大家应该都听过这篇文章中的故事吧，我就不再赘述了>_<

目前接受以下三种赞助方式：

服务器赞助（云计算和IDC公司推荐选择）
周期性资金赞助（以WordPress开发及周边为主的商业公司推荐选择）
一次性资金赞助（愿意请我吃一顿饭或者喝一杯咖啡的个人用户推荐选择）

如果你有意赞助请联系QQ：1642491905

推广者列表（按发文先后顺序排序）

这里先对所有参与推广的博主、群主等表示最真挚的感谢！你们为该项目的发展做出了不可磨灭的贡献！如果你感觉此插件使用体验良好，请一定也推荐给身边的朋友！

当你为WP-China-Yes写了一篇文章后，请在此文章下留下评论，我会第一时间将你的网站加入到这里的。

ps:自2020年4月15日之后只将服务器赞助者加入到仪表盘中展示

企业

薇晓朵（汉中菲比斯网络技术有限公司） ——1000元

AppNode（福州趣云信息科技有限公司）——1000元

Vps.re（亿云科技（深圳）有限公司） ——服务器x1

又拍云（杭州又拍云科技有限公司）——承包国内所有CDN流量及存储费用

栅格云（山东栅格网络科技有限公司）——服务器x3

酷番云（昆明酷番网络科技有限公司）——服务器x1

糖果主机（SugarHosts）——服务器x1

恒创科技（SonderCloud Limited）——服务器x1

柒比贰（武汉市潮流科技有限公司）——1000元

小兽wordpress（株洲纳姆网络科技有限公司）——200元

WordPress大学（桂林沃鹏网络科技有限公司） ——500元

买对的（石家庄买对的科技有限公司）——200元

个人

酷蝌星球 ——500元

设计窝 ——200元

胖子马 ——100元

爱搜博客 ——服务器x2

IFV的技术博客 ——5元

匿名 ——300元

学点编程吧 ——10元

Ares进阶之路 ——10元

Npcink ——99.98元

瀚域博客 ——38.8元

Haibin ——100元

蓝色创想 ——20元

顽兔博 ——21.69元

都潮汇 ——50元

Govzzp的生活 ——29元

贡献过代码/文档/参与运营（时间顺序排序）

孙锡源 | 赵丰 | 咸寒少 | 董嘉龙 | 3xs | 耗子 | Wr

生而为人，意欲何为

午休时回想起童年的经历，一切都历历在目，就好像昨天才发生一样。这种感觉使我十分恐惧……

由此时回忆童年向外发散，可以预见：当我而立之年回忆起20岁的经历时也必然会感觉一切像是昨日才发生的，时间就好像不存在一样，一霎时就穿越了十年的光景。

在我垂暮之年回忆一生时也必然会感慨人生如此短暂，转瞬即逝，我才刚出生就走到了尽头。若那时我不能建功立业，不能在人类的历史上留下自己的名字，我恐怕会怀着遗恨衰老死去。

我所恐惧的就是死亡到来时我作为一个人、一个宇宙中渺小的人、一个在人类历史进程中平平凡凡的人随着时间的流逝化作物质组成的基本元素散落在宇宙间，而我的事迹、我的精神、我的一切都无人记得更无人在乎，我就好像从来没存在过一样，未曾留下任何痕迹。

是的，在宇宙几百亿年的历史中、在人类几万年的进化史中、在文明诞生的几千年历程中，我微不足道，不值一提。这太可怕了。

我迫切希望我来人世的这一遭对于人类这个物种能有大的贡献，我不渴望富贵，只渴望在人类的历史上有关于我的记载流传下去，使聚集成我的这搓物质所孕育出的精神意识在随物质消散后依然被人们铭记……

我快速的在脑子里过了一遍，要做出什么样的事情才能达到这一目的？或者说，那些被印在史书中的都是些什么人？思来想去，大概也只有三种人是史书的常客——政治家、科学家、艺术家。

或许我可以做一个计算机科学家，带动某一项技术的突破，从而被历史铭记。这会非常困难，即便真的侥幸有所突破，鉴于计算机技术快速迭代的特性，我的成果最多也只能在某一历史时期有一定影响力，并将很快被新技术取代。不能奢望像物理学一样，一项成果的公布只要是正确的就注定了会万代流传，毕竟物理学定律这种东西从宇宙大爆炸开始就注定是一成不变的了。如今我们一谈到光速不能被超越就会第一时间想到头发蓬乱的爱因斯坦老爷爷，相信以后的人们也一定会这样联想，除非相对论被推翻了。

此时我多少为我选择了计算机专业而感到一丝悲凉，但是还好，至少我目前在这一方面的成绩还是可喜的，虽然距离我的理想相距甚远。

周老师曾对我说：“锡源，等你年纪大了，回忆你以前所想所做的，会觉得多么可笑”。

没错，我确实会觉得可笑，但是我绝对不会为此而后悔。或许随着年纪的增长，我在精神上的追求会逐渐被生活的琐碎消磨掉——每日脑子里只有孩子的奶粉钱、妻子的粉饰钱……但至少现在我是一个理想主义者，我愿意为理想付出一切，哪怕是我的生命。

即便我此刻的想法很幼稚很可笑，但多少年后回想起来我绝对不会后悔。

或者说，唯一会使我后悔的就是——年轻的时候不敢想、不敢试。

composer设置全局辅助函数

参考下面的代码，其中files中写的就是包含全局辅助函数的文件。

"autoload": {
        "classmap": [
            "src/"
        ], "files": [
            "src/tools.php"
        ]
}

QT发送HTTP请求的最小Demo

最近在筹划一个开源项目，为了尽可能压榨服务器性能，所以部分代码使用C++编写。程序涉及到对外的HTTP请求，正好发现QT自带这方面的库，那就直接引用吧！

下面给出一个最小的Demo，不做额外介绍，每个类的具体用法请查阅官方文档。

注意

跑Demo前需要在.pro文件中加上如下代码，以链接网络库。

QT += network

Demo：

#include <QCoreApplication>
#include <QNetworkRequest>
#include <QNetworkReply>
#include <QNetworkAccessManager>

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    // 构建及发送请求
    QNetworkAccessManager *manager = new QNetworkAccessManager();
    QString url = "https://www.ibadboy.net";
    QNetworkRequest request;
    request.setUrl(QUrl(url));
    QNetworkReply *pReply = manager->get(request);

    // 开启一个局部的事件循环，等待页面响应结束
    QEventLoop eventLoop;
    QObject::connect(manager, &QNetworkAccessManager::finished, &eventLoop, &QEventLoop::quit);
    eventLoop.exec();

    // 获取网页Body中的内容
    QByteArray bytes = pReply->readAll();
    qDebug() << bytes;

    return a.exec();
}

QT快速学习笔记——介绍窗体

QT中的窗体

在上一节中，我允诺会在本节介绍一个空白组件来作为窗体的“衬底”，也就是所有其他组件的父组件。

这个空白的组件的名字是QWidget，我不知道上一节中我贴出来的QT中类的结构简图你有没有仔细看。假如仔细看过应该会记得QPushButton以及其他所有的可视的窗体组件都是继承自QWidget的。

这应该很好理解，QWidget是所有可视组件的基类，拥有一个组件的基本属性——可以设置尺寸、设置标题、设置是否允许最大化及最小化等。

是不是被我说晕了？潜意识里认定明明只有窗体才拥有标题以及最大最小化这些按钮，为什么组件也可以？

这是因为在QT中其实并没有严格意义上的“窗体”，前面两节中咱们运行的程序展现出的窗体实际上都是组件本身——当一个不存在父组件的组件被调用show方法时，他就会显示出窗体的外边框。

下图是上一节中编写的程序，他的窗体外边框（标红部分）来自不存在父组件的button1对象，而button2对象的父组件是button1，所以button2的窗体外边框被隐藏了。

简而言之，QWidget拥有一个组件的基本能力，同时他默认不显示任何内容也不提供任何功能。

虽然QT中没有专门作为窗体的东西，但我们完全可以把QWidget这个组件当成纯粹的窗体来使用。

改进上一节的程序

非常简单，我们只需要把button1对象换成一个来自QWidget类的对象就好啦！

#include <QApplication>
#include <QPushButton>
#include <QWidget> // 引入QWidget组件

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    // 实例化一个QWidget对象window
    QWidget *window = new QWidget();
    // 注意这里将button2的父组件修改为window
    QPushButton *button2 = new QPushButton("Hi", window);

    // 这里修改要显示的组件为window
    window->show();

    return a.exec();
}

运行程序

还是很简陋，但是比上一节中那个两个按钮叠罗汉的程序可是好多了哈~

下一节中我将介绍QT组件的方法和属性，那时我们就可以利用新学的知识再度美化一下界面了。

QT快速学习笔记——在组件之上显示另一个组件

Parenting system介绍

这是我要介绍的QT程序的第一个重要的概念——Parenting system，原谅我不知道怎么翻译=_=。

这个机制的实现由QObject类提供，该类是QT中绝大部分组件的基类。QT中类的关系简图如下：

可以看到，我们在上一节中所使用的QPushButton组件也继承自QObject类，所以该组件也支持Parenting system机制。

代码演示

接下来我将通过一段代码来演示Parenting system机制的作用：

#include <QApplication>
#include <QPushButton>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QPushButton *button1 = new QPushButton("Hello World");
    // 实例化button2，在构造函数的第二个参数中填入button1的地址
    // 此时button2就是button1的子组件
    QPushButton *button2 = new QPushButton("Hi", button1);

    // 只需要显示父组件，其下的子组件就会一同显示
    // 另外子组件也不需要单独调用delete()，他会随着父组件一起被释放
    button1->show();

    return a.exec();
}

运行后显示是这样的：

我们将窗体拉大，变成如下：

解读

可以看到，button2是显示在了button1的上面。这就很实际了，因为我们常见的Windows窗体都是在一个组件上叠加其他组件来显示的，例如：

每一个颜色的框框代表一个组件（没有把所有组件都标记出来，只摘取部分说明问题）。可以发现这样一个很复杂的窗体，就是一个面积很大的组件上面无限层次的叠加小组件来最终实现的。

而维护这种组件之间的父子关系的方法就是我们本篇文章所介绍的——Parenting system机制。

但是我们刚刚的程序还存在一个问题，就是父组件button1是一个按钮，试想一下如果把button1换成一个显示空白的组件是不是会更好一些？相关内容将在下一篇文章中详述。

QT快速学习笔记——编写第一个QT程序

刚新建完的QT项目包含五个文件，分别是：

main.cpp
mainwindow.cpp
mainwindow.h
mainwindow.ui
untitled.pro

尝试运行一下这个默认项目，运行的方法如下所示。

运行起来的程序：

是一个标题为MainWindow的空窗体，里面什么也没有。即便如此，这个窗体的代码对于初学者而言依然过于复杂，接下来我们删除掉窗体显示相关代码，只保留QT程序最基本的框架，随后再一点一点向里面填充内容。

删掉除了main.cpp和untitled.pro之外的其他文件。最后整个项目变成这样：

我们看main.cpp，这个文件的初始内容如下：

#include "mainwindow.h"

#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();
    return a.exec();
}

下面简单修改一下这个文件，删除掉对mainwindow.h文件的引用和对MainWindow类的实例化相关代码。我们在之前看到的那个标题为MainWindow的窗体实际上就是这个类生成的。删除后的代码如下所示：

#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    
    return a.exec();
}

现在看到的就是一个QT程序的最基本框架了。下面我们填充一个按钮到这个QT程序里，让按钮显示Hello World。

#include <QApplication>
#include <QPushButton> // QPushButton这个类提供按钮组件

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    // 实例化一个按钮，这里传给构造函数的值会被设置为按钮显示的文字
    // 除此之外还可以通过按钮类提供的setText方法来设置，后面会讲
    QPushButton *button = new QPushButton("Hello World"); 
    button->show(); // 调用show方法，显示组件。

    return a.exec();
}

之后运行程序就可以看到第一个QT程序跑起来了~他可能很简陋，但战略意义远大于战术意义。