參與者列表 Search 感謝 2020 ~ 2023.4 所有關注過 LitePress 的用户 此版已存檔,詳情參見 《推廣名單》 《“ 參與者列表” 》 有 2,005 條評論 文派葉子 🍃 2021.08.07 任何人都可以進行 DNS 污染。 參見:https://www.cloudflare.com/zh-cn/learning/dns/dns-cache-poisoning/ 文派葉子 🍃 2021.08.07 WordPress 的頭像獲取函數默認是傳遞用户 id 或郵箱地址的,所以也建議傳遞用户 id 或郵箱,而不是將評論對象整個傳過去。 這個報錯的意思是評論對象無法被 WordPress 的緩存相關幫助函數用作鍵值。如果確定必須傳遞評論對象的話可以把自定義的獲取頭像的函數中帶 wp_cache 相關的行都刪掉。 文派葉子 🍃 2021.08.07 完全沒看懂問題描述欸。 你説的的特色視頻是主題帶的功能還是 WordPress 內置的?可否附加一張截圖我看一下在什麼位置。 另外編輯器有插入圖片功能,通過附件上傳不太方便看。 文派葉子 🍃 2021.08.07 這玩意就和人和人的體質不能一概而論一樣,貼吧五虎將能滑鏟老虎、抱殺狗熊、一拳打穿一米鋼板、徒步躲子彈,普通人行嗎? 同樣如果別人裝了一堆插件,可能文章剛 10 萬的時候 postmeta 表數據就上千萬了,但是你裝的插件少可能文章 10 萬 postmeta 表才 50 萬,這東西無論如何都不能一概而論的。 myelse 2021.08.06 wordpress 多少篇文章能達到百萬行數據庫的量? 文派葉子 🍃 2021.08.06 wordpress.com 利用這個插件來使用幾千個數據庫的數百萬數據表存儲其全球業務產生的海量數據。可以理解成無限擴容。 文派葉子 🍃 2021.08.06 分庫分表使用插件——HyperDB,這也是目前 wordpress.com 在用的方案。 這個插件的使用非常複雜,這裏有一篇最簡單架構的設置方案:https://www.interserver.net/tips/kb/high-availability-wordpress-hyperdb/ 數據達到多少才需要分表這個沒有統一規範,要根據你的業務來定。 cgq630105023 2021.08.06 分庫分表插件有啥?? 達到多少文章適合分庫分表? 不凡 2021.08.06 好的,謝謝告知! 文派葉子 🍃 2021.08.06 我之前很多客户用模板兔寫的 erphpdown 插件,這個主要是把你的文章變成只有付費才可讀或是提供付費下載功能。 如果你是打算賣通常的商品的話除了 WooCommerce 外不建議用別的,你可以把系統轉換成站羣平台,然後商城在單獨的子站裏做,這樣就可以給商城用一套專門的主題,然後會員數據也是互通的。 另外 wpcom 的主題我記得是適配了 WooCommerce 的 文派葉子 🍃 2021.08.06 china yes 插件當前是從 wp-china.org 上讀取的翻譯數據。這個老平台目前還在運行,但是今天上面的數據會被全部遷移到 litepress.cn 上,遷移範圍只包括人工翻譯的,機器翻譯的捨棄掉重新跑,因為新版的機器翻譯會匹配術語庫,一定程度上比老版的會更準確。 文派葉子 🍃 2021.08.06 已經好了 smile 2021.08.06 另外反饋一個問題,我發現 ElasticPress 插件是沒有翻譯的,但是我已經可以通過 WP-China-Yes 插件接收到它的翻譯更新了。 smile 2021.08.06 順便也給我添加一下權限,謝謝。 leafit 2021.08.06 不好意思,把後台緩存插件禁用就好了,已經解決了 文派葉子 🍃 2021.08.05 肯定是 QPS 越大資源佔用越大…… 通常可以通過多級緩存來降低單次請求的負載,比如説對某個頁面整體靜態緩存、對數據查詢進行緩存、對 PHP 腳本預編譯。再就是可以引入 NoSQL 來持久化存儲一些簡單的數據。 myelse 2021.08.05 就比如你們剛推出的頭像服務,分庫分表,查詢的時間降下來,但是 QPS 一多是不是還得有很大負載壓力。 myelse 2021.08.05 後者基本就是企業的大型業務了,而且這種業務可能也都是自己開發了。不分庫分表的情況下,是不是數據庫越大記錄越多,同樣的併發數,所需要的 CPU 算力越多?同樣的一篇文章,多次訪問 redis 和 pagecache 能解決,但是沒緩存的數據還是需要進行數據庫查詢。 文派葉子 🍃 2021.08.05 可以。 如果你只是普通的文章站的話是有現成的分庫分表插件的,這是數據庫層面的橫向擴容。 Web 服務器層面的橫向擴容要求你不能使用任何基於本地磁盤的持久化文件或會話存儲,這樣你就可以使用一個負載均衡器來輪詢一組 Web 服務器節點了。 通過這種方式理論上你可以無限擴容。 myelse 2021.08.05 橫向擴容是自己上手操作的是吧,mysql 能支撐上億文章的體量嗎? myelse 2021.08.05 不是擔心 wordpress 的承載量的問題,而是服務器算力成本的問題哈哈。 文派葉子 🍃 2021.08.05 不一定,數據量大了可以通過分庫分表來橫向擴容,這時候單節點無需很高的配置。 總之不用擔心,WordPress 可以承載任何數據量的數據,哪怕上億文章都毫無問題。 myelse 2021.08.05 就是,數據庫查詢問題,要是 wordpress 文章多起來,比如到十萬百萬篇文章的量級,是不是需要超高配置服務器支撐一定程度的併發? 文派葉子 🍃 2021.08.05 你説的數據庫大小是指的磁盤空間吧。 這個你這樣想,你的電腦能運行多高特效的遊戲是不是和你硬盤容量沒啥關係? 文派葉子 🍃 2021.08.05 WooCommerce 支持多站點模式,直接在網絡管理中啓用 WooCommerce 即可。 如果想為每個站點同步商品 SKU,但為每個商品填寫不同語言的介紹和庫存可以參考這篇帖子:https://litepress.cn/topic/21213 bighuaji 2021.08.05 有啊,之前翻譯過 telegram linn 2021.08.05 看了一下 F12 控制枱有一條報錯 但是找不到具體的原因 不過寫一個 JS 也可以解決這個問題 原理是一樣的 你把這個 JS 找個地方運行一下即可 還有手風琴的標題不要加入超鏈接 不然會跳轉的 var $ = jQuery.noConflict(); $(".elementor-tab-title").on("click",function(){ $(this).toggleClass("elementor-active"); $(this).next().toggle(); }) 文派葉子 🍃 2021.08.05 已經好了。不過你之前有翻譯的經驗嗎? 文派葉子 🍃 2021.08.05 已經審核了。 新版的翻譯平台因為還是開發中所以審核不是很及時,本週會結束這一塊的所有開發工作。 ndwsj 2021.08.05 https://a.dwcloud.xyz/ 麻煩您看下謝謝 ←較舊評論 1 … 28 29 30 31 32 … 67 較新評論→
《“ 參與者列表” 》 有 2,005 條評論
任何人都可以進行 DNS 污染。
參見:https://www.cloudflare.com/zh-cn/learning/dns/dns-cache-poisoning/
WordPress 的頭像獲取函數默認是傳遞用户 id 或郵箱地址的,所以也建議傳遞用户 id 或郵箱,而不是將評論對象整個傳過去。
這個報錯的意思是評論對象無法被 WordPress 的緩存相關幫助函數用作鍵值。如果確定必須傳遞評論對象的話可以把自定義的獲取頭像的函數中帶 wp_cache 相關的行都刪掉。
完全沒看懂問題描述欸。
你説的的特色視頻是主題帶的功能還是 WordPress 內置的?可否附加一張截圖我看一下在什麼位置。
另外編輯器有插入圖片功能,通過附件上傳不太方便看。
這玩意就和人和人的體質不能一概而論一樣,貼吧五虎將能滑鏟老虎、抱殺狗熊、一拳打穿一米鋼板、徒步躲子彈,普通人行嗎?
同樣如果別人裝了一堆插件,可能文章剛 10 萬的時候 postmeta 表數據就上千萬了,但是你裝的插件少可能文章 10 萬 postmeta 表才 50 萬,這東西無論如何都不能一概而論的。
wordpress 多少篇文章能達到百萬行數據庫的量?
wordpress.com 利用這個插件來使用幾千個數據庫的數百萬數據表存儲其全球業務產生的海量數據。可以理解成無限擴容。
分庫分表使用插件——HyperDB,這也是目前 wordpress.com 在用的方案。
這個插件的使用非常複雜,這裏有一篇最簡單架構的設置方案:https://www.interserver.net/tips/kb/high-availability-wordpress-hyperdb/
數據達到多少才需要分表這個沒有統一規範,要根據你的業務來定。
分庫分表插件有啥?? 達到多少文章適合分庫分表?
好的,謝謝告知!
我之前很多客户用模板兔寫的 erphpdown 插件,這個主要是把你的文章變成只有付費才可讀或是提供付費下載功能。
如果你是打算賣通常的商品的話除了 WooCommerce 外不建議用別的,你可以把系統轉換成站羣平台,然後商城在單獨的子站裏做,這樣就可以給商城用一套專門的主題,然後會員數據也是互通的。
另外 wpcom 的主題我記得是適配了 WooCommerce 的
china yes 插件當前是從 wp-china.org 上讀取的翻譯數據。這個老平台目前還在運行,但是今天上面的數據會被全部遷移到 litepress.cn 上,遷移範圍只包括人工翻譯的,機器翻譯的捨棄掉重新跑,因為新版的機器翻譯會匹配術語庫,一定程度上比老版的會更準確。
已經好了
另外反饋一個問題,我發現 ElasticPress 插件是沒有翻譯的,但是我已經可以通過 WP-China-Yes 插件接收到它的翻譯更新了。
順便也給我添加一下權限,謝謝。
不好意思,把後台緩存插件禁用就好了,已經解決了
肯定是 QPS 越大資源佔用越大……
通常可以通過多級緩存來降低單次請求的負載,比如説對某個頁面整體靜態緩存、對數據查詢進行緩存、對 PHP 腳本預編譯。再就是可以引入 NoSQL 來持久化存儲一些簡單的數據。
就比如你們剛推出的頭像服務,分庫分表,查詢的時間降下來,但是 QPS 一多是不是還得有很大負載壓力。
後者基本就是企業的大型業務了,而且這種業務可能也都是自己開發了。不分庫分表的情況下,是不是數據庫越大記錄越多,同樣的併發數,所需要的 CPU 算力越多?同樣的一篇文章,多次訪問 redis 和 pagecache 能解決,但是沒緩存的數據還是需要進行數據庫查詢。
可以。
如果你只是普通的文章站的話是有現成的分庫分表插件的,這是數據庫層面的橫向擴容。
Web 服務器層面的橫向擴容要求你不能使用任何基於本地磁盤的持久化文件或會話存儲,這樣你就可以使用一個負載均衡器來輪詢一組 Web 服務器節點了。
通過這種方式理論上你可以無限擴容。
橫向擴容是自己上手操作的是吧,mysql 能支撐上億文章的體量嗎?
不是擔心 wordpress 的承載量的問題,而是服務器算力成本的問題哈哈。
不一定,數據量大了可以通過分庫分表來橫向擴容,這時候單節點無需很高的配置。
總之不用擔心,WordPress 可以承載任何數據量的數據,哪怕上億文章都毫無問題。
就是,數據庫查詢問題,要是 wordpress 文章多起來,比如到十萬百萬篇文章的量級,是不是需要超高配置服務器支撐一定程度的併發?
你説的數據庫大小是指的磁盤空間吧。
這個你這樣想,你的電腦能運行多高特效的遊戲是不是和你硬盤容量沒啥關係?
WooCommerce 支持多站點模式,直接在網絡管理中啓用 WooCommerce 即可。
如果想為每個站點同步商品 SKU,但為每個商品填寫不同語言的介紹和庫存可以參考這篇帖子:https://litepress.cn/topic/21213
有啊,之前翻譯過 telegram
看了一下 F12 控制枱有一條報錯 但是找不到具體的原因 不過寫一個 JS 也可以解決這個問題 原理是一樣的 你把這個 JS 找個地方運行一下即可
還有手風琴的標題不要加入超鏈接 不然會跳轉的
已經好了。不過你之前有翻譯的經驗嗎?
已經審核了。
新版的翻譯平台因為還是開發中所以審核不是很及時,本週會結束這一塊的所有開發工作。
https://a.dwcloud.xyz/
麻煩您看下謝謝