Troubleshooting
How To Use This Page
Section titled “How To Use This Page”Pick the tab below that matches what the plugin is showing in WordPress admin. Each tab keeps the original symptom block — most likely cause, how to verify, how to fix — so you can read just the tab you need rather than the whole page. If two tabs both seem to match, work the more specific symptom first; the more general one will often clear up on its own.
If your problem is more about how TMXIO sees the site than about the plugin itself, see External Troubleshooting instead.
Symptoms
Section titled “Symptoms”The API key is invalid
Section titled “The API key is invalid”Most likely cause: the key is not valid for the account or was copied incorrectly. Trailing whitespace, smart-quoted characters, and truncation from a chat client are the usual culprits.
How to verify: copy a fresh API key from TMXIO into a plain text editor first, confirm there are no surprises, and then paste it into the plugin and validate it.
How to fix: reconnect with the correct key and make sure the correct workspace is selected. If the same key validates elsewhere but fails on this specific site, the failure is not really about the credential — move to the Connectivity tab.
Wrong workspace selected
Section titled “Wrong workspace selected”Most likely cause: the account can access more than one workspace, and the wrong one was picked during the connection flow. The site shows as connected, but it is reporting into a workspace where nobody is looking.
How to verify: open the plugin’s connection summary in WordPress and compare the workspace name with where you actually expect to see the site.
How to fix: disconnect and reconnect the site, picking the correct workspace on the way through. See Disconnect and Reconnect.
TMXIO is unreachable
Section titled “TMXIO is unreachable”Most likely cause: the site cannot reach TMXIO from its current host or security layer. The plugin’s outbound call is being filtered before it leaves the host or before it reaches TMXIO.
How to verify: run Test Connection and compare the result with the site’s normal outbound connectivity. If the site cannot load any external resource from PHP, the WordPress host has no outbound networking at all and needs that fixed first.
How to fix: confirm the site can make outbound web requests and is not blocked by an extra protection layer. If the host has an egress allowlist, add the TMXIO API hostname.
Heartbeat occasionally fails
Section titled “Heartbeat occasionally fails”Most likely cause: the host’s outbound networking is unstable or the host is saturated and the plugin’s cron is occasionally being skipped.
How to verify: correlate the missed heartbeats with host metrics. Persistent flapping during business hours usually points at a load problem; flapping at the same time every day usually points at a backup or cron storm.
How to fix: address the host-side cause. The plugin itself does not need changes; it just needs a stable place to run from.
The site is behind HTTP auth
Section titled “The site is behind HTTP auth”Most likely cause: a protected site is blocking the normal connection path. The classic version of this is an .htpasswd wall covering the entire site, including /wp-json/.
How to verify: check whether the site sits behind .htpasswd or another HTTP auth wall. Confirm by hitting the REST API endpoint directly from a shell:
curl -u user:pass https://example.com/wp-json/tmxio/v1/pingIf that returns successfully with credentials but is challenged without them, an auth wall is in front of the plugin’s API.
How to fix: coordinate the connection with that protection layer in mind. Either whitelist TMXIO’s outbound path at the auth layer or relax the wall for /wp-json/tmxio/. If you cannot change the auth wall in staging, you can temporarily disable it during the initial connection — but heartbeats will still need to pass continuously, so the wall must allow them long-term.
Cloudflare Access or SSO in front of the site
Section titled “Cloudflare Access or SSO in front of the site”Most likely cause: the site sits behind a corporate SSO layer that challenges every request, including outbound API calls from the plugin.
How to verify: load /wp-json/ from a browser session that has no SSO cookies. If you get bounced to an identity provider, every plugin call sees the same.
How to fix: add a service token or IP bypass in Cloudflare Access (or the equivalent in your SSO provider) covering the plugin’s API namespace.
Site limit exceeded or backup capacity is exhausted
Section titled “Site limit exceeded or backup capacity is exhausted”Most likely cause: the account or workspace has hit an allowed limit. New sites cannot register, or new backups cannot be stored, until capacity is freed or the plan is upgraded.
How to verify: compare the visible plugin or TMXIO message with the plan or capacity state in the account.
How to fix: review the workspace’s current plan and capacity with your account owner. Free up capacity by disconnecting decommissioned sites, or upgrade the plan to accommodate the new site.
Backups failing only on certain tables
Section titled “Backups failing only on certain tables”Most likely cause: a specific WordPress plugin is generating a high-churn log or audit table that is exceeding the backup window or storage budget.
How to verify: review backup failure detail for the affected site and look for table names tied to known logging plugins.
How to fix: see Backup Exclusions for the default and reviewed exclusion lists and how to request additional ones.
Disconnect fails
Section titled “Disconnect fails”Most likely cause: the local action ran but the remote cleanup did not complete as expected. The plugin shows a disconnected state but TMXIO still has the site as active.
How to verify: refresh both WordPress and TMXIO. If the dashboard still shows the site as connected after a refresh cycle, the states have drifted.
How to fix: contact support if the disconnect states do not reconcile on their own. Repeatedly toggling the disconnect button tends to make the drift worse rather than better.
Plugin deleted without disconnecting
Section titled “Plugin deleted without disconnecting”Most likely cause: the plugin was removed from Plugins in WordPress admin without going through the disconnect flow first. TMXIO has no signal except the absence of future heartbeats.
How to verify: the dashboard should mark the site as disconnected after ten consecutive missed heartbeats, which is the natural timeout.
How to fix: wait through the timeout, or contact support if you need the site removed from the dashboard sooner than the natural disconnect window.
cURL is missing or PHP is too old
Section titled “cURL is missing or PHP is too old”Most likely cause: the WordPress environment does not meet the plugin requirements. cURL is required for outbound HTTPS, and the plugin relies on language features in PHP 7.4+.
How to verify: review the notices shown by the plugin in WordPress admin. The plugin checks the environment on load and refuses to proceed if cURL is missing or PHP is too old.
How to fix: update the host environment before trying to connect again. Most modern WordPress hosts are on PHP 8.1+ already; only legacy shared hosting is still likely to be below 7.4.
Plugin conflicts after a WordPress update
Section titled “Plugin conflicts after a WordPress update”Most likely cause: another plugin or a theme started intercepting REST API requests in a way the TMXIO plugin cannot route around.
How to verify: disable plugins one at a time and re-run Test Connection after each disable. The conflict will surface when the offending plugin is off.
How to fix: report the conflict to support with the name and version of the conflicting plugin. Most conflicts are resolved on the conflicting plugin’s side rather than in TMXIO.