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