他在 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，不知道是這邊還沒完善還是自己服務器有什麼設置限制了）
在這種環境下有一個本土優化是好事，但路還很長，加油