【唐诗】《古從軍行》 李頎：白日登山望烽火，黃昏飲馬傍交河。行人刁斗風沙暗，公主琵琶幽怨多。野雲萬里無城郭，雨雪紛紛連大漠。胡鴈哀鳴夜夜飛，

永夜

没有不值得去解决的问题，也没有不值得去学习的技术！

Making the WordPress AI Translation Optimization Repository Public: From Sensitive Information Audit to Minimal-Change Release

Figure 3: GitHub has correctly identified the repository's MIT License.

作者：

永夜

在

Post Views: 4

Recently, I have been optimizing the English translation workflow for Chinese WordPress technical articles.

This workflow is no longer just a simple call to a large language model; it has gradually incorporated a lot of site-specific logic, such as:

  • Using SlyTranslate as the translation entry point;
  • Using Zhipu GLM to process entire articles;
  • Preserving the Gutenberg block structure;
  • Protecting code blocks, shortcodes, HTML, URLs, and file paths;
  • Validating placeholder integrity;
  • Synchronizing the relationship between Chinese and English articles in Polylang;
  • Fixing English featured image attachments and alt text;
  • Adding automated tests and production verification records.

Previously, I organized this code and troubleshooting records into a private GitHub repository:

Plaintext
wordpress-ai-translation-pipeline

As the translation workflow stabilized, I started considering whether to switch this repository to public, both as a milestone archive and to serve as a reference for others using WordPress, Polylang, and AI translation tools.

However, before actually executing the switch, I conducted a complete sensitive information audit.

1. Why I Didn’t Simply Switch the Repository to Public

Switching a GitHub repository from Private to Public itself only takes a single command.

The real consideration is that once the repository is public, not only the current files become accessible, but the Git commit history, tags, and previously deleted files can also be recovered.

Therefore, this audit covered:

  • The current working directory;
  • All tracked files;
  • Untracked and ignored files;
  • The entire Git commit history;
  • All tags;
  • Files deleted in the history;
  • Commit messages;
  • Third-party plugin source code;
  • GitHub repository metadata;
  • Common API Key, Token, Cookie, Nonce, password, and private key formats.

At the time of the audit, the repository had 524 tracked files, and the working directory was clean.

Figure 1: Codex report page after completing the sensitive information audit prior to making the repository public.
Figure 1: Codex report page after completing the sensitive information audit prior to making the repository public.

The audit ultimately found none of the following:

  • API Keys;
  • GitHub Tokens;
  • Model service keys for OpenAI, Zhipu, DeepSeek, etc.;
  • Alibaba Cloud, Cloudflare, EdgeOne authentication information;
  • SSH private keys;
  • Database usernames and passwords;
  • WordPress salts;
  • Cookies;
  • WP_ADMIN_COOKIE;
  • WP_REST_NONCE;
  • Authorization Headers;
  • OAuth client secrets;
  • Webhook secrets.

In other words, no authentication information that could directly grant system access was found in the repository.

2. The First Audit Conclusion Was Overly Conservative

Although no actual credentials were found, the first audit still reached a rather cautious conclusion:

The current repository is not suitable for direct public release; creating a new sanitized public repository is recommended.

The main reasons included:

  • Real production directories existed in the Git history;
  • SSH aliases like ssh aliyun existed;
  • Real domains, article IDs, and attachment IDs were saved;
  • Production deployment and troubleshooting commands were included;
  • The installed source code for SlyTranslate and PublishPress Series was saved;
  • There was no README, LICENSE, or third-party license notice.

From a strict enterprise security audit perspective, this assessment is correct.

However, considering my actual situation, I felt this standard was a bit too high.

For example:

Bash
ssh aliyun

This is just an alias defined in my local ~/.ssh/config.

The repository contains no corresponding server IP, password, or private key. Anyone running this command on their own computer cannot connect to my server.

Similarly, a server directory like this:

Plaintext
/data/wwwroot/www.shuijingwanwq.com

along with real domains, article IDs, and attachment IDs, is not authentication information in itself.

This information has already been widely published in my technical blog to illustrate the real troubleshooting process. Replacing all of it with example.com or fabricated IDs just to switch to a public repository would not only require a lot of work but also reduce the authenticity of the troubleshooting records.

Security cannot rely on hiding an SSH alias, a WordPress path, or an article ID.

What truly needs protection remains:

  • Keys;
  • Passwords;
  • Cookies;
  • Nonces;
  • Private keys;
  • Database dumps;
  • Authentication values that can directly grant system privileges.

This audit found none of these, so I decided against large-scale sanitization and against creating a second public repository.

3. Why I Didn’t Adopt the “Dual-Repository” Approach

I initially considered keeping the existing private repository and creating a new sanitized public repository.

The structure would look roughly like this:

Plaintext
Private repository
    ↓ One-way export
Public repository

This approach is clear from a security isolation perspective, but it also introduces new maintenance issues:

  • Which repository is the authoritative version;
  • Whether the public repository is synced promptly after changes in the private one;
  • How to back-merge Pull Requests received in the public repository;
  • Whether the export script misses files;
  • Whether the two repositories will gradually diverge;
  • Whether sanitization must be repeated for every release.

