參與者列表

感謝 2020 ~ 2023.4 所有關注過 LitePress 的用户

此版已存檔,詳情參見 《推廣名單》

《“ 參與者列表” 》 有 2,005 條評論

  1. smile 的頭像
    smile

    這個源代碼是不是在建立項目的時候填寫了原文件 URL 就可以實現了?

  2. 文派葉子 🍃 的頭像
    文派葉子 🍃

    撿到寶藏了……後面就對着你這個列表挨個聯繫了

  3. muze 的頭像
    muze

    巧了,這些主題我都收錄的有,

    還有一些其他的可以來看看哦

    https://www.npc.ink/wp-theme

  4. 文派葉子 🍃 的頭像
    文派葉子 🍃

    這個報錯目測是模板兔的 Erphpdown 插件引發的,聯繫作者看看吧,僅憑藉這些數據庫提示判斷不出具體問題。

  5. jietaonet 的頭像
    jietaonet

    記得沒錯的話,這是 erphpdown 插件的數據庫。

    解決方案 1,卸載之,或安裝新版

    解決方案 2,按照報錯重新寫一份創建數據庫代碼。

  6. cgq630105023 的頭像
    cgq630105023

  7. tomda 的頭像
    tomda

    瞭解了

  8. 文派葉子 🍃 的頭像
    文派葉子 🍃

    結果後來還是貼了張純圖 >_> 。

    你這個問題大概率是給網站開 https 然後 url 沒換全導致的。去 wp 後台站點 url 設置那更新一下,或者在數據庫裏批量替換成 https

  9. tomda 的頭像
    tomda

     

    okk

  10. 文派葉子 🍃 的頭像
    文派葉子 🍃

    然後下次儘量文字描述,然後配圖。純圖的話搜索引擎不索引欸

  11. 文派葉子 🍃 的頭像
    文派葉子 🍃

    f12 看控制枱報錯

  12. 耗子 的頭像
    耗子

    很多主題報錯誒,考慮換個主題吧。

  13. 文派葉子 🍃 的頭像
    文派葉子 🍃

    最好肯定是都處理

  14. 文派葉子 🍃 的頭像
    文派葉子 🍃

    商業公司應該也必然以自身發展為主要任務,商業本身就是最大的公益了,他們贊助也是要獲得對等收益的,也或者是出於大局及戰略部署的原因,總之不會平白無辜的付出成本給某個人或某個羣體。

    如果是因為真實用户量大了他們是會願意贊助的,但如果是被 CC 攻擊把流量刷光了,我想應該就夠嗆了。

  15. myelse 的頭像
    myelse

    OKKKKKKKKKKKK

  16. 文派葉子 🍃 的頭像
    文派葉子 🍃

    別糾結了,擺在你面前的就三個選項:JB 、 VS Code 、 VS 。

    除非你是做科研,需要用一些特定的語言和編譯工具。

    你説的 eclipse 以及 myeclipse 這倆已經是上個時代的東西了。

    或者其實可以乾脆用記事本寫,然後手工運行編譯器和調試器,這樣就不用花時間選了。

  17. myelse 的頭像
    myelse

    eclipse myeclipse 咋樣

  18. yungking 的頭像
    yungking

    又拍雲應該全力支持。

  19. myelse 的頭像
    myelse

    vs 面向個人是不是隻有免費版?

  20. myelse 的頭像
    myelse

    很好,哈哈。

  21. 文派葉子 🍃 的頭像
    文派葉子 🍃

    目前主流就是 JB 和 VS Code 了,其他 IDE 的市場佔有率都快被擠沒了。

    如果你是寫 C 、 CPP 或者微軟家的 C#、.Net 則是用宇宙最強的 Visual Studio

  22. 耗子 的頭像
    耗子

    vscode 記事本

  23. myelse 的頭像
    myelse

    其他還有推薦嘛站長?

  24. 文派葉子 🍃 的頭像
    文派葉子 🍃

    最多 100,否則就得考慮優化了。

  25. cgq630105023 的頭像
    cgq630105023

    一般多少以下合適?

  26. 文派葉子 🍃 的頭像
    文派葉子 🍃

    建議使用 redis cache object 或者用水煮魚的 wpjam 。

    總之,你需要開緩存。

    單次請求 261 次查詢太誇張了,這個應該就是造成你 cpu 100% 的直接原因

  27. cgq630105023 的頭像
    cgq630105023

    頁面查詢次數、加載時間和內存佔用

    261 queries in 1.135 seconds, using 17.56MB memory

     

     

    多少合適呢? 這是本地測試的

  28. 文派葉子 🍃 的頭像
    文派葉子 🍃

    MySQL 最近一次記錄的慢查詢是下午兩點了,通過這個日誌看不出什麼。

    這有可能是實際發生了低效的慢查詢但是你的記錄閾值太高導致的。

    你是否能通過訪問某個特定 url 來觸發這個 cpu 100% 的情況?

    如果可以的話,安裝插件:query monitor

    通過這個插件來監控慢查詢 (需開啓 wp 的 debug 模式)

    如果你不知道如何觸發的話可以從 web 日誌裏找找靈感

  29. 文派葉子 🍃 的頭像
    文派葉子 🍃

    貼一下 mysql 的慢查詢日誌。

    懷疑是觸發了低效的查詢

  30. smallsaltedfish 的頭像
    smallsaltedfish

    JB 全家桶+1