這裡是 LitePress 社群舊貼存檔，您可以在此留言或提交新的回應和資訊。
LitePress 社群舊貼存檔 2020~2023 年度
文章投稿 131 篇
參與 1035 次討論和 239 條回覆您可能也喜歡…
發表評論
2,005 條回覆
-
騰訊雲官方有專門的外掛，直接安裝之後根據裡面的設定要求進行設定即可
搜尋關鍵詞：tencentcloud
-
點選域名 第一個域名管理 直接新增
-
這。。。。。。。。
直接網站管理裡新增域名他不香。
解析過去直接綁，啥都不設定。
你們為啥想那麼複雜。
-
-
剛整理術語表的時候突然想起來，中文翻譯的時候是不是可以忽略掉單複數了。這樣術語表裡只記錄單數，然後程式匹配的時候單數和複數都去匹配這條術語？不知道這樣會不會產生一些翻譯錯誤。
-
現在這個階段講的話我覺得就是你說的這樣。
更深層次闡述一下，這個和我本人一直奉行的發展策略有關。
我覺得我唯一成功的方式是透過一個優勢點去撬動其他點，在不斷的資源整合中變得強大。這個策略適用於我在做的幾乎所有的事情。
往大的方面舉例子，就好像我從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
-
已找到合適的外掛，外掛名【plus webp】（https://litepress.cn/plugins/plus-webp），雖然功能不全，可以將就使用。
<h3>外掛設定截圖</h3>
與又拍云云儲存外掛做了相容測試，測試完美。
我只用又拍雲端儲存，沒有騰訊雲阿里雲等物件儲存服務，請自行測試。
<h3>又拍云云儲存外掛</h3>
以下兩個外掛都可以使用，任選其一。一、https://litepress.cn/plugins/wpupyun
二、https://litepress.cn/plugins/uss-upyun
-
是有必要的，前面也說了，站點地圖可以讓蜘蛛更快的發現你的新增內容。
你說的百度不相容站點地圖是什麼情況？遇到報錯了還是有什麼檔案提到了？
-
當初這麼設計主要是考慮到這個需求或許並不常見，因為頭像作為一個人的網路標識，想當然的每個人應該只有一個，但一個人難免有多個郵箱，所以就想為多個郵箱都繫結到這一個頭像上。
而需要多個頭像情況更多是註冊馬甲賬號，考慮到實現上的便捷性，也就需要對業務邏輯解耦，所以打算如果是馬甲的話使用者就新註冊一個號。
當然，以上結論也不排除是因為我的認知偏差所下的錯誤結論，所以如果這個功能後面呼聲高的話還是會搞，最終還是以使用者實際需求為準。
最後就是，Cravatar並不是我一個人做的，至少前端部分我是一點沒碰的，這一塊是老李頭在負責。所以把整個專案歸為“我的專案”實在是感覺不自在。
-
那麼WordPress自帶的xml站點地圖有沒有必要 貌似這種地圖還不支援百度
-
檢視MySQL配置檔案中是否包含了名為
innodb_force_recovery的引數，這個引數就是配置MySQL恢復級別的。另外開啟了Redis快取也可能造成配置不更新，建議檢視下資料庫中的資料是否已經被更新過而只是網站後臺不顯示？
-
現在的問題只剩，，儲存配置後重新整理，配置沒變，上面說的恢復模式是什麼意思
-
還有主題也要換成wp的預設主題
-
我沒有手動改過資料庫檔案。。
外掛的話我全部關閉了。。我等下再試試
-
從你的描述看，如果你確信你已經完全刪除了所有老網站的檔案和資料庫（也包括Nginx的偽靜態配置），那麼現在就已經和你折騰站群沒關係了。
我上面詢問的倆問題也沒回復我，問題得靠排查，不配合的話要如何定位，畢竟我也不是神仙。
-
剛才在折騰wordpress站群，，沒弄成就來恢復資料庫和網站檔案。。然後就這樣了
如何解決呢
發表回覆