Even if designed as a one-way mirror, an export mechanism would still require long-term maintenance.

The current repository is not large, and no actual credentials were found. Introducing a second repository and sync scripts just to reduce theoretical risk goes against the principle I have always adhered to:

Do not introduce a large amount of extra code, complex processes, and long-term maintenance costs for a marginal improvement.

Therefore, I finally decided to continue using the existing repository and only make the most necessary additions before making it public.

4. The Final Minimal-Change Approach

The finalized approach was simple:

  1. Keep the existing repository and all Git history;
  2. Do not delete real domains, directories, or article IDs;
  3. Do not delete third-party source code snapshots;
  4. Do not execute git filter-repo;
  5. Do not rewrite commit history;
  6. Do not delete or rebuild tags;
  7. Do not force push;
  8. Add a README;
  9. Add an MIT License;
  10. Add a third-party license notice;
  11. Run another actual credential scan;
  12. Switch to Public directly after tests pass.

This time, only three files were added:

Plaintext
README.md
LICENSE
THIRD_PARTY_NOTICES.md

No PHP, JavaScript, Shell, test, or production configuration code was modified.

5. How the README Explains the Repository’s Positioning

The newly added README.md uses a structure primarily in Chinese, with a brief English summary.

The README explicitly states that this is not a universal plugin that can be installed and directly adapted to all WordPress websites, but rather a site-specific implementation derived from a real production environment.

The repository mainly documents:

  • The SlyTranslate invocation workflow;
  • GLM translation quality optimization;
  • Gutenberg block protection;
  • HTML and placeholder handling;
  • Code block, URL, and path protection;
  • Polylang article and media relationships;
  • English featured image and alt synchronization;
  • Automated tests;
  • Production verification and troubleshooting records.

The README also explains the main directories:

Plaintext
swq-glm52-translation-tuning.php

The MU plugin tuning implementation used by the current site.

Plaintext
sources/

Stores source code snapshots of some installed third-party plugins for differential analysis and reproduction.

Plaintext
patch/

Stores patches, tests, and verification tools.

Plaintext
archive/

Stores historical candidate versions or unpublished solutions.

Plaintext
evidence/

Stores real production troubleshooting and deployment evidence.

The README also explicitly warns:

  • Verify in a test environment before use;
  • Do not commit real API Keys;
  • Do not commit Cookies and Nonces;
  • Do not commit wp-config.php;
  • Do not commit database passwords or database dumps;
  • Real domains, directories, and article IDs in the repository are not equivalent to authentication credentials.
Figure 2: Project description on the GitHub repository homepage after adding the README.
Figure 2: Project description on the GitHub repository homepage after adding the README.

6. Using the MIT License for Original Code

I ultimately chose to use the MIT License for the original content.

The copyright line is as follows:

Plaintext
Copyright (c) 2026 Qiang Wang

The MIT License has very few usage restrictions; others can:

  • Use;
  • Copy;
  • Modify;
  • Merge;
  • Publish;
  • Distribute;
  • Sublicense;
  • Use commercially.

For me, the main value of this repository is documenting real technical implementations and troubleshooting processes.

I am fine with others using it for reference, modifying it, or even using it in their own commercial projects, so there is no need to choose a more restrictive license.

Figure 3: GitHub has correctly identified the repository's MIT License.
Figure 3: GitHub has correctly identified the repository’s MIT License.

7. Third-Party Code Cannot Simply Be Uniformly Declared as MIT

The repository also stores the installed source code of two third-party plugins:

Plaintext
sources/slytranslate-installed/
sources/publishpress-series-installed/

These are not my original code, so adding an MIT License to the repository root does not relicense these third-party files as MIT.

Therefore, I added:

Plaintext
THIRD_PARTY_NOTICES.md

This file records the currently identified third-party projects and licenses.

SlyTranslate

The version saved in the repository is:

Plaintext
SlyTranslate 1.9.0

The plugin header information includes:

Plaintext
Author: Timon Först
License: MIT

PublishPress Series

The version saved in the repository is:

Plaintext
PublishPress Series Free 3.1.2

The plugin header declares:

Plaintext
GPLv3

Some code comments also mention:

Plaintext
GPLv2 or later

I did not attempt to explain the relationship between the two declarations this time; I just faithfully recorded them in the third-party notice.

vendor, translation files, images, and other bundled components continue to follow their respective original licenses.

The top-level MIT License only applies to the original code and documentation that I have the right to authorize; it does not override or replace the licenses of third-party components.

8. Scanning for Actual Credentials Again Before Making Public

After adding the documents, I ran another final credential scan.

This scan still covered:

  • The current complete working tree;
  • The entire Git history;
  • All tags;
  • Commit messages.

Focus of the scan:

  • Private key headers;
  • Common GitHub Tokens;
  • API Keys for OpenAI, Zhipu, DeepSeek, etc.;
  • Authorization Bearer;
  • Authorization Basic;
  • Cookies;
  • Database passwords;
  • WordPress salts;
  • Nonces;
  • OAuth client secrets;
  • Webhook secrets;
  • Usernames and passwords embedded in URLs.

