分类： 博客系统
-
此前已经发现 W3 Total Cache 页面缓存长期很难看到超过 2 天的文件，但当时正在批量处理历史文章，不适合立即判断。等历史处理结束后，借这次 CPU 告警继续排查，最终发现联合预热 Sitemap 长期生成失败，根因是 Yoast SEO 生成 post-sitemap.xml 时触发 PHP 256M 内存耗尽并返回 HTTP 500。将 PHP-FPM memory_limit 提升到 512M 后，中英文 Sitemap 恢复 200，联合预热 Sitemap 也恢复自动更新。
-
2026 年 8 月 6 日，我曾在 PHP 8.5 环境中排查 WordPress 插件兼容性问题，并向 PublishPress Series 官方 GitHub 仓库提交 Issue #1163，报告 SplObjectStorage::attach() 与 contains() 在 PHP 8.5 下产生 Deprecated 警告。升级至 PublishPress Series Free 3.1.3 后，我重新检查了这个问题：Issue 已由上游关闭，生产环境源码中的旧调用也已经全部替换为 offsetSet() 与 offsetExists()，实际运行测试得到 DEPRECATIONS: 0，确认旧问题已经解决。不过，这次升级又带来了一个新的 Gutenberg 保存异常：新发布的中文文章虽然仍然属于正确的系列，却不再自动获得 Series Part 编号，而对应 English 文章仍然正常。全站扫描最终发现 6 篇受影响中文文章。恢复正确编号后，全站缺失 Series Part 的文章重新归零。为了避免修改插件源码或降级版本，我增加了一个最小 MU Plugin，在 Gutenberg REST 保存完成后调用 PublishPress Series 自己的排序函数自动补齐编号。本文随后作为修复后的第一篇真实中文文章发布，并成功自动成为「WordPress 性能优…
-
今天继续整理 WordPress 生产站的站点健康状态。最初后台显示 6 个“推荐的改进”，包括未启用的插件、未启用的主题、陈旧的 SQL 服务器、公开可访问的调试日志、评论分页，以及固定链接中没有文章名。排查过程中删除了 5 个不再使用的旧主题和 12 个已经没有实际用途的插件，升级 Akismet，关闭 WordPress 调试日志，并结合当前页面缓存与 CDN 架构，最终决定关闭文章评论及 Pingback/Trackback，同时保留历史评论数据。处理完成后，站点健康推荐项由 6 个减少到 3 个；剩余项目则分别因为 Cloudflare 插件暂时保留、阿里云 RDS MySQL 5.7 暂时无法升级，以及现有固定链接结构不适合为消除提示而贸然修改，因此选择保持现状。
-
在 WordPress Twenty Twenty-Five 主题中，分类下拉列表原本会先访问 ?category_name=slug，再由 WordPress 跳转到最终分类固定链接。随着网站后续实施 Query String CDN 缓存归一化，这一中转机制产生了兼容问题。本文记录如何通过 WPCode、render_block_core/categories、WP_HTML_Tag_Processor 与 get_term_link()，为分类选项写入真实固定链接，并由 JavaScript 直接跳转；同时利用 WPCode 的 Frontend Conditional Logic，将执行范围限制在首页与归档页。等待缓存自然过期后，中文首页、中文归档页、英文首页及英文归档页四种场景全部验证通过，无需修改 EdgeOne 或 Cloudflare 的现有 Query String 规则。
-
本文记录 WordPress 双语博客文章列表摘要显示优化的完整实践。针对 Gutenberg Post Excerpt 默认长度导致中文摘要过短、100 字仍会截断的问题，通过 WPCode 在首页、归档页和搜索结果页中将 excerptLength 提高至 500，并保留主题 100 作为后备值。经过一段时间真实运行与启停对照，最终确认中文首页、中文分类页及英文搜索页均可基本完整显示已有摘要，同时也复盘了多层缓存环境下容易误判代码是否生效的问题。
-
一次 WordPress 生产站点根目录清理实战。从 SSH 终端误粘贴产生的 0 字节命令碎片入手，逐步排查 WordPress 核心空文件、历史临时文件、旧主题与插件、PHP 维护脚本、Nginx/W3 Total Cache 配置、搜索引擎验证文件以及多年遗留的安装包。通过源码校验、旧博客溯源、当前配置核对和隔离机制，最终清理无用文件，同时避免误删仍在使用的标签处理脚本、AdSense、IndexNow 和搜索引擎验证文件，并总结生产环境下“先确认用途、优先隔离、最后删除”的安全清理思路。
-
在解决 WordPress 首页性能问题后，对当前服务器进行了完整配置审计，重点检查 Nginx、PHP-FPM、OPcache、Redis、W3 Total Cache、阿里云 RDS/MySQL 以及 WordPress 应用层。最终将 PHP-FPM 最大工作进程从 10 提高到 14，调整 OPcache 内存与 Interned Strings 配置，关闭 Gutenberg 实时协作，并为 SlyTranslate 调试日志增加日志轮转；同时保留大量已经运行健康的参数不变，形成一套更适合当前网站长期运行的服务器配置基线。
-
本文记录一次 WordPress 动态首页性能问题的完整排查与优化过程。绕过 EdgeOne、Cloudflare 和 W3 Total Cache 后，发现中文首页真实动态生成时间接近 19 秒。通过 PHP-FPM slowlog、MySQL EXPLAIN 与实际 SQL 基准测试，最终定位到 Post Views Counter 的热门文章排行榜查询：完整 wp_posts.* 参与 SUM、GROUP BY 和 ORDER BY，导致 MySQL 5.7 创建磁盘临时表。通过 MU Plugin 将查询改造成“轻量排名 + Top N 完整文章加载”的两阶段结构后，中文动态首页降至约 0.83～0.89 秒，英文首页稳定在约 0.87～0.96 秒，同时保持排行榜顺序、浏览量和 Polylang 语言过滤正确。