參與者列表 Search 感謝 2020 ~ 2023.4 所有關注過 LitePress 的用户 此版已存檔，詳情參見 《推廣名單》 《“ 參與者列表” 》 有 2,005 條評論 bnqdzj 2021.10.31 hCaptcha for Forms and More Featured Image from URL (FIFU) 5323 2021.10.29 謝謝老闆 文派葉子 🍃 2021.10.29 二者應該同時存在。已經存在的內容目測是寶塔為了防止跨站攻擊而添加的，用於限制 WEB 程序可讀寫的目錄範圍，刪了不會報錯，但是有安全隱患。 文派葉子 🍃 2021.10.29 如果需要按文章發佈日期升序更新的話 （也就是先更老文章），將代碼改成如下即可： 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' ); 老實説，我非常不理解你這個需求，甚至於感覺匪夷所思。我無法理解為什麼文章的更新時間會影響文章的順序，但是還是按你的需求修改了一下代碼。 yuanmaking 2021.10.29 我需要從很久之前發佈的第一個文章 陸續更新到 最新發布的文章。 （這樣更新下來，最新發的文章還是在最前面） 文派葉子 🍃 2021.10.28 順序變了？你是根據最後更新日期排序嗎？改成以文章創建日期排序唄。不然你將來保存一下老文章就會打亂排序。 yuanmaking 2021.10.28 但是 文章的順序變了。。這個咋整 yuanmaking 2021.10.28 我知道了，沒有修改 PHP memory_limit 文派葉子 🍃 2021.10.28 把以下代碼放到主題的 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 的最大執行時間。 yuanmaking 2021.10.28 謝謝，找到了 文派葉子 🍃 2021.10.28 點分類的編輯按鈕，然後瀏覽器地址欄有一個名為 tag_id 的查詢參數，那個就是了 reishi 2021.10.28 我感覺，你們做 litepress 的項目就是針對國內的 WP 用户羣，如果推回給官方，用户選擇性就多了，分散了用户。 文派葉子 🍃 2021.10.27 已駁回 文派葉子 🍃 2021.10.27 不好意思，白天去交接税務了，剛回來。 yuexuan 2021.10.27 我重裝了 php 之後他莫名其妙的好了, 然而我上午重裝了好幾次, 都沒用, 離譜 dazaiyuki 2021.10.25 可以看看 sakura 改的一個，應該算是更完善的 https://github.com/mirai-mamori/Sakurairo 文派葉子 🍃 2021.10.25 想知道這裏參與的插件翻譯是留在本土還是説會推回給上游 所有翻譯會存在於本地平台，不會回推給 wordpress.org，這個老實説技術上可以實現數據迴流，但是我們也確實是有意的不會這樣做。 這就好像子貢贖人的典故一樣，子貢好心的拒絕了贖金，其產生的後果是將來都不會有人再主動去營救魯國的奴隸。代入到現在這個項目也是一樣，如果我們好心的主動把數據同步給 wordpress.org，我們將始終難以在本地化生態積累的層面上超過 wordpress.org，也就沒理由説服用户選擇本地平台，長久來看本地平台也就幾乎不可能得到發展。 但，如果我們不做數據迴流，則可以逐漸加大兩個平台的差異化，而且本地平台等於 wordpress.org 的超集，將來勢必會倒逼用户選擇本地平台，有了用户基數就有了貢獻者和參與到這一體系的開發者，本地平台也就有了崛起的可能。 應用市場方面個人使用更傾向於擴展，如果可以兩邊的市場都能同時訪問到就更好了 應用市場目前上確實是按二者並存為出發點設計的，也就是説將來可以完全脱離 wordpress.org 。但就像前面的翻譯平台一樣，本地的應用市場上架的應用同樣不會迴流給 wordpress.org（況且付費和閉源的應用也沒法迴流） 。 試用 LitePress 市場的時候報了 504，不知道是這邊還沒完善還是自己服務器有什麼設置限制了 你是指的插件端的嗎？插件端的 API 前段時間重構了，後來因為翻譯平台的開發比較緊張所以暫時擱置，目前只重構完了翻譯推送相關的 API 功能。 關於重構這個，其實 litepress.cn 平台各個子模塊都最少重構了三次，重構的多並不值得炫耀，這其實映射的是我本人在工程化開發方面的經驗很缺乏，於是造成了開發好一個功能，但是很快的發現這個功能在融入總的工程後在將來的可維護性、擴展性、各模塊聯動性方面存在缺失，於是只能重構。週而復始的重構與迭代，我難以在早期就預料到所有情況，所以只能很無奈的承擔下多出來的重構成本。 在這種環境下有一個本土優化是好事，但路還很長，加油 路長且艱，但我覺得我們或許是過去十年間最有可能做成這件事的人。 dazaiyuki 2021.10.25 想知道這裏參與的插件翻譯是留在本土還是説會推回給上游 應用市場方面個人使用更傾向於擴展，如果可以兩邊的市場都能同時訪問到就更好了 （試用 LitePress 市場的時候報了 504，不知道是這邊還沒完善還是自己服務器有什麼設置限制了） 在這種環境下有一個本土優化是好事，但路還很長，加油 文派葉子 🍃 2021.10.24 這是個 BUG 。有一些字符串沒翻譯是因為這個項目沒託管到翻譯平台，所以很多字符串沒收錄，對於沒收錄的字符串翻譯引擎是不會處理的。然後插件那邊在處理這種情況的時候直接引用了原文，於是造成了很多字符串的翻譯被使用原文填充的情況。 這個問題今天發的版本中會處理 文派葉子 🍃 2021.10.24 應該是你做了公安備案，然後當地的王安在掃漏洞。因為我發現這些 IP 都是廣西的。 smile 2021.10.24 抱歉太極沒表達清楚，就是我在使用自動機器翻譯完成之後發現有很多字符串在翻譯的位置直接填充了原文，特別是一些長一點的語句 lutofan 2021.10.23 好的 感謝！ 文派葉子 🍃 2021.10.23 不好意思，我剛看見這條回覆。 不過我沒太明白你的意思，能再詳細點嗎？ post 2021.10.22 如果是指文章鏈接上的，，把 「固定鏈接」 設置為任意非 「樸素」 的形式，然後每一篇文章都可以想改什麼序號就改什麼序號了，並且每次發文章都要自己寫序號，不要覺得麻煩，搞這些神仙事情總要付出點代價的。 文派葉子 🍃 2021.10.22 從你的描述來看，應該就是某個插件篡改了固定鏈接導致的。 這個問題需要一點點定位，逐漸縮小範圍。目前如果懷疑是固定鏈接被篡改的話，需要你在下次發生 404 的時候查看一下 wp_options 數據表中 meta_key 為 permalink_structure 的行，看看其 meta_value 字段是否就是你設置的固定鏈接值 （對於 Nginx 來説，更新固定鏈接只需要改這裏的值即可，所以説通過觀察其值也可以直接得知是否被篡改，這不像 Apache 還需要查看 .htaccess 文件） 。 如果確認是被篡改的話要麼是把插件禁用挨個查，要麼是用 xdebug 記錄 PHP 執行堆棧，找到觸發會更改固定鏈接的 SQL 語句的執行位置，再順藤摸瓜向上查到具體是哪個插件搞的。不過這需要有一點點技術能力才行，我暫時沒想到有什麼簡單的方法能查出來。 文派葉子 🍃 2021.10.22 我着實沒懂你的意思。能再描述清楚點嗎？ 或者，是不是你之前設置了 WordPress 的 ID 連續，然後刪除了一些文章導致 ID 之間存在空缺？如果是這樣的話據我所知是沒有辦法能做到重新給文章 ID 排序的，因為文章 ID 可能會關聯很多數據，改了會很麻煩。 smile 2021.10.21 現在存在的一個問題就是，有一些字符串的翻譯會直接填充原文 文派葉子 🍃 2021.10.20 話説，昨晚的一個項目託管申請是你提交的嗎？我傻逼了，忘了記錄提交者是誰了，加管理員都不知道給誰加 post 2021.10.19 厲害了，不鳴則已，一鳴驚人，持續關注。 5323 2021.10.18 好的 ，謝謝~ ←較舊評論 1 … 39 40 41 42 43 … 63 較新評論→
《“ 參與者列表” 》 有 2,005 條評論
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 用户羣，如果推回給官方，用户選擇性就多了，分散了用户。
已駁回
不好意思，白天去交接税務了，剛回來。
我重裝了 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，不知道是這邊還沒完善還是自己服務器有什麼設置限制了）
在這種環境下有一個本土優化是好事，但路還很長，加油
這是個 BUG 。有一些字符串沒翻譯是因為這個項目沒託管到翻譯平台，所以很多字符串沒收錄，對於沒收錄的字符串翻譯引擎是不會處理的。然後插件那邊在處理這種情況的時候直接引用了原文，於是造成了很多字符串的翻譯被使用原文填充的情況。
這個問題今天發的版本中會處理
應該是你做了公安備案，然後當地的王安在掃漏洞。因為我發現這些 IP 都是廣西的。
抱歉太極沒表達清楚，就是我在使用自動機器翻譯完成之後發現有很多字符串在翻譯的位置直接填充了原文，特別是一些長一點的語句
好的 感謝！
不好意思，我剛看見這條回覆。
不過我沒太明白你的意思，能再詳細點嗎？
如果是指文章鏈接上的，，把 「固定鏈接」 設置為任意非 「樸素」 的形式，然後每一篇文章都可以想改什麼序號就改什麼序號了，並且每次發文章都要自己寫序號，不要覺得麻煩，搞這些神仙事情總要付出點代價的。
從你的描述來看，應該就是某個插件篡改了固定鏈接導致的。
這個問題需要一點點定位，逐漸縮小範圍。目前如果懷疑是固定鏈接被篡改的話，需要你在下次發生 404 的時候查看一下 wp_options 數據表中 meta_key 為 permalink_structure 的行，看看其 meta_value 字段是否就是你設置的固定鏈接值 （對於 Nginx 來説，更新固定鏈接只需要改這裏的值即可，所以説通過觀察其值也可以直接得知是否被篡改，這不像 Apache 還需要查看 .htaccess 文件） 。
如果確認是被篡改的話要麼是把插件禁用挨個查，要麼是用 xdebug 記錄 PHP 執行堆棧，找到觸發會更改固定鏈接的 SQL 語句的執行位置，再順藤摸瓜向上查到具體是哪個插件搞的。不過這需要有一點點技術能力才行，我暫時沒想到有什麼簡單的方法能查出來。
我着實沒懂你的意思。能再描述清楚點嗎？
或者，是不是你之前設置了 WordPress 的 ID 連續，然後刪除了一些文章導致 ID 之間存在空缺？如果是這樣的話據我所知是沒有辦法能做到重新給文章 ID 排序的，因為文章 ID 可能會關聯很多數據，改了會很麻煩。
現在存在的一個問題就是，有一些字符串的翻譯會直接填充原文
話説，昨晚的一個項目託管申請是你提交的嗎？我傻逼了，忘了記錄提交者是誰了，加管理員都不知道給誰加
厲害了，不鳴則已，一鳴驚人，持續關注。
好的 ，謝謝~