参与者列表

感谢 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