這裏是 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站羣，，沒弄成就來恢復數據庫和網站文件。。然後就這樣了
如何解決呢
發表回覆