这里是 LitePress 社区旧贴存档，您可以在此留言或提交新的回应和信息。
LitePress 社区旧贴存档 2020~2023 年度
文章投稿 139 篇
参与 1035 次讨论和 239 条回复
投稿·赢取 Wapuu 纪念品
20 周年限量版
发表评论
2,005 条回复
-
腾讯云官方有专门的插件，直接安装之后根据里面的设置要求进行设置即可
搜索关键词：tencentcloud
来自成都 -
点击域名 第一个域名管理 直接添加
来自成都 -
这。。。。。。。。
直接网站管理里添加域名他不香。
解析过去直接绑，啥都不设置。
你们为啥想那么复杂。
来自许昌 -
-
刚整理术语表的时候突然想起来，中文翻译的时候是不是可以忽略掉单复数了。这样术语表里只记录单数，然后程序匹配的时候单数和复数都去匹配这条术语？不知道这样会不会产生一些翻译错误。
来自秦皇岛 -
现在这个阶段讲的话我觉得就是你说的这样。
更深层次阐述一下，这个和我本人一直奉行的发展策略有关。
我觉得我唯一成功的方式是通过一个优势点去撬动其他点，在不断的资源整合中变得强大。这个策略适用于我在做的几乎所有的事情。
往大的方面举例子，就好像我从 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
来自南充 -
已找到合适的插件，插件名 【plus webp 】 （https://litepress.cn/plugins/plus-webp），虽然功能不全，可以将就使用。
<h3> 插件设置截图</h3>
与又拍云云存储插件做了兼容测试，测试完美。
我只用又拍云存储，没有腾讯云阿里云等对象存储服务，请自行测试。
<h3> 又拍云云存储插件</h3>
以下两个插件都可以使用，任选其一。一、 https://litepress.cn/plugins/wpupyun
二、 https://litepress.cn/plugins/uss-upyun
来自南充 -
是有必要的，前面也说了，站点地图可以让蜘蛛更快的发现你的新增内容。
你说的百度不兼容站点地图是什么情况？遇到报错了还是有什么文件提到了？
来自秦皇岛 -
当初这么设计主要是考虑到这个需求或许并不常见，因为头像作为一个人的网络标识，想当然的每个人应该只有一个，但一个人难免有多个邮箱，所以就想为多个邮箱都绑定到这一个头像上。
而需要多个头像情况更多是注册马甲账号，考虑到实现上的便捷性，也就需要对业务逻辑解耦，所以打算如果是马甲的话用户就新注册一个号。
当然，以上结论也不排除是因为我的认知偏差所下的错误结论，所以如果这个功能后面呼声高的话还是会搞，最终还是以用户实际需求为准。
最后就是，Cravatar 并不是我一个人做的，至少前端部分我是一点没碰的，这一块是老李头在负责。所以把整个项目归为 「我的项目」 实在是感觉不自在。
来自秦皇岛 -
那么 WordPress 自带的 xml 站点地图有没有必要 貌似这种地图还不支持百度
-
查看 MySQL 配置文件中是否包含了名为
innodb_force_recovery的参数，这个参数就是配置 MySQL 恢复级别的。另外开启了 Redis 缓存也可能造成配置不更新，建议查看下数据库中的数据是否已经被更新过而只是网站后台不显示？
-
现在的问题只剩，，保存配置后刷新，配置没变，上面说的恢复模式是什么意思
来自聊城 -
还有主题也要换成 wp 的默认主题
-
我没有手动改过数据库文件。。
插件的话我全部关闭了。。我等下再试试
来自聊城 -
从你的描述看，如果你确信你已经完全删除了所有老网站的文件和数据库 （也包括 Nginx 的伪静态配置），那么现在就已经和你折腾站群没关系了。
我上面询问的俩问题也没回复我，问题得靠排查，不配合的话要如何定位，毕竟我也不是神仙。
-
刚才在折腾 wordpress 站群，，没弄成就来恢复数据库和网站文件。。然后就这样了
如何解决呢
来自聊城
发表回复