wp-china-yes: a WordPress plugin tuned for the mainland China network

One plugin aimed at one network

The repository describes itself as an open source WordPress China site accelerator, and the product it now sells under the WenPai Yezi name, at WPCY.COM, is described as infrastructure software for the Chinese WordPress ecosystem, and as part of the WenPai open source project at WenPai.org.

The lineage explains the name. The WordPress localisation work in China started in 2019 with the plugin that was then called WPCY, and its predecessor was WP-China-Yes. In April 2023 WenPai Technology completed the acquisition of the project and carried out a full brand refresh, which is why the repository carries both the old name and the new one.

So the scope is narrow and deliberate. This is not a caching plugin, a CDN service or a page speed optimiser in the general sense. It is a set of substitutions for the specific third-party services that a WordPress site calls out to by default, made because those services are slow or unreachable from mainland China. The audience is therefore operators of WordPress sites with a Chinese readership, and the value is proportional to how much of a typical install depends on those services.

The homepage is wpcy.com, and the topic tags are china, wenpai, wordpress, wordpress-plugin and wpcy.

The feature list is a list of third-party services

The Features section is a checklist, and reading it as a list makes the plugin's scope obvious. It optimises the access speed of WordPress-related services in mainland China, and it optimises the loading speed of the WordPress admin. It removes useless requests and components from the admin.

Then come the substitutions, one per external service. It replaces Gravatar avatars with Cravatar, a different avatar service. It optimises the loading of Google Fonts, of Google's front-end libraries, of CDNJS and of Jsdelivr, so each of those is reached through a faster path rather than directly.

It also integrates with Chinese-facing replacements: WPMirror as a mirror update source for WordPress itself, Windfonts for Chinese webfonts, and adminCDN as a front-end public library. The last group of features is the operational side, and the next section covers it, because those are the ones that decide whether the plugin is safe to leave enabled.

Flight mode and the upstream fallback are what make it safe

Three features stand out because they are about failure rather than speed.

The first is flight mode, which can be enabled to block external API requests entirely. That is a blunt instrument, and it is presented as a switch rather than a default. In a network where those services are unreachable rather than slow, blocking them removes a long tail of stalled connections from page loads, and a site that depends on none of them loses nothing.

The second is the automatic fallback to the original upstream when a mirror is unavailable. This is the feature that turns the plugin from a hazard into something you can leave on. Every substitution the plugin makes is a single point of failure, and a mirror that goes down would otherwise take the site's fonts, avatars or libraries with it. With the fallback in place, the worst case is that the plugin quietly stops helping and the site behaves as it would have without it.

The third is the connection diagnostics and compatibility report, which gives an operator a way to see what the plugin is doing to their site rather than guessing. For a plugin whose whole job is rewriting outbound requests on a site you do not fully control, a diagnostic view is not a luxury, and the presence of one is a reasonable signal about how the project is maintained.

3.9.3 removed the front-end acceleration

There is a single note under the feature list, and it describes a removal rather than an addition. In version 3.9.3 the front-end acceleration that rewrote the site's own `wp-content` resources to point at a shared public endpoint was removed.

That is a significant change in behaviour, and it is worth understanding what it was doing. Rewriting your own uploaded assets to a shared endpoint means the site stops serving its own files and starts serving them from somewhere else, which is a large amount of control to give up for a speed gain. Removing it means the plugin now only substitutes the third-party services and leaves local assets alone, which is the more conservative design.

There is a versioning oddity here. The note refers to 3.9.3, while the listed releases are v3.8 from 2025-02-05, v3.7.1 from 2024-11-19 and v3.6.5 from 2024-08-23. The listed releases therefore do not include the version in which the removal happened, which is the kind of gap that makes it worth checking the actual release page rather than assuming the note applies to the build you are about to install.

For a site operator the takeaway is simple: the plugin's behaviour is not fixed across versions, so a version pin is a decision rather than an afterthought, especially if the site relies on the shared endpoint that 3.9.3 removed.

Install from a release, not from the source tree

