參與者列表 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 可能會關聯很多資料，改了會很麻煩。
現在存在的一個問題就是，有一些字串的翻譯會直接填充原文
話說，昨晚的一個專案託管申請是你提交的嗎？我傻逼了，忘了記錄提交者是誰了，加管理員都不知道給誰加
厲害了，不鳴則已，一鳴驚人，持續關注。
好的 ，謝謝~