参与者列表 Search 感谢 2020 ~ 2023.4 所有关注过 LitePress 的用户 此版已存档，详情参见 《推广名单》 《“ 参与者列表” 》 有 2,005 条评论 5323 2021.08.21 宝塔是不是可以防火墙 ip. 文派叶子 🍃 2021.08.21 在站点 Nginx 的 location / 中加入以下配置： deny ::; 参见： Nginx 官方文档中对 ngx_http_access_module 的描述：http://nginx.org/en/docs/http/ngx_http_access_module.html IBM 官方文档中对特殊 IPv6 地址的描述：https://www.ibm.com/docs/en/zos/2.4.0?topic=applications-special-ipv6-addresses smallsaltedfish 2021.08.20 哟西 文派叶子 🍃 2021.08.20 如果是内部调用的话可以设置白名单 IP，仅允许来自该 IP 的访问。这个方案应该是最安全的。 文派叶子 🍃 2021.08.20 以下语句按执行优先级拆解一下： isset($options['smtp_password']) ?? '111'; 最优先执行的 isset($options['smtp_password']) 的返回值是 true 或 false 。 之后使用 ?? 来判断 isset($options['smtp_password']) 是否已定义，想当然的是按 true 处理的，于是这个语句最后返回的值就是三目左侧的 true 或 false，而不是选项值。 正确写法应该是： $phpmailer->Password = $options['smtp_password'] ?? '111'; biggerm 2021.08.20 腾讯云官方有专门的插件，直接安装之后根据里面的设置要求进行设置即可 搜索关键词：tencentcloud linn 2021.08.20 点击域名 第一个域名管理 直接添加 divivityan 2021.08.19 这。。。。。。。。 直接网站管理里添加域名他不香。 解析过去直接绑，啥都不设置。 你们为啥想那么复杂。 文派叶子 🍃 2021.08.19 参见： 后台加载慢，有什么办法可以找出问题 – LitePress 社区 文派叶子 🍃 2021.08.19 刚整理术语表的时候突然想起来，中文翻译的时候是不是可以忽略掉单复数了。这样术语表里只记录单数，然后程序匹配的时候单数和复数都去匹配这条术语？不知道这样会不会产生一些翻译错误。 文派叶子 🍃 2021.08.19 现在这个阶段讲的话我觉得就是你说的这样。 更深层次阐述一下，这个和我本人一直奉行的发展策略有关。 我觉得我唯一成功的方式是通过一个优势点去撬动其他点，在不断的资源整合中变得强大。这个策略适用于我在做的几乎所有的事情。 往大的方面举例子，就好像我从 12 岁就开始自学编程，对计算机的了解和编程知识就是我作为一个社会底层人士在前期积累中的一个优势点。在日后的日子里我不断通过这个优势点去撬动其他资源，比如说老师们更愿意和我保持朋友关系，而不仅仅是上完课就走的塑料师生关系，原因就在于我有一技之长，虽然作为一个学生在地位上无法和他们相提并论，但是我可以和他们形成优势互补，他们自己做项目或者帮别人做项目或多或少都要咨询我。 往小的方面说，比如 WP-China-Yes 这个项目刚起步的时候，很多人说 「我们早就想到了，只是碍于成本没做」 。但是我一直在说的是只要有用户使用，我就可以靠用户资源这个优势点去拉动赞助来填平成本，我觉得日后的事实证明我是对的。 整个逻辑就好像是手摇式拖拉机的启动过程，单凭发动机自己虽然力量存在，但是找不到做功的着力点 （类比一下，就好像现实世界中我的老师这一力量存在，赞助我的商家这一力量也是现实存在的，他们只是对我或我在做的事来讲找不到或者说不想找到做工的着力点），而我要做的就是去用摇把摇一下 （创造优势点），给发动机一个初始的力，有了这个初始的力后发动机的各个机件就会不断的加入到工作循环，直到所有机件都被带动起来之后，甚至我不摇它它也会凭借发动机做工而运转下去。 前面还只是拿我个人发展举例子，如果代入 WordPress 生态发展上来讲： 我觉得 WordPress 生态是根上烂了，也就是我在发展计划里说的是，强制 GPL 及不支持国内的小程序体系。前者阻碍生态原始积累，后者把 WP 锁死在 PC 端。 所以说做这件事第一步就是刮骨疗毒重新打一套新的地基 （新的 LitePress 发行版与 liitepress.cn），之后也就是融入我前面讲的通过优势点不断整合资源的思想。 比如通过 China Yes 的存量用户与开发者交换流量的方式要求开发者入驻，越多的开发者入驻后筹码和能力就会越大。 再比如通过完善的翻译和其他优势以及适当的引导，撬动用户主动参与翻译过程。这就是咱们本次讨论的话题，我觉得通过机器翻译填充起来的 100% 汉化的仓库或许是打出与 w.org 差异以撬动用户在新体系下贡献翻译的点，我需要做的就是集中力量加大这一优势点，以让更多人参与进来，由大家一起完善资源，而不是尽善尽美地都自己去做，这样老实说也不大现实，就好像我作为一个穷人不可能仅凭自己完成所有积累然后实现最终理想。 通过以优势点不断撬动资源的方式，在不久的将来，很大一部分的开发者、译者、普通用户将会参与到这个新体系中，待到时局一变 （w.org 被墙或再来一次 429），届时就是彻底实现整个计划的时刻了。 之后目标就会从内部统一转换为向外扩张，理想状态下 WordPress 将渗透入中小企业应用场景的方方面面，而不止于建站系统。 改变世界或许太远了，先从改变行业开始吧！ fanly 2021.08.19 来关注一下，我也是一枚 WordPress 爱好者。 文派叶子 🍃 2021.08.19 在证书配置那勾选强制 https，这样访问 http 就跳到 https 了，http 不能单独访问 smile 2021.08.18 我想了想：litepress.cn 的术语表是用于对机器翻译的错误词汇进行纠正的，所以应只需包含机器翻译会出错的术语，这样条目也不会太多，也顺便减少了你说的替换过多而无法翻译的情况，这样可能就需要对术语表进行适当的增减了。 文派叶子 🍃 2021.08.18 你说的这个需求在单一的站点理应是也能实现的，把你的站点 Nginx 配置文件贴上来瞧瞧 （用论坛编辑器带的代码插入功能贴） ndwsj 2021.08.18 哦 好吧 我干脆直接重新新建一个站点好了 不凡 2021.08.18 那就新建站点，设置重定向到另一个站点的域名。 文派叶子 🍃 2021.08.18 按道理讲术语表属于是技多不压身的东西，对于人类翻译的话条目理应是越多越好。 我前面表达的观点主要是从机器翻译填充和成本投入的角度出发的，因为举个例子，如果一个句子比如说 10 个单词，其中有 3 个都命中术语表被替换成代码的话谷歌就翻译不出来了。 同时，对于我们来讲，整理数据这种枯燥的工作只能是我自己做，毕竟己所不欲勿施于人。但是我的时间老实说也蛮紧张的，所以说没法在这上面投入太大精力。目前计划术语表整理的规模大概在 200 条，今天下午实践看，精校 20 条+收集整理资料的时间大概是一个小时，200 条大概是两天全天的工作量，但是老实说这种枯燥的工作我很难满效率搞两天，所以总时间大概延长一倍。。 总结一下就是综合以下三个方面的考量，我现阶段希望建立一个较小的术语表： 利于机器翻译 较小的成本投入 大而全的术语表似乎并非必要 其实对机器翻译的影响应该可以通过技术方案规避 （比如说限制下机器只读取某些术语），最主要的问题还是成本投入。 如果你愿意整理的话我不介意白嫖一份 （大笑。 当然我整理的你也可以导出使用。 smile 2021.08.18 翻译一致性检查工具我觉得能做的话就做出来吧，可以对一些字词或句子的翻译进行查找还是很有必要的，方便参考，如果有些字词出现的频率比较高而又在术语表中找不到也可以用上 smile 2021.08.18 我是准备打算用 wp-info 把 wp.org 的术语表重新整理一遍的，然后按照情况去除掉一些条目，然后把以前术语表的一部分条目保留下来 （仅限整理后的数与表不包含的条目，即整理之前手动添加上的条目） 文派叶子 🍃 2021.08.18 你如果感觉这个 w.org 的术语列表可以的话我开发一个自动同步工具，从 w.org 上抓取这个列表填充到翻译平台的术语表中，后面也随着 w.org 上的更新而增量更新 文派叶子 🍃 2021.08.18 我在 WordPress.org 的支持文档中翻到了这一篇官方建议的术语表列表： https://wordpress.org/support/article/glossary/ 按上面说的，术语表存在的意义在于让不了解 WordPress 的人能正确的使用 WordPress 专有的术语 进行翻译，而不是对通用词汇提供翻译指北以实现类似 《英汉词典》 这种大而全的词汇对照。 而上面的文档中列出的也就是如前所述的 「WordPress 专有术语」 。 wp-info.org 上的术语表中存在很多类似 「administrator」 这种几乎只对应唯一翻译的词汇，以及类似 「approval」 这种在不同地方存在不同译文的词汇，这样的话我感觉整体范围太宽泛了，变成了前面说的 《英汉词典》 而有悖术语表的初衷。 如果是想通过术语表让翻译保持一致的话，我在想是不是也要提供一个翻译一致性检查工具，由这个工具来确保翻译一致，而不是通过术语表。 smile 2021.08.17 我觉得术语表应该需要以这个为基础重新整理一下 https://wp-info.org/p/glossaries.csv 这里面条目比较全 5323 2021.08.17 好的 谢谢~大哥 文派叶子 🍃 2021.08.17 没有太好的办法，我上次也被刷的裤衩都要卖了。 又拍云提供了访问速率限制以及防 CC 功能，但是实际测试来看并不会起任何作用。 该问题目前唯一的解决方案就是如果你网站不需要面向老外的话可以在屏蔽掉海外 IP，又拍云提供访问地域限制功能，海外 IP 屏蔽后能预防绝大部分 CC 攻击。 其次就是在被打的时候手工通过日志分析攻击者 IP，然后手工拉黑了，不过这个在面对攻击者使用代理 IP 的情况时就很无力了。 高风险的业务不建议使用这种按量付费的 CDN，就算换阿里、腾讯也一样给你刷到破产。最好是使用百度云减速这种预付费的 CDN，不管你被刷多少反正一年就几百块，超量了最多回源而已。 只是普通的个人博客的话可以不用担心这个。我自己的博客日 IP 大概 200，四年了也没被打过一次。前面说被刷的是 Cravatar 的头像服务。 不凡 2021.08.17 这两插件我都用过，第二个有第一个的功能，做过简单测试，第二个的效果不是很好，有的地区打开网页秒开，有的地区打开慢了几秒，我现在用的 fastese cache+redis object cache 文派叶子 🍃 2021.08.17 这个检索了下官方的文档：https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/ 目前的代码编写已经符合文档要求了，不能出现在常用区块中可能是古腾堡对区块变体的处理还有 BUG，因为我和老李头都不是 JS 开发方面的专家，所以这个问题得搁置了。 文派叶子 🍃 2021.08.17 类似 WP 大学这样都聚合到一页上提交：https://www.wpdaxue.com/sitemap.xml 。 他使用的是这个插件：https://litepress.cn/plugins/www-xml-sitemap-generator-org sexloli 2021.08.17 百度不支持索引型 xml 地图了 不凡 2021.08.17 后来发现跟我使用的主题有问题，例如文章缩略图在列表中不是居中对齐，TTBF 时间增加到 300 多 ms，已找到替代插件，在楼下 #21387 ←较旧评论 1 … 32 33 34 35 36 … 67 较新评论→
《“ 参与者列表” 》 有 2,005 条评论
宝塔是不是可以防火墙 ip.
在站点 Nginx 的
location /中加入以下配置：参见：
Nginx 官方文档中对
ngx_http_access_module的描述：http://nginx.org/en/docs/http/ngx_http_access_module.htmlIBM 官方文档中对特殊 IPv6 地址的描述：https://www.ibm.com/docs/en/zos/2.4.0?topic=applications-special-ipv6-addresses
哟西
如果是内部调用的话可以设置白名单 IP，仅允许来自该 IP 的访问。这个方案应该是最安全的。
以下语句按执行优先级拆解一下：
最优先执行的
isset($options['smtp_password'])的返回值是 true 或 false 。之后使用
??来判断isset($options['smtp_password'])是否已定义，想当然的是按 true 处理的，于是这个语句最后返回的值就是三目左侧的 true 或 false，而不是选项值。正确写法应该是：
腾讯云官方有专门的插件，直接安装之后根据里面的设置要求进行设置即可
搜索关键词：tencentcloud
点击域名 第一个域名管理 直接添加
这。。。。。。。。
直接网站管理里添加域名他不香。
解析过去直接绑，啥都不设置。
你们为啥想那么复杂。
参见：
后台加载慢，有什么办法可以找出问题 – LitePress 社区
刚整理术语表的时候突然想起来，中文翻译的时候是不是可以忽略掉单复数了。这样术语表里只记录单数，然后程序匹配的时候单数和复数都去匹配这条术语？不知道这样会不会产生一些翻译错误。
现在这个阶段讲的话我觉得就是你说的这样。
更深层次阐述一下，这个和我本人一直奉行的发展策略有关。
我觉得我唯一成功的方式是通过一个优势点去撬动其他点，在不断的资源整合中变得强大。这个策略适用于我在做的几乎所有的事情。
往大的方面举例子，就好像我从 12 岁就开始自学编程，对计算机的了解和编程知识就是我作为一个社会底层人士在前期积累中的一个优势点。在日后的日子里我不断通过这个优势点去撬动其他资源，比如说老师们更愿意和我保持朋友关系，而不仅仅是上完课就走的塑料师生关系，原因就在于我有一技之长，虽然作为一个学生在地位上无法和他们相提并论，但是我可以和他们形成优势互补，他们自己做项目或者帮别人做项目或多或少都要咨询我。
往小的方面说，比如 WP-China-Yes 这个项目刚起步的时候，很多人说 「我们早就想到了，只是碍于成本没做」 。但是我一直在说的是只要有用户使用，我就可以靠用户资源这个优势点去拉动赞助来填平成本，我觉得日后的事实证明我是对的。
整个逻辑就好像是手摇式拖拉机的启动过程，单凭发动机自己虽然力量存在，但是找不到做功的着力点 （类比一下，就好像现实世界中我的老师这一力量存在，赞助我的商家这一力量也是现实存在的，他们只是对我或我在做的事来讲找不到或者说不想找到做工的着力点），而我要做的就是去用摇把摇一下 （创造优势点），给发动机一个初始的力，有了这个初始的力后发动机的各个机件就会不断的加入到工作循环，直到所有机件都被带动起来之后，甚至我不摇它它也会凭借发动机做工而运转下去。
前面还只是拿我个人发展举例子，如果代入 WordPress 生态发展上来讲：
我觉得 WordPress 生态是根上烂了，也就是我在发展计划里说的是，强制 GPL 及不支持国内的小程序体系。前者阻碍生态原始积累，后者把 WP 锁死在 PC 端。
所以说做这件事第一步就是刮骨疗毒重新打一套新的地基 （新的 LitePress 发行版与 liitepress.cn），之后也就是融入我前面讲的通过优势点不断整合资源的思想。
比如通过 China Yes 的存量用户与开发者交换流量的方式要求开发者入驻，越多的开发者入驻后筹码和能力就会越大。
再比如通过完善的翻译和其他优势以及适当的引导，撬动用户主动参与翻译过程。这就是咱们本次讨论的话题，我觉得通过机器翻译填充起来的 100% 汉化的仓库或许是打出与 w.org 差异以撬动用户在新体系下贡献翻译的点，我需要做的就是集中力量加大这一优势点，以让更多人参与进来，由大家一起完善资源，而不是尽善尽美地都自己去做，这样老实说也不大现实，就好像我作为一个穷人不可能仅凭自己完成所有积累然后实现最终理想。
通过以优势点不断撬动资源的方式，在不久的将来，很大一部分的开发者、译者、普通用户将会参与到这个新体系中，待到时局一变 （w.org 被墙或再来一次 429），届时就是彻底实现整个计划的时刻了。
之后目标就会从内部统一转换为向外扩张，理想状态下 WordPress 将渗透入中小企业应用场景的方方面面，而不止于建站系统。
改变世界或许太远了，先从改变行业开始吧！
来关注一下，我也是一枚 WordPress 爱好者。
在证书配置那勾选强制 https，这样访问 http 就跳到 https 了，http 不能单独访问
我想了想：litepress.cn 的术语表是用于对机器翻译的错误词汇进行纠正的，所以应只需包含机器翻译会出错的术语，这样条目也不会太多，也顺便减少了你说的替换过多而无法翻译的情况，这样可能就需要对术语表进行适当的增减了。
你说的这个需求在单一的站点理应是也能实现的，把你的站点 Nginx 配置文件贴上来瞧瞧 （用论坛编辑器带的代码插入功能贴）
哦 好吧 我干脆直接重新新建一个站点好了
那就新建站点，设置重定向到另一个站点的域名。
按道理讲术语表属于是技多不压身的东西，对于人类翻译的话条目理应是越多越好。
我前面表达的观点主要是从机器翻译填充和成本投入的角度出发的，因为举个例子，如果一个句子比如说 10 个单词，其中有 3 个都命中术语表被替换成代码的话谷歌就翻译不出来了。
同时，对于我们来讲，整理数据这种枯燥的工作只能是我自己做，毕竟己所不欲勿施于人。但是我的时间老实说也蛮紧张的，所以说没法在这上面投入太大精力。目前计划术语表整理的规模大概在 200 条，今天下午实践看，精校 20 条+收集整理资料的时间大概是一个小时，200 条大概是两天全天的工作量，但是老实说这种枯燥的工作我很难满效率搞两天，所以总时间大概延长一倍。。
总结一下就是综合以下三个方面的考量，我现阶段希望建立一个较小的术语表：
其实对机器翻译的影响应该可以通过技术方案规避 （比如说限制下机器只读取某些术语），最主要的问题还是成本投入。
如果你愿意整理的话我不介意白嫖一份 （大笑。
当然我整理的你也可以导出使用。
翻译一致性检查工具我觉得能做的话就做出来吧，可以对一些字词或句子的翻译进行查找还是很有必要的，方便参考，如果有些字词出现的频率比较高而又在术语表中找不到也可以用上
我是准备打算用 wp-info 把 wp.org 的术语表重新整理一遍的，然后按照情况去除掉一些条目，然后把以前术语表的一部分条目保留下来 （仅限整理后的数与表不包含的条目，即整理之前手动添加上的条目）
你如果感觉这个 w.org 的术语列表可以的话我开发一个自动同步工具，从 w.org 上抓取这个列表填充到翻译平台的术语表中，后面也随着 w.org 上的更新而增量更新
我在 WordPress.org 的支持文档中翻到了这一篇官方建议的术语表列表：
https://wordpress.org/support/article/glossary/
按上面说的，术语表存在的意义在于让不了解 WordPress 的人能正确的使用 WordPress 专有的术语 进行翻译，而不是对通用词汇提供翻译指北以实现类似 《英汉词典》 这种大而全的词汇对照。
而上面的文档中列出的也就是如前所述的 「WordPress 专有术语」 。
wp-info.org 上的术语表中存在很多类似 「administrator」 这种几乎只对应唯一翻译的词汇，以及类似 「approval」 这种在不同地方存在不同译文的词汇，这样的话我感觉整体范围太宽泛了，变成了前面说的 《英汉词典》 而有悖术语表的初衷。
如果是想通过术语表让翻译保持一致的话，我在想是不是也要提供一个翻译一致性检查工具，由这个工具来确保翻译一致，而不是通过术语表。
我觉得术语表应该需要以这个为基础重新整理一下 https://wp-info.org/p/glossaries.csv 这里面条目比较全
好的 谢谢~大哥
没有太好的办法，我上次也被刷的裤衩都要卖了。
又拍云提供了访问速率限制以及防 CC 功能，但是实际测试来看并不会起任何作用。
该问题目前唯一的解决方案就是如果你网站不需要面向老外的话可以在屏蔽掉海外 IP，又拍云提供访问地域限制功能，海外 IP 屏蔽后能预防绝大部分 CC 攻击。
其次就是在被打的时候手工通过日志分析攻击者 IP，然后手工拉黑了，不过这个在面对攻击者使用代理 IP 的情况时就很无力了。
高风险的业务不建议使用这种按量付费的 CDN，就算换阿里、腾讯也一样给你刷到破产。最好是使用百度云减速这种预付费的 CDN，不管你被刷多少反正一年就几百块，超量了最多回源而已。
只是普通的个人博客的话可以不用担心这个。我自己的博客日 IP 大概 200，四年了也没被打过一次。前面说被刷的是 Cravatar 的头像服务。
这两插件我都用过，第二个有第一个的功能，做过简单测试，第二个的效果不是很好，有的地区打开网页秒开，有的地区打开慢了几秒，我现在用的 fastese cache+redis object cache
这个检索了下官方的文档：https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/
目前的代码编写已经符合文档要求了，不能出现在常用区块中可能是古腾堡对区块变体的处理还有 BUG，因为我和老李头都不是 JS 开发方面的专家，所以这个问题得搁置了。
类似 WP 大学这样都聚合到一页上提交：https://www.wpdaxue.com/sitemap.xml 。
他使用的是这个插件：https://litepress.cn/plugins/www-xml-sitemap-generator-org
百度不支持索引型 xml 地图了
后来发现跟我使用的主题有问题，例如文章缩略图在列表中不是居中对齐，TTBF 时间增加到 300 多 ms，已找到替代插件，在楼下 #21387