Pro module1 ability

Diagnostics ability reference: integration health

Reference for the GoBuildWP Pro 1.12.4 source. Installed schemas and policy remain authoritative.

This Diagnostics ability reference covers one read-only call, wppilot/integration-health, which answers the question every missing tool raises: is the ability absent, or is something stopping it from loading?

By GoBuildWPContent updated 12 October 2026How we check claims

Read-only, write and destructive groups describe the source annotations. They do not establish a minimum safety profile, human approval or undo support. Those controls are separate: check the installed ability, the connected user and the active site policy before calling it. A read can still return sensitive data. These pages are not evidence that every operation passed an end-to-end runtime test.

What Diagnostics needs before these load

It ships inside GoBuildWP Pro and needs no other plugin. It registers into the diagnostics category that GoBuildWP Free creates, and Free only creates its categories while AI abilities are switched on, so with abilities off the call is not offered at all. Running it needs the manage_options capability: an editor's credential will not see it.

What the report returns

status is healthy or degraded. It turns degraded while any recorded failure is still unresolved, and it clears by itself: when an integration that failed later loads cleanly in the same phase, its failure is stamped resolved_at and kept as history rather than deleted, so a fixed problem stops raising the alarm without losing the record of what happened.

integrations lists every Pro specialisation with two separate facts. category_active says whether the plugin it serves is present (or the module is always on). load_eligible says whether its loader gate passed. A row that is active but not eligible is the common case after an update: the plugin is there, but below the module's version floor, or the licence gate has not passed. integration_count and eligible_count summarise the list.

recorded_failures carries each integration whose loading threw: the error class, the first 500 characters of the message, the file name and line, when it was first and last seen, and how many times it has happened. They live in the wppilot_pro_integration_failures option, capped at the 100 most recent. request_events describes how each integration loaded during the one request that answered this call; it is held in memory only, so it says nothing about earlier requests.

Why one broken integration does not break the rest

Each specialisation loads in isolation. When one throws, the exception is caught, recorded in the list above and written to the PHP error log as a line starting "[GoBuildWP Pro] Integration" followed by its slug and the phase it failed in. The other integrations carry on loading, so a site whose Bricks module is failing still has its WooCommerce tools, and the host's log viewer shows the failure even when no AI client is connected.

Before accepting the result

Illustrative states: healthy with a historical resolved_at failure is not degraded; category_active=true with load_eligible=false means present but gated. Inspect the actual gate and recorded failure before choosing a remedy.

Safety profiles and human confirmation

Representative call sequence

This sequence describes the documented calls and checks to perform. It is not a recorded result from an installed WordPress site. Inspect returned errors and partial results, then verify the saved values and affected output before proceeding.

An agent reports that the Rank Math tools have vanished from its tool list after a plugin update.

01 wppilot/integration-health Returns the rank-math row. If category_active is true and load_eligible is false, the plugin is installed but a gate refused it: a version below the floor, or the licence.
02 wppilot/integration-health If the row instead appears under recorded_failures, the message and file name point at the code that threw; update or roll back the plugin, then call again and look for resolved_at on that entry.

Questions about Diagnostics

Does integration-health change anything on the site?

No. It is annotated read-only and idempotent: it reads the manifest, evaluates each gate and returns the stored failures. It never clears a failure itself; a failure is only marked resolved when the integration next loads cleanly.

The plugin is active but its abilities are missing. Where do I look first?

At load_eligible for that integration in this report. False with category_active true means a gate stopped it, which the row names. If the integration is healthy here and still missing from the client, the cause is further down: the active safety profile, an ability switched off, or the WordPress capabilities of the connected user.

Diagnostics reads

Ability What it does

wppilot/integration-healthIntegration Health Reports why an integration is not answering, which is otherwise indistinguishable from the ability not existing. Every Pro specialization is listed with two separate facts: whether its category is active, and whether its loader is eligible to run — a plugin present but below its version floor, or a licence gate that has not passed, shows as active and not eligible rather than silently missing. recorded_failures carries integrations whose loading threw, so one broken specialization is reported here instead of taking the rest of the plugin down with it, and request_events shows how each integration loaded during the request that answered this call (it is held in memory only, not kept between requests). status is degraded only while recorded failures remain unresolved; history with resolved_at stays visible without degrading health. Run this before concluding an ability is unavailable: the answer is usually a gate rather than an absence, and the gate names itself.

Ability	What it does
`wppilot/integration-health`Integration Health	Reports why an integration is not answering, which is otherwise indistinguishable from the ability not existing. Every Pro specialization is listed with two separate facts: whether its category is active, and whether its loader is eligible to run — a plugin present but below its version floor, or a licence gate that has not passed, shows as active and not eligible rather than silently missing. `recorded_failures` carries integrations whose loading threw, so one broken specialization is reported here instead of taking the rest of the plugin down with it, and `request_events` shows how each integration loaded during the request that answered this call (it is held in memory only, not kept between requests). `status` is `degraded` only while recorded failures remain unresolved; history with resolved_at stays visible without degrading health. Run this before concluding an ability is unavailable: the answer is usually a gate rather than an absence, and the gate names itself.