The final result was still zero hits.

This scan no longer treated the following as secrets:

  • Domains;
  • Server directories;
  • SSH aliases;
  • Article IDs;
  • Attachment IDs;
  • SHA-256 hashes;
  • Deployment commands that do not contain authentication values.

This classification better fits my actual use case and avoids conflating “production environment information” with “authentication credentials.”

9. Running 62 Tests Before Making Public

Although only documentation was added this time and no code was modified, I still ran the existing featured image sync tests before committing:

Bash
bash patch/run-featured-image-tests.sh

Test results:

Plaintext
62 tests, 0 failures
Featured-image tests passed

PHP syntax checks and Git diff checks also all passed.

Figure 4: Terminal showing all 62 featured image tests passed.
Figure 4: Terminal showing all 62 featured image tests passed.

This step was primarily to confirm that the public repository preparation process had not accidentally modified existing code, nor broken the previously completed featured image attachment and English alt synchronization logic.

10. Committing and Pushing the Public Repository Documentation

The commit message for this change was:

Plaintext
docs: 增加公共仓库说明与 MIT 许可证

Full commit hash:

Plaintext
585b41873c3c81d14eca236935337d860a13079b

This commit contains only three new files, totaling 127 lines:

Plaintext
README.md
LICENSE
THIRD_PARTY_NOTICES.md

Push result:

Plaintext
52d9b94..585b418  main -> main

A regular push was used this time:

Bash
git push origin main

There was no force push, and no history was rewritten.

Figure 5: Codex completing the documentation commit and pushing to GitHub.
Figure 5: Codex completing the documentation commit and pushing to GitHub.

11. Using GitHub CLI to Switch Repository Visibility

The original plan was to execute:

Bash
gh repo edit shuijingwan/wordpress-ai-translation-pipeline \
  --visibility public \
  --accept-visibility-change-consequences

But the currently installed version of gh does not support:

Plaintext
--accept-visibility-change-consequences

The first execution failed directly during the argument parsing phase, so no modifications were made to the repository.

I then used the command supported by the current version:

Bash
gh repo edit shuijingwan/wordpress-ai-translation-pipeline \
  --visibility public

After successful execution, I read the repository status again:

JSON
{
  "visibility": "PUBLIC",
  "isPrivate": false,
  "defaultBranchRef": {
    "name": "main"
  }
}

GitHub has also identified the license:

Plaintext
MIT License
key: mit
Figure 6: GitHub repository page showing the repository has been switched to Public.
Figure 6: GitHub repository page showing the repository has been switched to Public.

12. Final Public Address

The repository is now officially public:

https://github.com/shuijingwan/wordpress-ai-translation-pipeline

Final status:

Plaintext
## main...origin/main

The working directory is clean, and the local branch matches the remote branch.

The following operations were not performed this time:

  • No Git history was rewritten;
  • No tags were deleted or rebuilt;
  • No force push was used;
  • No third-party source code was deleted;
  • No real domains or paths were replaced;
  • No existing code was modified;
  • No production servers were accessed;
  • No databases were modified;
  • No article translations were re-executed;
  • No production deployment was carried out.

13. The Most Important Judgment in This Process of Making the Repository Public

This experience led me to re-distinguish between two types of information that are often conflated.

The first type is environmental information:

  • Domains;
  • File paths;
  • SSH aliases;
  • Article IDs;
  • Attachment IDs;
  • Plugin directories;
  • Deployment steps.

The second type is authentication information:

  • API Keys;
  • Passwords;
  • Private keys;
  • Cookies;
  • Nonces;
  • Access Tokens;
  • Database credentials.

Environmental information might help others understand the server structure, but it cannot directly grant access.

Authentication information, however, could directly lead to system access, and must be strictly kept out of the Git repository.

If all production environment details are treated as secrets, it ultimately requires extensive sanitization, history rewriting, dual-repository synchronization, and additional maintenance processes. For a personal project focused on real technical practices, this cost may not be worthwhile.

A more appropriate approach is:

Focus on protecting the authentication information that can actually grant system privileges, while accepting the presence of domains, paths, and resource IDs in real technical records.

14. Milestone Summary

This repository was initially just for saving SlyTranslate and GLM translation optimization code, but gradually added:

  • Full-article translation;
  • Gutenberg structure protection;
  • Placeholder validation;
  • Code block protection;
  • English excerpt processing;
  • Polylang mapping;
  • English featured image attachments;
  • alt synchronization;
  • Automated tests;
  • Production troubleshooting evidence.

Switching the repository from private to public also serves as another milestone wrap-up for this round of WordPress AI translation quality optimization.

The final approach did not pursue theoretical maximum security isolation; instead, after confirming no actual credentials existed, it only added the necessary README, MIT License, and third-party notices.

No second repository was created, no sync scripts were maintained, and no history was rewritten.

For me, this approach is simpler, more stable, and better suited for long-term maintenance.

系列导航

需要长期技术维护或远程问题排查？

我是拥有 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

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章