The installation section is short and unusually emphatic. As with other WordPress plugins, download the latest version of the plugin from the Releases page, and the README adds a parenthetical in bold telling you not to download the source code directly, uploading it in the admin plugin page and activating it.

The reason for the emphasis is visible in the repository layout. This is not a plugin that can be dropped in as source and run. The root holds `wp-china-yes.php` and `Plugin.php` as the entry points, but also a `framework/` directory, a `Service/` directory, a `client/` directory, `templates/`, `helpers.php`, `assets/`, and a `composer.json` with a lock file, alongside a `package.json` and a `package-lock.json` for the JavaScript side. There is a `client` and a `framework`, which means there is a build step, and a source checkout is not the same artefact as a release.

The alternative route is the standard one: upload the plugin manually into the `wp-content/plugins` directory and then activate it from the admin.

For support, the README splits the channels. Questions about WordPress itself go to the WenPai support forum at wenpai.org/support, while problems with the plugin itself go to the Issues page on the repository, and the README links a guide on asking questions well for that purpose. There is also a QQ group with the number 1046115671 listed for contact.

Local development runs on wp-env and a smoke test

The development setup is small enough to describe in full, and it is in the package manifest. The package is named `wp-china-yes-development`, is marked private, and has one dev dependency, `@wordpress/env` at 11.12.0. The scripts are three:

  "name": "wp-china-yes-development",
  "private": true,
  "devDependencies": {
    "@wordpress/env": "11.12.0"
  },
  "scripts": {
    "env:start": "wp-env start",
    "env:stop": "wp-env stop",
    "test:wordpress": "bash tests/wordpress-smoke.sh"
  }

The first two start and stop a WordPress development environment through wp-env, and the repository root carries a `.wp-env.json` file that configures it. The third is the interesting one: the test suite is a shell script, `tests/wordpress-smoke.sh`, rather than a framework, and it runs against a real WordPress.

That choice fits a plugin whose job is to interfere with what WordPress loads. A unit test with mocked HTTP calls would not prove much about whether the admin is faster, and the `tests/` directory sits alongside a `scripts/` directory and a `docs/` directory in the root, with a `changelog.txt` for the WordPress plugin format and a separate `CHANGELOG.md`.

The repository also carries an `AGENTS.md`, a `composer.json` and `composer.lock` for the PHP side, and both a `.forgejo/` and a `.github/` directory, which suggests the project is developed on Forgejo and mirrored to GitHub.

GPL-3.0, a commercial vendor, and an infrequent release train

The licence is GPL-3.0, with the LICENSE file, a separate `license` file and a `copyright.txt` at the root, and the README closes with the copyright line naming WPCY.COM and WenPai, a technology company based in Guangzhou, with the year 2026.

So this is an open source project published by a company, which is the normal arrangement for a plugin sold as infrastructure with a support forum and a sponsor section. For an operator, the practical questions are the ones the GPL answers, such as what you may do with the code and what notice you must keep, and what the company does not answer, such as what support commitments exist.

The release cadence is slower than the commit cadence. The recent releases are v3.8 from 2025-02-05, v3.7.1 from 2024-11-19 and v3.6.5 from 2024-08-23, and the repository is not archived with the last push on 2026-10-20. So the branch is well ahead of the newest published build, and the plugin you download from the Releases page is not the same as the code on master.

That gap is the thing to keep in mind when reading the feature list. The list describes the current design, including the removal of the shared-endpoint acceleration in 3.9.3, while the published artefacts may predate it. The install instructions point you at the Releases page rather than the source, and that instruction is doing more work than it looks.

Editorial conclusion

wp-china-yes fits a site operator whose WordPress install is slow or partly broken because Google Fonts, Gravatar, jsdelivr and CDNJS are slow or blocked from mainland China, and who can accept a plugin from a Chinese vendor rewriting third-party requests. It is the wrong choice for a site that is not affected by those access problems, since almost everything it does is a substitution you would not want. Verify first that the release you install is the one whose behaviour you expect, because the project removed a front-end acceleration feature in 3.9.3, and read the licence and copyright file, which name WenPai in Guangzhou rather than a foundation or individual.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. WenPai-org/wp-china-yes on GitHub