月度归档： 2026 年 8 月
-
英文站从 www.shuijingwanwq.com/en/ 迁移至独立子域 en.shuijingwanwq.com 后，Google Search Console 出现大量“已抓取 – 尚未编入索引”页面。本文通过检查 Sitemap、301 重定向、canonical、实时网址测试及历史搜索表现，逐步排除常见技术 SEO 故障，并随机抽查 3 篇已由 GLM-5.2 重翻译且被 Google 再次抓取的文章，发现它们仍未进入索引。现有证据更支持英文站正处于迁移后的重新抓取、索引接管与质量重新评估阶段，后续将继续推进历史英文文章重翻译，并持续观察索引数量与搜索流量变化。
-
在 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 作为后备值。经过一段时间真实运行与启停对照，最终确认中文首页、中文分类页及英文搜索页均可基本完整显示已有摘要，同时也复盘了多层缓存环境下容易误判代码是否生效的问题。
-
在此前排查 ThinkPad T570 的 Type-C 转 VGA 无法识别副屏问题后，我最终放弃继续修复 USB-C / Thunderbolt 视频输出链路，重新购买了一台原生支持 HDMI 的显示器作为副屏。现在采用 ThinkPad T570 HDMI → HDMI 线 → 显示器 HDMI2 的直接连接方式，Ubuntu 双屏已经恢复正常。新的结果也进一步说明，之前的问题并不是 Ubuntu 本身无法正常使用双屏，而更可能集中在原来的 USB-C / Thunderbolt / DisplayPort Alt Mode 链路。相比继续研究 Thunderbolt 固件和底层硬件，使用 HDMI 直连最终以更简单、稳定的方式解决了实际需求。
-
在一次 GLM-5.2 WordPress 整篇翻译完成后，服务器 Trace 明确记录了 3 次 API 请求，但智谱开放平台的费用明细却显示了 4 条模型推理记录。通过导出费用明细 Excel，并结合请求时间、输入与输出 Tokens、请求次数以及资源包余额进行交叉核对，最终确认费用明细的一行并不等于一次 API 请求：同一时间范围内的请求会汇总统计，而输入 Tokens 与输出 Tokens 又分别形成计费记录。本次 3 次请求共消耗 10,880 Tokens，与新用户赠送的 200 万通用模型推理资源包余额变化完全一致，同时也验证了资源包抵扣与“后付费”字段的实际含义。
-
在 WordPress 历史文章英文覆盖翻译过程中，文章 ID 4652 持续触发 GLM-5.2 HTTP 400 安全检测错误。通过执行 Trace、模型真实 Payload 与 Plaintext Region 分析，最终发现多个不含中文的服务器日志、文件列表等 Plaintext 区块没有翻译必要，却仍被完整发送给模型。本文记录如何调整 Code Block Pro Plaintext 保护策略，将纯机器文本改为 SWQBLOCK 整体保护，使正文 Payload 从 49938 字符降至 8876 字符，并继续处理 Ctrl+C 遗留状态、recovery_generation 重试计数、counter_drift 与 WordPress REST Nonce 过期问题，最终成功完成 GLM-5.2 整篇翻译。
-
一次 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 语言过滤正确。