标签： Polylang
-
在完成 SlyTranslate 与智谱 GLM-5.2 的 WordPress 长文章整篇翻译定制后，英文正文虽然能够正常生成，但实际发布流程仍出现分类、标签、PublishPress Series、Series 部分编号和特色图片未正确迁移等问题。本文根据真实测试过程，记录如何将新英文译文由自动发布调整为草稿，利用 Polylang 将中文 Taxonomy 关系迁移到已建立的英文分类、标签和 Series，并让 PublishPress Series 在人工发布时自动生成顺序编号。同时还修复了 GLM 压缩保护 Token 前导零以及英文特色图片缺失的问题。最终，新英文草稿已经能够保留 Gutenberg 结构，并自动关联正确的分类、标签、Series 和特色图片。中文语言切换器及多域名 Object Cache 失效问题则留待后续单独处理。
-
本文记录了在 WordPress、Polylang 与 SlyTranslate 环境下，为 GLM 5.2 整篇翻译流程增加 Plaintext 智能判断的完整优化过程。通过结构占位、区块顺序校验、Code Block Pro 原样保护、最终正文精确写回及 SHA-256 校验，实现了自然语言 Plaintext 可翻译、URL 和代码保持不变，同时修复了 Gutenberg 编辑器中的无效区块提示。文章还记录了英文文章分类、系列与标签因多域名对象缓存未及时失效而未能在前台正确显示的问题。
-
本文记录在 WordPress、Polylang 与 SlyTranslate 环境中，使用智谱 GLM-5.2 对包含大量 Gutenberg 区块和 Code Block Pro 代码块的技术长文进行正文单次翻译的完整排查过程。最初后台返回 invalid_translation_runaway_output，但执行轨迹显示正文其实只调用模型一次，并已成功保存英文文章。真正原因是自定义翻译完成后，SlyTranslate 原始 REST 回调又继续执行。通过将接管入口从 rest_request_before_callbacks 调整为 rest_dispatch_request，最终避免重复翻译，同时验证了 54 个代码块逐字一致、Gutenberg 结构完整、正文无中文漏译，翻译质量也明显优于原生分块流程。
-
在 WordPress、Polylang、W3 Total Cache、Redis 与多域名架构下，后台通过 admin 子域名发布文章或清理缓存后，www 与 en 前台仍可能读取旧的页面缓存和对象缓存。本文通过对比源站、CDN、WP_Query 与 Redis 缓存结果，定位到 W3TC 按 Host 隔离对象缓存的问题，并利用缓存组版本机制，配合自定义 MU Plugin，实现语言首页、文章查询缓存及 WPCode 配置缓存的跨域同步失效，同时保留中英文站必要的缓存隔离。
-
本文记录了在 WordPress 中使用 SlyTranslate 接入智谱 GLM-5.2 翻译技术长文时，从连续 504 超时到最终成功生成英文文章的完整排障过程。经日志分析发现，主要问题分别是模型请求的 `max_tokens` 被限制为 256，导致大量译文以 `finish_reason=length` 被截断，以及 SlyTranslate 使用三倍字符长度判断失控生成，对中文翻译为英文产生误判。通过 MU Plugin 将 GLM-5.2 的最小输出上限调整为 1024、关闭思考模式，并将长文本增长阈值由 3 调整为 6 后，翻译任务在约 9 分钟内完成。最终生成的英文文章保留了全部 Gutenberg 区块顺序、图片、列表和 54 个 Code Block Pro 代码块，普通正文无中文残留，Polylang 关联及英文前台访问均正常。当前方案已经解决长文翻译的稳定性与结构完整性问题，但英文自然度和术语准确性仍有进一步优化空间。
-
本文记录 WordPress 英文站从 /en/ 路径迁移到 en.shuijingwanwq.com 后，围绕 Yoast SEO 站点地图进行的完整调整与验证过程。内容包括薄内容标签页设置 noindex 并从 XML Sitemap 排除、W3 Total Cache 与 Cloudflare 多层缓存清理、重复标签导致的 Sitemap 误判排查，以及 Google、Bing、360、百度和搜狗等搜索平台中的资源添加与站点地图更新。最终，中英文站均统一使用 Yoast 生成的 sitemap_index.xml，英文子域的 Sitemap、robots、canonical 和搜索引擎提交状态均得到验证。
-
本文记录 WordPress + Polylang 英文站从 /en/ 迁移至独立子域名后，对首页和分类归档页错误链接的完整排查与修复过程。问题涉及分类下拉列表仍使用中文主域名、站点标题和面包屑 Home 指向默认语言首页、导航与侧栏保留旧 /en/ 链接，以及 W3 Total Cache Object Cache 导致英文 Host 无法及时加载最新 WPCode 片段。最终通过前端事件补丁、区块模板链接调整、按 Host 刷新对象缓存及源站验证，恢复英文站分类、导航、面包屑和多域名链接的正确跳转。
-
本文记录了 WordPress 英文站日历链接被错误拼接为双重 URL 的完整排查过程。问题最初源于旧版 WPCode 代码仍按 `/en/` 目录模式处理链接，在英文站迁移到 `en.shuijingwanwq.com` 后，将完整子域名 URL 再次拼接到旧地址后方。代码升级为兼容 Polylang 多域名模式的版本后，英文 Host 仍因 W3 Total Cache Object Cache 中的旧状态继续执行旧代码。最终通过按 `en.shuijingwanwq.com` Host 加载 WordPress 并调用 W3TC 对象缓存清理接口，使新版代码立即生效，日历链接恢复正常，并将清理流程整理为可重复使用的服务器脚本。
-
本文记录了一次 WordPress 英文文章页面横向滚动条的完整排查过程。在 Polylang 多域名、Twenty Twenty-Five 区块主题、W3 Total Cache Page Cache 与 W3TC Object Cache（Redis 后端）的组合下，页头搜索框的 `min-width: 250px` 导致英文语言切换器被挤出父级 Flex 容器。将其修改为 `min-width: 0` 后，英文页面却仍然输出旧 CSS。进一步对比 Cloudflare、源站响应、数据库原始内容与 `get_post()` 返回值后确认：数据库中的 `wp_global_styles` 已经更新，但 W3TC Object Cache 仍在返回旧的文章对象。最终通过 `clean_post_cache()` 精确清理对应对象缓存后，新 CSS 正常生效，横向滚动条消失。本文同时结合此前 Polylang 英文子域名迁移经历，总结了 W3TC Page Cache 多域名识别、旧 Polylang option 和旧全局样式对象缓存等问题的排查思路。
-
本文记录了将 WordPress 英文站从 `www` 主域名下的 `/en/` 路径迁移到 `en.shuijingwanwq.com` 子域名的完整实践。由于站点原有数千条标签 slug 转换、旧标签合并和专题重定向规则，不能简单使用一条通用 rewrite。最终通过“历史路径映射、最终域名转换、普通 `/en/` 兜底迁移”三层逻辑，实现旧英文标签和专题一次 301 到达最终英文地址，同时保留中文主域名规则与查询参数，并将 `www` 和 `en` 子域名后续产生的 301 规则分开维护。