參與者列表 Search 感謝 2020 ~ 2023.4 所有關注過 LitePress 的用户 此版已存檔，詳情參見 《推廣名單》 《“ 參與者列表” 》 有 2,005 條評論 5323 2021.08.21 寶塔是不是可以防火牆 ip. 文派葉子 🍃 2021.08.21 在站點 Nginx 的 location / 中加入以下配置： deny ::; 參見： Nginx 官方文檔中對 ngx_http_access_module 的描述：http://nginx.org/en/docs/http/ngx_http_access_module.html IBM 官方文檔中對特殊 IPv6 地址的描述：https://www.ibm.com/docs/en/zos/2.4.0?topic=applications-special-ipv6-addresses smallsaltedfish 2021.08.20 喲西 文派葉子 🍃 2021.08.20 如果是內部調用的話可以設置白名單 IP，僅允許來自該 IP 的訪問。這個方案應該是最安全的。 文派葉子 🍃 2021.08.20 以下語句按執行優先級拆解一下： isset($options['smtp_password']) ?? '111'; 最優先執行的 isset($options['smtp_password']) 的返回值是 true 或 false 。 之後使用 ?? 來判斷 isset($options['smtp_password']) 是否已定義，想當然的是按 true 處理的，於是這個語句最後返回的值就是三目左側的 true 或 false，而不是選項值。 正確寫法應該是： $phpmailer->Password = $options['smtp_password'] ?? '111'; biggerm 2021.08.20 騰訊雲官方有專門的插件，直接安裝之後根據裏面的設置要求進行設置即可 搜索關鍵詞：tencentcloud linn 2021.08.20 點擊域名 第一個域名管理 直接添加 divivityan 2021.08.19 這。。。。。。。。 直接網站管理裏添加域名他不香。 解析過去直接綁，啥都不設置。 你們為啥想那麼複雜。 文派葉子 🍃 2021.08.19 參見： 後台加載慢，有什麼辦法可以找出問題 – LitePress 社區 文派葉子 🍃 2021.08.19 剛整理術語表的時候突然想起來，中文翻譯的時候是不是可以忽略掉單複數了。這樣術語表裏只記錄單數，然後程序匹配的時候單數和複數都去匹配這條術語？不知道這樣會不會產生一些翻譯錯誤。 文派葉子 🍃 2021.08.19 現在這個階段講的話我覺得就是你説的這樣。 更深層次闡述一下，這個和我本人一直奉行的發展策略有關。 我覺得我唯一成功的方式是通過一個優勢點去撬動其他點，在不斷的資源整合中變得強大。這個策略適用於我在做的幾乎所有的事情。 往大的方面舉例子，就好像我從 12 歲就開始自學編程，對計算機的瞭解和編程知識就是我作為一個社會底層人士在前期積累中的一個優勢點。在日後的日子裏我不斷通過這個優勢點去撬動其他資源，比如説老師們更願意和我保持朋友關係，而不僅僅是上完課就走的塑料師生關係，原因就在於我有一技之長，雖然作為一個學生在地位上無法和他們相提並論，但是我可以和他們形成優勢互補，他們自己做項目或者幫別人做項目或多或少都要諮詢我。 往小的方面説，比如 WP-China-Yes 這個項目剛起步的時候，很多人説 「我們早就想到了，只是礙於成本沒做」 。但是我一直在説的是隻要有用户使用，我就可以靠用户資源這個優勢點去拉動贊助來填平成本，我覺得日後的事實證明我是對的。 整個邏輯就好像是手搖式拖拉機的啓動過程，單憑發動機自己雖然力量存在，但是找不到做功的着力點 （類比一下，就好像現實世界中我的老師這一力量存在，贊助我的商家這一力量也是現實存在的，他們只是對我或我在做的事來講找不到或者説不想找到做工的着力點），而我要做的就是去用搖把搖一下 （創造優勢點），給發動機一個初始的力，有了這個初始的力後發動機的各個機件就會不斷的加入到工作循環，直到所有機件都被帶動起來之後，甚至我不搖它它也會憑藉發動機做工而運轉下去。 前面還只是拿我個人發展舉例子，如果代入 WordPress 生態發展上來講： 我覺得 WordPress 生態是根上爛了，也就是我在發展計劃裏説的是，強制 GPL 及不支持國內的小程序體系。前者阻礙生態原始積累，後者把 WP 鎖死在 PC 端。 所以説做這件事第一步就是刮骨療毒重新打一套新的地基 （新的 LitePress 發行版與 liitepress.cn），之後也就是融入我前面講的通過優勢點不斷整合資源的思想。 比如通過 China Yes 的存量用户與開發者交換流量的方式要求開發者入駐，越多的開發者入駐後籌碼和能力就會越大。 再比如通過完善的翻譯和其他優勢以及適當的引導，撬動用户主動參與翻譯過程。這就是咱們本次討論的話題，我覺得通過機器翻譯填充起來的 100% 漢化的倉庫或許是打出與 w.org 差異以撬動用户在新體系下貢獻翻譯的點，我需要做的就是集中力量加大這一優勢點，以讓更多人蔘與進來，由大家一起完善資源，而不是盡善盡美地都自己去做，這樣老實説也不大現實，就好像我作為一個窮人不可能僅憑自己完成所有積累然後實現最終理想。 通過以優勢點不斷撬動資源的方式，在不久的將來，很大一部分的開發者、譯者、普通用户將會參與到這個新體系中，待到時局一變 （w.org 被牆或再來一次 429），屆時就是徹底實現整個計劃的時刻了。 之後目標就會從內部統一轉換為向外擴張，理想狀態下 WordPress 將滲透入中小企業應用場景的方方面面，而不止於建站系統。 改變世界或許太遠了，先從改變行業開始吧！ fanly 2021.08.19 來關注一下，我也是一枚 WordPress 愛好者。 文派葉子 🍃 2021.08.19 在證書配置那勾選強制 https，這樣訪問 http 就跳到 https 了，http 不能單獨訪問 smile 2021.08.18 我想了想：litepress.cn 的術語表是用於對機器翻譯的錯誤詞彙進行糾正的，所以應只需包含機器翻譯會出錯的術語，這樣條目也不會太多，也順便減少了你説的替換過多而無法翻譯的情況，這樣可能就需要對術語表進行適當的增減了。 文派葉子 🍃 2021.08.18 你説的這個需求在單一的站點理應是也能實現的，把你的站點 Nginx 配置文件貼上來瞧瞧 （用論壇編輯器帶的代碼插入功能貼） ndwsj 2021.08.18 哦 好吧 我乾脆直接重新新建一個站點好了 不凡 2021.08.18 那就新建站點，設置重定向到另一個站點的域名。 文派葉子 🍃 2021.08.18 按道理講術語表屬於是技多不壓身的東西，對於人類翻譯的話條目理應是越多越好。 我前面表達的觀點主要是從機器翻譯填充和成本投入的角度出發的，因為舉個例子，如果一個句子比如説 10 個單詞，其中有 3 個都命中術語表被替換成代碼的話谷歌就翻譯不出來了。 同時，對於我們來講，整理數據這種枯燥的工作只能是我自己做，畢竟己所不欲勿施於人。但是我的時間老實説也蠻緊張的，所以説沒法在這上面投入太大精力。目前計劃術語表整理的規模大概在 200 條，今天下午實踐看，精校 20 條+收集整理資料的時間大概是一個小時，200 條大概是兩天全天的工作量，但是老實説這種枯燥的工作我很難滿效率搞兩天，所以總時間大概延長一倍。。 總結一下就是綜合以下三個方面的考量，我現階段希望建立一個較小的術語表： 利於機器翻譯 較小的成本投入 大而全的術語表似乎並非必要 其實對機器翻譯的影響應該可以通過技術方案規避 （比如説限制下機器只讀取某些術語），最主要的問題還是成本投入。 如果你願意整理的話我不介意白嫖一份 （大笑。 當然我整理的你也可以導出使用。 smile 2021.08.18 翻譯一致性檢查工具我覺得能做的話就做出來吧，可以對一些字詞或句子的翻譯進行查找還是很有必要的，方便參考，如果有些字詞出現的頻率比較高而又在術語表中找不到也可以用上 smile 2021.08.18 我是準備打算用 wp-info 把 wp.org 的術語表重新整理一遍的，然後按照情況去除掉一些條目，然後把以前術語表的一部分條目保留下來 （僅限整理後的數與表不包含的條目，即整理之前手動添加上的條目） 文派葉子 🍃 2021.08.18 你如果感覺這個 w.org 的術語列表可以的話我開發一個自動同步工具，從 w.org 上抓取這個列表填充到翻譯平台的術語表中，後面也隨着 w.org 上的更新而增量更新 文派葉子 🍃 2021.08.18 我在 WordPress.org 的支持文檔中翻到了這一篇官方建議的術語表列表： https://wordpress.org/support/article/glossary/ 按上面説的，術語表存在的意義在於讓不瞭解 WordPress 的人能正確的使用 WordPress 專有的術語 進行翻譯，而不是對通用詞彙提供翻譯指北以實現類似 《英漢詞典》 這種大而全的詞彙對照。 而上面的文檔中列出的也就是如前所述的 「WordPress 專有術語」 。 wp-info.org 上的術語表中存在很多類似 「administrator」 這種幾乎只對應唯一翻譯的詞彙，以及類似 「approval」 這種在不同地方存在不同譯文的詞彙，這樣的話我感覺整體範圍太寬泛了，變成了前面説的 《英漢詞典》 而有悖術語表的初衷。 如果是想通過術語表讓翻譯保持一致的話，我在想是不是也要提供一個翻譯一致性檢查工具，由這個工具來確保翻譯一致，而不是通過術語表。 smile 2021.08.17 我覺得術語表應該需要以這個為基礎重新整理一下 https://wp-info.org/p/glossaries.csv 這裏麪條目比較全 5323 2021.08.17 好的 謝謝~大哥 文派葉子 🍃 2021.08.17 沒有太好的辦法，我上次也被刷的褲衩都要賣了。 又拍雲提供了訪問速率限制以及防 CC 功能，但是實際測試來看並不會起任何作用。 該問題目前唯一的解決方案就是如果你網站不需要面向老外的話可以在屏蔽掉海外 IP，又拍雲提供訪問地域限制功能，海外 IP 屏蔽後能預防絕大部分 CC 攻擊。 其次就是在被打的時候手工通過日誌分析攻擊者 IP，然後手工拉黑了，不過這個在面對攻擊者使用代理 IP 的情況時就很無力了。 高風險的業務不建議使用這種按量付費的 CDN，就算換阿里、騰訊也一樣給你刷到破產。最好是使用百度雲減速這種預付費的 CDN，不管你被刷多少反正一年就幾百塊，超量了最多回源而已。 只是普通的個人博客的話可以不用擔心這個。我自己的博客日 IP 大概 200，四年了也沒被打過一次。前面説被刷的是 Cravatar 的頭像服務。 不凡 2021.08.17 這兩插件我都用過，第二個有第一個的功能，做過簡單測試，第二個的效果不是很好，有的地區打開網頁秒開，有的地區打開慢了幾秒，我現在用的 fastese cache+redis object cache 文派葉子 🍃 2021.08.17 這個檢索了下官方的文檔：https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/ 目前的代碼編寫已經符合文檔要求了，不能出現在常用區塊中可能是古騰堡對區塊變體的處理還有 BUG，因為我和老李頭都不是 JS 開發方面的專家，所以這個問題得擱置了。 文派葉子 🍃 2021.08.17 類似 WP 大學這樣都聚合到一頁上提交：https://www.wpdaxue.com/sitemap.xml 。 他使用的是這個插件：https://litepress.cn/plugins/www-xml-sitemap-generator-org sexloli 2021.08.17 百度不支持索引型 xml 地圖了 不凡 2021.08.17 後來發現跟我使用的主題有問題，例如文章縮略圖在列表中不是居中對齊，TTBF 時間增加到 300 多 ms，已找到替代插件，在樓下 #21387 ←較舊評論 1 … 32 33 34 35 36 … 67 較新評論→
《“ 參與者列表” 》 有 2,005 條評論
寶塔是不是可以防火牆 ip.
在站點 Nginx 的
location /中加入以下配置：參見：
Nginx 官方文檔中對
ngx_http_access_module的描述：http://nginx.org/en/docs/http/ngx_http_access_module.htmlIBM 官方文檔中對特殊 IPv6 地址的描述：https://www.ibm.com/docs/en/zos/2.4.0?topic=applications-special-ipv6-addresses
喲西
如果是內部調用的話可以設置白名單 IP，僅允許來自該 IP 的訪問。這個方案應該是最安全的。
以下語句按執行優先級拆解一下：
最優先執行的
isset($options['smtp_password'])的返回值是 true 或 false 。之後使用
??來判斷isset($options['smtp_password'])是否已定義，想當然的是按 true 處理的，於是這個語句最後返回的值就是三目左側的 true 或 false，而不是選項值。正確寫法應該是：
騰訊雲官方有專門的插件，直接安裝之後根據裏面的設置要求進行設置即可
搜索關鍵詞：tencentcloud
點擊域名 第一個域名管理 直接添加
這。。。。。。。。
直接網站管理裏添加域名他不香。
解析過去直接綁，啥都不設置。
你們為啥想那麼複雜。
參見：
後台加載慢，有什麼辦法可以找出問題 – LitePress 社區
剛整理術語表的時候突然想起來，中文翻譯的時候是不是可以忽略掉單複數了。這樣術語表裏只記錄單數，然後程序匹配的時候單數和複數都去匹配這條術語？不知道這樣會不會產生一些翻譯錯誤。
現在這個階段講的話我覺得就是你説的這樣。
更深層次闡述一下，這個和我本人一直奉行的發展策略有關。
我覺得我唯一成功的方式是通過一個優勢點去撬動其他點，在不斷的資源整合中變得強大。這個策略適用於我在做的幾乎所有的事情。
往大的方面舉例子，就好像我從 12 歲就開始自學編程，對計算機的瞭解和編程知識就是我作為一個社會底層人士在前期積累中的一個優勢點。在日後的日子裏我不斷通過這個優勢點去撬動其他資源，比如説老師們更願意和我保持朋友關係，而不僅僅是上完課就走的塑料師生關係，原因就在於我有一技之長，雖然作為一個學生在地位上無法和他們相提並論，但是我可以和他們形成優勢互補，他們自己做項目或者幫別人做項目或多或少都要諮詢我。
往小的方面説，比如 WP-China-Yes 這個項目剛起步的時候，很多人説 「我們早就想到了，只是礙於成本沒做」 。但是我一直在説的是隻要有用户使用，我就可以靠用户資源這個優勢點去拉動贊助來填平成本，我覺得日後的事實證明我是對的。
整個邏輯就好像是手搖式拖拉機的啓動過程，單憑發動機自己雖然力量存在，但是找不到做功的着力點 （類比一下，就好像現實世界中我的老師這一力量存在，贊助我的商家這一力量也是現實存在的，他們只是對我或我在做的事來講找不到或者説不想找到做工的着力點），而我要做的就是去用搖把搖一下 （創造優勢點），給發動機一個初始的力，有了這個初始的力後發動機的各個機件就會不斷的加入到工作循環，直到所有機件都被帶動起來之後，甚至我不搖它它也會憑藉發動機做工而運轉下去。
前面還只是拿我個人發展舉例子，如果代入 WordPress 生態發展上來講：
我覺得 WordPress 生態是根上爛了，也就是我在發展計劃裏説的是，強制 GPL 及不支持國內的小程序體系。前者阻礙生態原始積累，後者把 WP 鎖死在 PC 端。
所以説做這件事第一步就是刮骨療毒重新打一套新的地基 （新的 LitePress 發行版與 liitepress.cn），之後也就是融入我前面講的通過優勢點不斷整合資源的思想。
比如通過 China Yes 的存量用户與開發者交換流量的方式要求開發者入駐，越多的開發者入駐後籌碼和能力就會越大。
再比如通過完善的翻譯和其他優勢以及適當的引導，撬動用户主動參與翻譯過程。這就是咱們本次討論的話題，我覺得通過機器翻譯填充起來的 100% 漢化的倉庫或許是打出與 w.org 差異以撬動用户在新體系下貢獻翻譯的點，我需要做的就是集中力量加大這一優勢點，以讓更多人蔘與進來，由大家一起完善資源，而不是盡善盡美地都自己去做，這樣老實説也不大現實，就好像我作為一個窮人不可能僅憑自己完成所有積累然後實現最終理想。
通過以優勢點不斷撬動資源的方式，在不久的將來，很大一部分的開發者、譯者、普通用户將會參與到這個新體系中，待到時局一變 （w.org 被牆或再來一次 429），屆時就是徹底實現整個計劃的時刻了。
之後目標就會從內部統一轉換為向外擴張，理想狀態下 WordPress 將滲透入中小企業應用場景的方方面面，而不止於建站系統。
改變世界或許太遠了，先從改變行業開始吧！
來關注一下，我也是一枚 WordPress 愛好者。
在證書配置那勾選強制 https，這樣訪問 http 就跳到 https 了，http 不能單獨訪問
我想了想：litepress.cn 的術語表是用於對機器翻譯的錯誤詞彙進行糾正的，所以應只需包含機器翻譯會出錯的術語，這樣條目也不會太多，也順便減少了你説的替換過多而無法翻譯的情況，這樣可能就需要對術語表進行適當的增減了。
你説的這個需求在單一的站點理應是也能實現的，把你的站點 Nginx 配置文件貼上來瞧瞧 （用論壇編輯器帶的代碼插入功能貼）
哦 好吧 我乾脆直接重新新建一個站點好了
那就新建站點，設置重定向到另一個站點的域名。
按道理講術語表屬於是技多不壓身的東西，對於人類翻譯的話條目理應是越多越好。
我前面表達的觀點主要是從機器翻譯填充和成本投入的角度出發的，因為舉個例子，如果一個句子比如説 10 個單詞，其中有 3 個都命中術語表被替換成代碼的話谷歌就翻譯不出來了。
同時，對於我們來講，整理數據這種枯燥的工作只能是我自己做，畢竟己所不欲勿施於人。但是我的時間老實説也蠻緊張的，所以説沒法在這上面投入太大精力。目前計劃術語表整理的規模大概在 200 條，今天下午實踐看，精校 20 條+收集整理資料的時間大概是一個小時，200 條大概是兩天全天的工作量，但是老實説這種枯燥的工作我很難滿效率搞兩天，所以總時間大概延長一倍。。
總結一下就是綜合以下三個方面的考量，我現階段希望建立一個較小的術語表：
其實對機器翻譯的影響應該可以通過技術方案規避 （比如説限制下機器只讀取某些術語），最主要的問題還是成本投入。
如果你願意整理的話我不介意白嫖一份 （大笑。
當然我整理的你也可以導出使用。
翻譯一致性檢查工具我覺得能做的話就做出來吧，可以對一些字詞或句子的翻譯進行查找還是很有必要的，方便參考，如果有些字詞出現的頻率比較高而又在術語表中找不到也可以用上
我是準備打算用 wp-info 把 wp.org 的術語表重新整理一遍的，然後按照情況去除掉一些條目，然後把以前術語表的一部分條目保留下來 （僅限整理後的數與表不包含的條目，即整理之前手動添加上的條目）
你如果感覺這個 w.org 的術語列表可以的話我開發一個自動同步工具，從 w.org 上抓取這個列表填充到翻譯平台的術語表中，後面也隨着 w.org 上的更新而增量更新
我在 WordPress.org 的支持文檔中翻到了這一篇官方建議的術語表列表：
https://wordpress.org/support/article/glossary/
按上面説的，術語表存在的意義在於讓不瞭解 WordPress 的人能正確的使用 WordPress 專有的術語 進行翻譯，而不是對通用詞彙提供翻譯指北以實現類似 《英漢詞典》 這種大而全的詞彙對照。
而上面的文檔中列出的也就是如前所述的 「WordPress 專有術語」 。
wp-info.org 上的術語表中存在很多類似 「administrator」 這種幾乎只對應唯一翻譯的詞彙，以及類似 「approval」 這種在不同地方存在不同譯文的詞彙，這樣的話我感覺整體範圍太寬泛了，變成了前面説的 《英漢詞典》 而有悖術語表的初衷。
如果是想通過術語表讓翻譯保持一致的話，我在想是不是也要提供一個翻譯一致性檢查工具，由這個工具來確保翻譯一致，而不是通過術語表。
我覺得術語表應該需要以這個為基礎重新整理一下 https://wp-info.org/p/glossaries.csv 這裏麪條目比較全
好的 謝謝~大哥
沒有太好的辦法，我上次也被刷的褲衩都要賣了。
又拍雲提供了訪問速率限制以及防 CC 功能，但是實際測試來看並不會起任何作用。
該問題目前唯一的解決方案就是如果你網站不需要面向老外的話可以在屏蔽掉海外 IP，又拍雲提供訪問地域限制功能，海外 IP 屏蔽後能預防絕大部分 CC 攻擊。
其次就是在被打的時候手工通過日誌分析攻擊者 IP，然後手工拉黑了，不過這個在面對攻擊者使用代理 IP 的情況時就很無力了。
高風險的業務不建議使用這種按量付費的 CDN，就算換阿里、騰訊也一樣給你刷到破產。最好是使用百度雲減速這種預付費的 CDN，不管你被刷多少反正一年就幾百塊，超量了最多回源而已。
只是普通的個人博客的話可以不用擔心這個。我自己的博客日 IP 大概 200，四年了也沒被打過一次。前面説被刷的是 Cravatar 的頭像服務。
這兩插件我都用過，第二個有第一個的功能，做過簡單測試，第二個的效果不是很好，有的地區打開網頁秒開，有的地區打開慢了幾秒，我現在用的 fastese cache+redis object cache
這個檢索了下官方的文檔：https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/
目前的代碼編寫已經符合文檔要求了，不能出現在常用區塊中可能是古騰堡對區塊變體的處理還有 BUG，因為我和老李頭都不是 JS 開發方面的專家，所以這個問題得擱置了。
類似 WP 大學這樣都聚合到一頁上提交：https://www.wpdaxue.com/sitemap.xml 。
他使用的是這個插件：https://litepress.cn/plugins/www-xml-sitemap-generator-org
百度不支持索引型 xml 地圖了
後來發現跟我使用的主題有問題，例如文章縮略圖在列表中不是居中對齊，TTBF 時間增加到 300 多 ms，已找到替代插件，在樓下 #21387