他在 LitePress 的市场里叫做 hCaptcha for WordPress，在 wordpress 的后台里叫做 hCaptcha for Forms and More，在后台点击翻译按钮会跳转到 https://litepress.cn/translate/projects/plugins/hcaptcha-for-forms-and-more
文派叶子 🍃
第一个项目我好像没检索到？发现似乎只有：hCaptcha for WordPress 、 G-Forms hCaptcha 、 Mailster hCaptcha 。
《“ 参与者列表” 》 有 2,005 条评论
你把 Autoptimze 和 WPJAM 两个插件关掉试试
行吧，有空我测试下，没啥提升就卸了
f12 看看网络请求，截图贴上来。
这个估计是你做了动静分离，然后要么 CDN 那边没配置好回源 Host，要么防盗链配错了。
你这四个插件，我都用过，我觉得只用 rocket 缓存插件和对象存储插件就够了，另两个插件没必要使用。
要不然修改数据库 要不然 用别名 替代吧。
感觉好像确实快了 666
可以用 wpjam 里面的，果酱在维护更新
已添加权限
hCaptcha for WordPress
他在 LitePress 的市场里叫做 hCaptcha for WordPress，在 wordpress 的后台里叫做 hCaptcha for Forms and More，在后台点击翻译按钮会跳转到 https://litepress.cn/translate/projects/plugins/hcaptcha-for-forms-and-more
第一个项目我好像没检索到？发现似乎只有：hCaptcha for WordPress 、 G-Forms hCaptcha 、 Mailster hCaptcha 。
第二个项目已经添加了权限：https://litepress.cn/translate/projects/plugins/featured-image-from-url/
hCaptcha for Forms and More
Featured Image from URL (FIFU)
谢谢老板
二者应该同时存在。已经存在的内容目测是宝塔为了防止跨站攻击而添加的，用于限制 WEB 程序可读写的目录范围，删了不会报错，但是有安全隐患。
如果需要按文章发布日期升序更新的话 （也就是先更老文章），将代码改成如下即可：
function update_all_posts() { $args = array( 'post_type' => 'post', 'numberposts' => -1, 'orderby' => 'post_date', 'order' => 'ASC', ); $all_posts = get_posts($args); foreach ($all_posts as $single_post){ $single_post->post_title = $single_post->post_title.''; wp_update_post( $single_post ); } } add_action( 'wp_loaded', 'update_all_posts' );老实说，我非常不理解你这个需求，甚至于感觉匪夷所思。我无法理解为什么文章的更新时间会影响文章的顺序，但是还是按你的需求修改了一下代码。
我需要从很久之前发布的第一个文章 陆续更新到 最新发布的文章。 （这样更新下来，最新发的文章还是在最前面）
顺序变了？你是根据最后更新日期排序吗？改成以文章创建日期排序呗。不然你将来保存一下老文章就会打乱排序。
但是 文章的顺序变了。。这个咋整
我知道了，没有修改 PHP memory_limit
提示这个，怎么处理呢？
把以下代码放到主题的 functions.php 文件里，然后随便访问一个网页，就对所有文章触发更新操作了。更新完记得删掉这段代码。
function update_all_posts() { $args = array( 'post_type' => 'post', 'numberposts' => -1 ); $all_posts = get_posts($args); foreach ($all_posts as $single_post){ $single_post->post_title = $single_post->post_title.''; wp_update_post( $single_post ); } } add_action( 'wp_loaded', 'update_all_posts' );如果你的文章数量很多的话需要改一下 PHP 的最大执行时间。
谢谢，找到了
点分类的编辑按钮，然后浏览器地址栏有一个名为 tag_id 的查询参数，那个就是了
我感觉，你们做 litepress 的项目就是针对国内的 WP 用户群，如果推回给官方，用户选择性就多了，分散了用户。
分类 ID 我的博客好像可以直接显示
不太清楚原来有没有，有可能是主题或插件添加的
还可以在编辑分类时看地址栏上的
tag_ID已驳回
不好意思，白天去交接税务了，刚回来。
我重装了 php 之后他莫名其妙的好了, 然而我上午重装了好几次, 都没用, 离谱
可以看看 sakura 改的一个，应该算是更完善的
https://github.com/mirai-mamori/Sakurairo
所有翻译会存在于本地平台，不会回推给 wordpress.org，这个老实说技术上可以实现数据回流，但是我们也确实是有意的不会这样做。
这就好像子贡赎人的典故一样，子贡好心的拒绝了赎金，其产生的后果是将来都不会有人再主动去营救鲁国的奴隶。代入到现在这个项目也是一样，如果我们好心的主动把数据同步给 wordpress.org，我们将始终难以在本地化生态积累的层面上超过 wordpress.org，也就没理由说服用户选择本地平台，长久来看本地平台也就几乎不可能得到发展。
但，如果我们不做数据回流，则可以逐渐加大两个平台的差异化，而且本地平台等于 wordpress.org 的超集，将来势必会倒逼用户选择本地平台，有了用户基数就有了贡献者和参与到这一体系的开发者，本地平台也就有了崛起的可能。
应用市场目前上确实是按二者并存为出发点设计的，也就是说将来可以完全脱离 wordpress.org 。但就像前面的翻译平台一样，本地的应用市场上架的应用同样不会回流给 wordpress.org（况且付费和闭源的应用也没法回流） 。
你是指的插件端的吗？插件端的 API 前段时间重构了，后来因为翻译平台的开发比较紧张所以暂时搁置，目前只重构完了翻译推送相关的 API 功能。
关于重构这个，其实 litepress.cn 平台各个子模块都最少重构了三次，重构的多并不值得炫耀，这其实映射的是我本人在工程化开发方面的经验很缺乏，于是造成了开发好一个功能，但是很快的发现这个功能在融入总的工程后在将来的可维护性、扩展性、各模块联动性方面存在缺失，于是只能重构。周而复始的重构与迭代，我难以在早期就预料到所有情况，所以只能很无奈的承担下多出来的重构成本。
路长且艰，但我觉得我们或许是过去十年间最有可能做成这件事的人。
想知道这里参与的插件翻译是留在本土还是说会推回给上游
应用市场方面个人使用更倾向于扩展，如果可以两边的市场都能同时访问到就更好了
（试用 LitePress 市场的时候报了 504，不知道是这边还没完善还是自己服务器有什么设置限制了）
在这种环境下有一个本土优化是好事，但路还很长，加油