WORDPRESS
Why ModelGain Polylang Audit Abilities Are Hidden from REST
ModelGain Polylang audit missing from WordPress REST? Learn why abilities stay hidden by default, what 401/403/404 mean, and how permissions work.
FREE WORDPRESS PLUGIN
Multilingual Abilities
Inspect missing Polylang translation links and bounded language coverage without changing your posts or translation groups.
- Install with Polylang on WordPress 6.9+
- Check Tools → Multilingual Abilities
- Run a permission-aware, bounded audit
Read-only and administrator-gated. No translation, automatic link repair, background scan or bundled MCP server. Coverage is paginated by source posts, not a site-wide total. External REST exposure stays off unless explicitly enabled.
ModelGain’s Polylang audit abilities are hidden from the WordPress REST API by default on purpose. The four read-only abilities can be registered and callable inside WordPress while their HTTP discovery and execution routes return a 404. This is an exposure setting, not evidence that Polylang is broken, that the abilities are missing, or that WordPress authentication failed.
When an administrator explicitly enables external exposure in Tools → Multilingual Abilities, REST clients can discover the abilities. But discoverability is not authorization: execution still requires manage_options, a working Polylang provider and, for content records, the caller’s edit_post access. This guide explains the precise behavior of ModelGain Multilingual Abilities 0.1.0, with isolated real tests on WordPress 7.1 and Polylang 3.9.1.
Understand the three gates before troubleshooting
| Gate | Question | What it controls |
|---|---|---|
| Registration | Is the ability available inside WordPress? | Whether code can retrieve the exact ID with wp_get_ability() |
| REST exposure | Is show_in_rest true? |
Whether the ability can appear in REST listings and be addressed through its REST routes |
| Authorization | Can this user execute it and inspect these posts? | Ability-level manage_options and, on scanned records, edit_post |
The WordPress Abilities REST reference specifies that show_in_rest=false hides an ability from the REST interface while keeping internal PHP usage possible. The core REST controller independently checks the exposure flag and then invokes the Ability’s permission checks. The Abilities API requires WordPress 6.9 or newer.
1. What the ModelGain exposure switch actually changes
ModelGain registers exactly four native WordPress Abilities: modelgain-multilingual/list-languages, modelgain-multilingual/find-missing-translations, modelgain-multilingual/audit-language-coverage and modelgain-multilingual/check-translation-links. These are not Abilities supplied by Polylang itself. They inspect Polylang’s supported public language and translation-link APIs without modifying posts.
The ModelGain option external_exposure defaults to disabled. Its stored setting controls each ability’s meta.show_in_rest. The administrative checkbox in Tools → Multilingual Abilities changes the setting for the next request that registers those abilities.
- Disabled (recommended unless needed): internal PHP and authorized WP-CLI execution remain possible; HTTP clients cannot use these four REST Ability routes, even when already logged in as an administrator.
- Enabled by an administrator: the four abilities become eligible for authenticated REST discovery and execution, subject to their individual permissions. This is not anonymous access and does not turn them into public data endpoints.
- Not included: a bundled MCP server, general-purpose REST permissions override, translation creation, automatic link repair or scheduled scan. The optional WordPress MCP Adapter is a separate integration with its own configuration.
If your only task is an on-site administrative audit, leave external exposure off and follow the existing WP-CLI guide for all four abilities. Do not enable HTTP exposure merely to resolve a local PHP registration error.
2. Tested REST results by identity and setting
The following observations come from the native WordPress REST dispatcher in a disposable WordPress 7.1, PHP 8.3, Polylang 3.9.1 environment with ModelGain Multilingual Abilities 0.1.0. Both exposure settings were tested in separate WordPress requests so the Ability registry could read the persisted option. The Editor used a temporary standard WordPress editor account; no production credentials or posts were used.
| State and caller | REST listing | REST execution of list-languages |
|---|---|---|
| Exposure off; administrator | ModelGain ability excluded | 404 (hidden) |
| Exposure on; administrator | Ability listed | 200 |
| Exposure on; standard Editor | 200, ability listed |
403 |
| Exposure on; anonymous client | 401 |
401 |
Important subtlety: after enabling REST, a logged-in Editor can see the ability’s name and schema in the authenticated listing, even though that Editor cannot execute the audit. Thus, external exposure broadens discoverability more than it broadens execution permission. Standard role names are examples; actual WordPress capabilities, filters and custom role configurations are authoritative. Anonymous discovery was denied in this tested core configuration.
Do not conclude that every 404 means the ability does not exist. Conversely, a successful listing is not proof that the client can run it. Check the actual wp-abilities/v1 endpoint and response code, rather than assuming that a generic /wp-json/ index proves the ModelGain ability is callable. For a different error class, see Ability registration versus MCP discovery.
3. Why an Editor can manage translations but still cannot run the audit
The plugin’s Ability-level permission_callback requires current_user_can( 'manage_options' ) and a ready Polylang provider. Standard WordPress Editors can often edit Posts and Pages but do not ordinarily receive manage_options. This is a deliberate administrative-only scope for ModelGain 0.1.0, not a generic Polylang limitation.
For actual post inspections, there is a second check: current_user_can( 'edit_post', $post_id ). Even a user who passes manage_options will not see a source post that the current capability mapping denies. In our disposable test, a scoped denial of edit_post for one private post prevented it from appearing in the coverage result while an allowed source was included. The checker did not print the denied post’s title or body.
This has two operational consequences. A denied audit means no authorized result, not zero translation gaps. A result limited by per-post permissions is not evidence of complete site-wide coverage. Each content query is also limited to at most 100 source posts per page; repeated authorized calls may traverse later pages. Neither pagination nor the absence of post bodies is a substitute for limiting account privileges and exposure.
For general capability design, see WordPress AI agent permissions. Avoid granting manage_options indiscriminately just to make an external integration work: this is a broad administrative capability, not a plugin-specific audit-only role.
4. When it is reasonable to enable REST exposure
Enable the setting only when a specific external HTTP client needs to invoke these audits, its authentication and secret storage are already in place, and an administrator accepts the exposure. For local WP-CLI or internal PHP usage, no opt-in is required.
- Confirm WordPress 6.9+, Polylang installed and configured, and the published ModelGain Multilingual Abilities plugin active.
- Check Tools → Multilingual Abilities for provider readiness, registered abilities and current external exposure state.
- Use HTTPS for the external client. A WordPress Application Password is a revocable, per-application credential tied to a particular user account; it is not that user’s interactive login password.
- Choose the account deliberately: ModelGain requires
manage_optionsto execute these abilities. An Application Password does not itself narrow that user’s WordPress permissions. Do not publish credentials in a URL, command history, screenshots, issue reports or Git. - Enable the checkbox only after preparing a genuine authenticated-client test. Verify listing and execution separately using one approved account. Where appropriate, also verify a lower-privilege account receives denial. Do not run the test against private real content without authorization.
- Once the integration is no longer required, turn REST exposure off, then revoke its Application Password if it is no longer needed. These are distinct cleanup actions; neither performs the other automatically.
Application Passwords are supported by the normal WordPress REST authentication layer. The official administration guide documents setup, TLS expectations, per-integration revocation and common 401/403 failures. This article intentionally contains no live Authorization header or credentials.
5. Diagnose the error you have instead of weakening permissions
| What you observe | Likely boundary to check | What not to assume |
|---|---|---|
404 when an administrator tries a specific Ability REST route |
Exposure is disabled, ability is not registered, route/namespace is wrong, or a separate server layer blocks it. Confirm the exact HTTP path, PHP registration and setting. | Do not assume Polylang data is missing or that enabling MCP fixes it. |
401 for listing or execution |
No recognized authentication, an invalid/revoked Application Password, or a stripped Authorization header. | Do not make the route anonymous to get a 200. |
403 for execution |
Caller authenticated but lacks manage_options or another applicable permission. |
Seeing the ability in a listing does not imply execution access. |
| Admin can execute but no post appears | Check edit_post, source-language and post-type eligibility, allowed post statuses, and the scanned source page. |
Do not equate an inaccessible post with a missing translation. |
| Provider unavailable / ability not registered | Check active Polylang plugin and supported public API, WordPress version, ModelGain activation and correct installation. | Changing REST exposure cannot create an unregistered PHP ability. |
The core REST endpoints reference describes the difference between rest_ability_not_found, missing or invalid input and execution permission failures. WordPress REST route permissions are evaluated separately from authentication. A wrong HTTP method or malformed JSON input can also produce 4xx responses, so avoid treating every 4xx as a privilege problem.
6. Select the next safe diagnostic step
The following guide separates an intentionally hidden ability from an authentication or permission problem. It does not contact your WordPress installation or change its settings.
A Polylang audit Ability is missing or denied over REST. Which boundary failed?
Applies when: A WordPress 6.9+ administrator or authorized integrator using ModelGain Multilingual Abilities is diagnosing whether a native ability is registered, REST-hidden, listed without execution rights, or blocked by per-post permissions. This is a static troubleshooting guide, not a live test or credential tool.
Quick answer
ModelGain REST exposure is off by default while internal PHP execution remains available. Enabling exposure can make metadata discoverable, including to authenticated lower-privilege users, but does not grant manage_options, edit_post or change provider readiness. Do not loosen authentication to fix a 401/403.
What to do
-
Confirm WordPress 6.9+, the correct WordPress site, Polylang provider readiness and the registered ModelGain ability name before interpreting a REST 404.
-
Review Tools → Multilingual Abilities. External REST exposure is optional and should remain off for local WP-CLI or internal PHP audits.
-
When REST is explicitly enabled, test authenticated discovery and execution separately, then verify manage_options, relevant edit_post access and bounded source pagination.
What did the client actually observe?
All paths are listed below. Select a symptom to focus on the most relevant path.
Investigate authentication without making the endpoint public
Check HTTPS, recognized WordPress account, application-password status and whether a proxy stripped the Authorization header. A credential belongs to its user and inherits that user's capabilities. Do not place secrets in URLs, examples or logs.
Discovery does not grant permission to run
An authenticated editor may see an exposed ability's metadata but cannot run ModelGain audits without manage_options and a working Polylang provider. Do not grant broad administrator powers merely to remove a 403; use a reviewed, authorized integration account.
Review per-post visibility and source-page scope
A caller who passes manage_options must also be permitted to edit each inspected post. Missing entries can be permission-hidden or outside a bounded 100-source-post page; absence is not proof of a translation gap. Check source-language and post-type settings separately.
Did this help?
If your integration does not require HTTP access, the simplest correct configuration is REST exposure off. If HTTP access is justified, keep the duration and credentials limited, test authenticated discovery and execution separately, and retain the regular WordPress permission checks. The free ModelGain plugin is a bounded translation relationship diagnostic; it is not a general website security scanner, and these isolated tests do not certify your installation as secure.
Next references and product boundaries
To use the four abilities without REST, follow the local WP-CLI tutorial. To distinguish WordPress security exposure from a genuine anonymous execution incident, see public Abilities and MCP security. For the relevant plugin’s exact feature contract and installation, see the ModelGain product page or WordPress.org listing. No account provisioning, role modification, translation write API or automatic credential cleanup is supplied by this plugin.