When troubleshooting compatibility issues among SlyTranslate, Zhipu GLM-5.2, Polylang, PublishPress Series, and W3 Total Cache, I initially relied on a fairly traditional collaboration workflow:
- ChatGPT provided a set of commands;
- I copied them to the server and ran them;
- I copied the output back into the browser;
- ChatGPT analyzed the results and provided the next set of commands;
- Then I repeated the process.
For a small, well-defined issue, this approach works reasonably well.
However, efficiency dropped noticeably as the investigation expanded to cover:
- WordPress plugin source code;
- Custom MU Plugins;
- Gutenberg protection tokens;
- Polylang category, tag, and post relationships;
- The PublishPress Series lifecycle;
- W3TC Object Cache;
- Host-isolated object caches stored in Redis;
- W3TC Page Cache;
- Cloudflare and EdgeOne;
- A local Git project;
- Production deployment and rollback.
As the conversation grew longer, the browser began reporting that the page was unresponsive more frequently. Copying dozens or even hundreds of lines of Shell commands, PHP, and diagnostic output each time was inefficient and made it easier to lose sight of the actual objective.
During this investigation, I began assigning work that was better suited to automated execution to Codex. Over time, this evolved into a collaboration model that is better suited to a production WordPress environment.
The focus of this article is not how to use a particular model. It is:
How to let Codex handle source-code inspection, diffing, testing, deployment, and verification while keeping human control over production risk, the scope of changes, and the final technical direction.
1. Why Conversational Troubleshooting Became Inefficient
The initial goal was to resolve data synchronization issues that appeared when SlyTranslate used GLM-5.2 to translate long WordPress posts.
The issues included:
- English categories were not linked correctly;
- English tags were missing;
- PublishPress Series was not linked;
- Series part numbers were incorrect;
- The featured image was not migrated;
- GLM altered Gutenberg protection tokens;
- The English front end read stale object-cache data;
- The language switcher did not appear promptly on the Chinese post.
If only one value needs to be checked, the command may be quite short.
For example:
get_post_meta(19519, "_series_part_38462", true)
But diagnosing the actual problem often requires comparing all of the following at the same time:
数据库原始值
admin Host 下的 WordPress 运行时值
www Host 下的运行时值
en Host 下的运行时值
W3TC Page Cache 中的 HTML
Cloudflare 或 EdgeOne 返回的公网 HTML
Copying a single command is not difficult. The problem is repeatedly going through the following cycle:
提出假设
↓
生成命令
↓
人工复制
↓
执行
↓
复制输出
↓
重新解释
↓
生成下一组命令
After an investigation continues for several hours, the browser session itself also becomes a burden.
2. Which Tasks Are Better Suited to Codex
During this work, I found the following tasks particularly well suited to Codex:
- Reading a local Git project;
- Reading production files over SSH;
- Comparing a local candidate file with the production file;
- Searching for specific hooks, functions, and cache groups;
- Running PHP syntax checks;
- Running targeted tests;
- Producing a minimal diff;
- Calculating SHA256 hashes;
- Generating precise deployment commands;
- Creating a backup before deployment;
- Atomically replacing the production file;
- Verifying the version and file hash after deployment;
- Clearing cache data only for a specific post ID;
- Deleting rejected candidate files that were never deployed.
Decisions that should not be left entirely to Codex include:
- Whether the translation plugin or the cache plugin should be modified;
- Whether a particular architectural direction should be accepted;
- Whether database changes are allowed;
- Whether a site-wide cache purge is acceptable;
- Whether one test result is sufficient evidence for a long-term solution;
- Whether the investigation should continue or the issue should be deferred;
- Whether a new MU Plugin should be deployed.
In other words, Codex is well suited to execution and verification, but the production architecture still requires human control.
3. Give Codex Clear Boundaries
If the only instruction given to Codex is:
帮我修复这个 WordPress Bug
It may propose a solution with a much broader scope, such as:
- Adding another MU Plugin;
- Modifying several existing files;
- Clearing all of Redis;
- Running W3TC Purge All;
- Changing both Page Cache and the CDN at the same time;
- Modifying post relationships in the database.
On a production site, such a vague task carries substantial risk.
The instruction structure I gradually adopted usually included the following sections:
目标
已确认事实
允许读取的文件
允许修改的文件
禁止修改的内容
测试要求
部署要求
回滚要求
最终报告格式
For example, when fixing featured-image migration, I limited the task to:
只修复英文译文未迁移特色图片的问题。
允许：
- 修改自定义 GLM 翻译 MU Plugin；
- 使用 set_post_thumbnail()；
- 为现有测试文章补上特色图片。
禁止：
- 修改正文；
- 修改文章状态；
- 修改分类、标签和 Series；
- 修改 Polylang 关系；
- 清理缓存；
- 修改 SlyTranslate 插件源码。
These constraints make it easier for Codex to produce a small patch that can be tested, reviewed, and rolled back.
4. Start with Read-Only Analysis, Then Allow Writes
In production, I did not let Codex modify files at the beginning.
A safer workflow is:
第一阶段：只读分析
↓
第二阶段：查看 Diff 和测试结果
↓
第三阶段：人工批准
↓
第四阶段：部署
↓
第五阶段：验证
For example, GLM-5.2 returned the following error while translating a post:
{
"code": "swq_full_article_token_validation_failed",
"message": "Protected token validation failed: expected=628, actual=627, fixed_order=no. Diagnostic: /tmp/swq-glm52-token-validation-summary.json",
"data": null
}
Codex first performed read-only checks of:
- The diagnostic file;
- The original post content;
- The list of protection tokens;
- The tokens returned by GLM;
- The validation function;
- The token restoration function.
The root cause was:
预期：
SWQSTRUCT000018END
实际：
SWQSTRUCT00018END
In other words, GLM had removed one of the consecutive leading zeros.
At this stage, Codex had not modified any files or called the GLM API again.
5. Ask for a Minimal Diff Instead of Overwriting the File
After locating the problem, the next step was not immediate deployment. I first reviewed the smallest possible change.
The core approach used to fix the token issue was:
在严格校验前增加一次有限规范化。
仅当畸形 Token：
- 只能唯一对应一个缺失 Token；
- 类型相同；
- 数字值相同；
- 不存在重复或歧义；
- 修复后顺序仍正确；
才允许补回完整 Token。
之后继续执行原有严格校验。
The test results included:
PASS: zero contraction is repaired
PASS: correct token remains unchanged
PASS: ambiguous candidates fail
PASS: duplicate token fails
PASS: wrong fixed order fails
This was much safer than simply loosening the regular expression or skipping validation.
Codex also provided:
- The file version change;
- A minimal diff;
- PHP syntax-check results;
- Unit-test results;
- The candidate file’s SHA256 hash;
- Exact deployment commands;
- Rollback instructions.
6. Use SHA256 to Prevent Deploying the Wrong File
Both the candidate file and the production file were verified with SHA256 during this deployment.
For example:
候选 SHA256：
405eb681ae8e71c2a0e3148361ea2ec53f61dbaacf84f5b287876aa98da8a22c
Before deployment, the process verifies all of the following:
- Whether the current production file is still the expected old version;
- Whether the temporary file uploaded to the server matches the local candidate;
- Whether the PHP syntax check passes;
- Whether permissions and ownership match the original file.
A typical process is:
本地候选文件
↓
上传到临时路径
↓
验证候选 SHA256
↓
PHP 语法检查
↓
备份生产文件
↓
继承原文件权限
↓
原子替换
↓
再次验证生产 SHA256
This helps prevent problems such as:
- The local file being modified accidentally after review;
- An incomplete upload;
- Overwriting the wrong file;
- The production file being changed by another operation before deployment;
- Incorrect permissions preventing WordPress from loading the MU Plugin.
7. Use a Temporary Path and Atomic Replacement for Production Files
I did not overwrite the file directly at its final production path.
Instead, I first uploaded it to:
wp-content/mu-plugins/.swq-glm52-translation-tuning-2026.07.17.15.deploy.tmp
After validation, I used mv to replace the production file:
mv -f "$STAGE" "$MU"
On the same filesystem, mv reduces the risk of a WordPress request reading a partially written PHP file.
Before the final replacement, the original file was also backed up, for example:
/root/swq-glm52-translation-tuning-20260717-xxxxxx.php
If a problem appeared after deployment, the backup could be restored quickly.
This is easier to control than editing the production file line by line in an editor.
8. Codex Can Also Perform Precise Repairs on Existing Data
After fixing the featured-image migration bug, I still needed to add the featured image to an English post that had already been generated.
The read-only inspection showed:
中文文章：19429
特色图片 attachment：19437
英文文章：19522
特色图片：空
After deploying the new version, Codex called only the newly added featured-image synchronization method for this specific post pair.
It also recorded the following values before and after the repair:
- Post status;
- Content hash;
- Categories;
- Tags;
- Series;
- Polylang relationships.
The validation logic was:
目标特色图片应变为 19437
其他数据必须完全不变
The actual checks included:
source_thumbnail=19437
target_thumbnail=19437
unrelated_data_unchanged=yes
This approach is more reliable than merely checking whether the image appears in the WordPress admin. It also proves that adding the image did not unintentionally change any other post data.
9. Not Every Solution Proposed by Codex Should Be Deployed
During this investigation, Codex generated a new candidate MU Plugin for the cross-host Object Cache issue:
swq-cross-host-publish-cache-invalidation.php
The candidate solution would clear the target host’s object cache after publication by sending a loopback request protected with HMAC.
From an implementation perspective, the solution included:
- A host allowlist;
- A timestamp;
- HMAC-SHA256;
- A nonce;
- Replay protection;
- A publication hook;
- Deferred execution during shutdown.
However, before deployment, I reconsidered the existing environment.
The site already had an MU Plugin for W3TC and Polylang multi-domain caching. Adding another cross-host plugin could have caused:
- Duplicate functionality;
- The same hooks firing more than once;
- Overlapping cache-purge scopes;
- Difficulty determining which plugin was actually effective;
- A more complicated rollback path when something failed.
For that reason, I ultimately did not deploy the new plugin.
Codex then deleted the two undeployed candidate files from the local project:
patch/swq-cross-host-publish-cache-invalidation.php
patch/cross-host-publish-cache-tests.php
No corresponding production changes were made.
This process demonstrates that:
Codex can quickly generate an implementation that is technically viable, but a human still needs to decide whether it fits the existing architecture.
10. Prevent the Task from Drifting When Using Codex
The objective also drifted at several points during this investigation.
For example, the original goal was to complete the following as soon as possible:
- Categories;
- Tags;
- Series;
- Featured image;
- Complete validation of a newly translated post.
While working on the language switcher for one Chinese post, however, the task was temporarily split into:
- Fixing only the Chinese language switcher;
- Handling the English Series separately;
- Checking breadcrumbs afterward;
- Then considering the Yoast primary category.
All of these were real issues, but they were not the highest-priority objective at that point.
When the browser was already struggling and the conversation had become very long, creating another lengthy instruction for every local symptom reduced overall efficiency.
I later restated the objective:
First make sure a new English post can be generated completely and published correctly. Handle the Chinese language switcher and cross-host caching as separate follow-up tasks.
This experience showed that Codex needs boundaries not only for files and commands, but also for the business objective.
11. One Approval for a Complete Operation Is More Efficient Than Repeated Confirmation
Before performing write operations on the server, Codex displays the complete command and waits for approval.
There may not be a separate graphical button. A direct reply in the conversation such as:
批准执行。
is enough to continue.
To avoid repeated confirmation, I usually request:
写操作前只展示一次完整命令并等待批准。
批准后一次完成备份、部署、验证和必要的数据修复。
不要每一个小步骤再次等待。
This preserves human approval before production writes while avoiding a separate confirmation for every cp, mv, and php -l command.
12. Dividing Responsibilities Between Codex and a Standard ChatGPT Conversation
After this experience, I gradually settled on the following division of responsibilities.
ChatGPT Is Better Suited To
- Organizing the symptoms;
- Setting priorities;
- Distinguishing translation bugs, cache bugs, and plugin lifecycle issues;
- Deciding whether further changes are appropriate;
- Designing validation criteria;
- Writing the blog post and summarizing each stage;
- Stopping solutions whose scope has grown too large.
Codex Is Better Suited To
- Reading code;
- Searching for hooks;
- Comparing files;
- Running tests;
- Producing diffs;
- Managing the local Git project;
- Verifying production over SSH;
- Generating and executing deployment commands;
- Checking SHA256 hashes;
- Performing precise repairs;
- Deleting rejected candidate files.
These tools do not replace one another; they are better suited to different stages of the work.
13. A Codex Workflow for Production WordPress Sites
Based on this real-world process, the workflow can be summarized as follows.
1. Define One Specific Problem
For example:
英文译文没有特色图片
Instead of:
英文文章不正常
2. Provide Confirmed Facts
For example:
中文文章 ID：19429
英文文章 ID：19522
中文特色图片 ID：19437
英文特色图片：空
3. Limit Which Files May Be Modified
For example:
只允许修改：
swq-glm52-translation-tuning.php
4. State What Must Not Be Changed
For example:
禁止修改数据库
禁止清理 Redis
禁止修改 SlyTranslate 源码
禁止修改分类、标签和 Series
5. Begin with Read-Only Analysis
Ask Codex to report:
- The root cause;
- The exact location to change;
- A minimal diff;
- A test plan.
6. Run Tests
At minimum, include:
- PHP syntax;
- The expected scenario;
- Failure scenarios;
- Data that must not be overwritten;
- Regression tests.
7. Validate the Candidate File
Record:
- The version number;
- The SHA256 hash;
- The Git status.
8. Back Up Before Deployment
Create the backup at a clearly defined path and record the actual filename.
9. Use Atomic Replacement
Upload to a temporary path first, then replace the production file.
10. Validate Immediately After Deployment
Confirm:
- The file version;
- The SHA256 hash;
- Whether WordPress loads normally;
- The target post data;
- Whether unrelated data remained unchanged.
11. Prepare the Rollback
The rollback command should be defined before deployment, not written hurriedly after something fails.
14. What Became More Efficient
The most noticeable change after adopting Codex was not that there were fewer commands. It was that far less manual copying was required.
Previously, I had to perform the following tasks manually:
复制命令
执行
复制输出
回到浏览器
继续生成命令
With Codex, the following can be completed within a single task:
读取代码
↓
远程读取生产环境
↓
定位问题
↓
生成补丁
↓
运行测试
↓
展示 Diff
↓
等待批准
↓
部署
↓
验证
↓
报告结果
The human role is mainly to:
- Define the objective;
- Review the proposed solution;
- Approve write operations;
- Decide whether the final result meets the business requirements.
For WordPress issues involving multiple files, multiple hosts, and production deployment, this approach is a better fit.
15. Risks to Keep in Mind
Codex cannot automatically guarantee that every proposed solution is correct.
The following risks appeared during this work:
- The scope of the solution expanded;
- A duplicate cache plugin was proposed;
- A cache problem was incorrectly placed inside the translation plugin;
- Only the current post was repaired, without covering the future workflow;
- Too much attention was given to a local page issue, drifting away from the main objective of categories, tags, and Series;
- Automated tests passed, but the design could still duplicate an existing plugin.
For that reason, the following rules still apply when using Codex:
一次只解决一个明确问题
先读后写
最小修改
生产部署前备份
部署后立即验证
始终保留回滚路径
16. What Was Completed in This Round
By combining ChatGPT and Codex, this round of work completed the following:
- Changed newly generated English translations from automatic publication to drafts;
- Fixed category-relationship migration;
- Fixed tag-relationship migration;
- Fixed PublishPress Series relationship migration;
- Restored automatic Series numbering when a draft is published;
- Fixed GLM’s compression of leading zeros in protection tokens;
- Added strict, narrowly scoped token normalization;
- Fixed featured-image migration;
- Added featured images to existing English posts;
- Precisely repaired Object Cache and Page Cache for one English post;
- Rejected and removed the undeployed cross-host cache plugin candidate;
- Kept existing production plugins and database data free from additional changes.
The long-term compatibility issues involving the Chinese post language switcher and multi-host Object Cache remain separate follow-up tasks. I did not continue expanding the modification scope merely to claim that everything had been solved.
17. Interim Conclusion
The greatest value of Codex is not replacing human technical judgment. It is executing already-defined technical work more completely.
In a production WordPress environment, it is particularly useful for:
- Code analysis;
- Small, targeted patches;
- Testing;
- File verification;
- Deployment;
- Rollback;
- Precise validation.
The following decisions still require a human:
- Which problem is currently the most important;
- Which plugin should own the change;
- Whether functionality is being duplicated;
- Whether the change is worth deploying;
- Whether an issue should be deferred;
- Whether the solution is ready for production.
After this experience, I now prefer the following collaboration model:
ChatGPT 帮助判断方向和整理证据
↓
Codex 完成代码、测试和部署
↓
人工审查修改范围并批准
↓
生产环境立即验证
For long-running WordPress investigations that span multiple cache layers and plugins, this approach is more efficient than repeatedly copying commands between the browser and terminal. It also makes it easier to preserve a complete audit and rollback record.
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复