这里是 LitePress 社区旧贴存档，您可以在此留言或提交新的回应和信息。
LitePress 社区旧贴存档 2020~2023 年度
文章投稿 139 篇
参与 1035 次讨论和 239 条回复
发表评论
2,005 条回复
-
混个脸熟 ，不卡就行。
来自重庆 -
恭喜你踩坑里了，这个没办法一键删掉的。
不过其实大可不必理会，数据库没想象中那么脆弱，单纯几千垃圾信息不会对查询性能造成什么影响的。
来自秦皇岛 -
可是有多少人会用呢，要知道那个是按次收费的。
来自南宁 -
百度云加速支持完整的 Node.js，理论上也可以实现吧
来自秦皇岛 -
国内目前只有云盾和又拍云支持 cookie 判断缓存。
来自南宁 -
现在很多 CDN 都具有边缘规则功能，其原理就是在边缘节点上执行用户设定的脚本。
于是就可以利用这个功能来实现对符合某些条件的网页不缓存。
WordPress 的登录状态记录在网页 Cookie 里，其中有一个字段：wp-settings-用户 ID 。
我们只需要判断 wp-settings-1 存在 （管理员的 ID 是 1） 则不缓存网页即可。
举例子：
为了方便复制，改写规则贴在这：$_URI?is_admin=$_RANDOM&$_QUERY
更多的控制方法可以参考 CDN 的边缘规则文档，总体思路就是判断是否存在 wp-settings-1 这个 Cookik 字段，存在就为请求附加随机字符串，然后 CDN 设置一下对 URL 查询参数全程跟随，这样就会为管理员生成单独的缓存，而不会影响普通用户了。
来自秦皇岛 -
我记得当初开发机器翻译的时候排查过这个问题，好像也是因为代码编写不规范 （很多语句未支持 i18n），所以无法被提取原字符串，也无法翻译。
论坛编辑器的插入媒体功能会尽快添加上。
来自秦皇岛 -
对了，WP Fastest Cache 这个插件好像内置简体中文，但是未完全翻译。
这个编辑器的可视化可以加个插入图片的按钮吗？来自南充 -
见上面的回复。
概述一下就是这个插件编写的不规范，问题无解的，只能联系开发者解决。
来自秦皇岛 -
WordPress 的时区没有问题，发表的文章也是北京时间。
楼上图的出处是插件 WP Fastest Cache 里面的。
来自南充 -
那是格林尼治标准时间。
先确认下你的 WordPress 系统的时区是否正确。如果是正确的，那么这个问题无解。
WordPress 提供了内置的时间获取函数：current_time()，其中会自动按系统时区设置为时间戳做偏移。但很多插件会直接使用 PHP 的 time() 函数获取时间戳，于是其便无法随系统时区变化。
这个问题想解决只能自己改代码或者联系开发者解决。
来自秦皇岛 -
来自南充 -
可以配合插件 code snippets
来自成都 -
这个插件可以用，谢谢推荐
来自南充 -
我在三个不同的网站上测试，没办法复现出这个问题。联系楼主希望远程调试被拒绝。
可以看一下同类插件：https://litepress.cn/store/plugins/wenprise-pinyin-slug
-
修改保存导航栏菜单出现了这个错误，然后我只能把插件卸载掉，还有别的插件吗？
来自南充 -
启用插件后，我看插件说明是” 自动转换文章/页面/附件/自定义文章类型的别名”，然后我发表文章测试了下，文章和标签的别名没有任何变化。
来自南充 -
这会打不开 github，晚点再看看
来自南充 -
看一下这个文派拼音生成器：https://github.com/WenPai-org/wppinyin-nihao，有 BUG 可以直接在这个帖子里反馈，会跟进修复的。
来自秦皇岛 -
what???
来自秦皇岛 -
我们的身上都有毛毛
来自漯河 -
谢谢孙老板解答
来自茂名 -
补充一句，没适配大数据量不代表说主题不好，这个更多的是用户需求和投入资源的权衡问题。有大数据量承载需求可以找专门针对性适配过的来用。
来自秦皇岛 -
刚仔细看了下那个 SQL 。问题应该是这款主题没适配大数据量，你文章标签有三万多个。主题在尝试一次性把标签全取出来。等于说你每次加载页面会从数据库取三万多条数据。这个只能联系主题作者解决，或是换个支持大数据量的主题。
来自秦皇岛 -
真是主题问题，但是其他站也是有用同个主题，都能正常秒开。就这个站这样。很懵逼
来自茂名 -
如果确定是主题的问题要联系主题作者实际在你网站上调试才能找出问题出在哪。
代码运行环境不同产生的结果也不同，所以不一定所有网站都能复现出这个 BUG 。
来自秦皇岛 -
我把所有插件禁用也是这样，切换其他主题就正常了。
但是我其他站也有用 dux 这个主题也都秒开。很奇怪
来自茂名 -
Query Monitor 在正常情况下会在 「组件」 一栏显示出这个查询是哪个插件 or 主题发起的，但是从你截图里没看到有体现。
正常是这样的：
先尝试开启 WordPress 的 DEBUG 模式，看看能不能把组件列显示出来，不行的话就翻翻 Query Monitor 的官方文档。
等能看见这个查询是哪个插件发起的之后，就去联系插件作者吧。这种问题如果不是一目了然的话就要实际调试代码才能知道为啥会慢。
另外提一句：term_order 这个字段不是 WordPress 自带的，应该是某个插件私自添加的。这种会更改 WordPress 核心数据表的插件最好不要用，会破坏向后兼容性。
来自秦皇岛 -
是有个 慢查询
这种要怎么优化
来自茂名 -
WordPress 单纯负载几万篇文章很轻松的，页面加载 6 秒多一定是被某些插件影响了
来自秦皇岛 -
最简单的方法是装 Query Monitor 插件，这个插件可以监控 WordPress 页面加载过程中执行了什么操作。
你可以通过它看一下是不是存在慢 SQL，或是外部 HTTP 调用，通常这两个是主要影响速度的因素。来自秦皇岛 -
感谢反馈~该问题已修复——用户主页背景和用户头像大小限制在 2MB
来自秦皇岛 -
站名：小兴博客
文章地址：https://xn--9kra.xn--6qq986b3xl/241.html
得空看见 烦请添加一下
来自佛山 -
密切关注，占位见证。
来自银川 -
奥力给，干就完了
来自茂名
发表回复