Troubleshooting / Common Errors
Common errors
Find the message on your screen, read what it means, then follow the link for the fix. Each heading below is the exact text Workover shows, so you can search this page for the words you see. Where a message includes your site’s address or a number, this page shows that part as ….
Connecting a site
“Site not found or not a WordPress site.”
Workover could not find the address you entered, so it never reached WordPress. Check the URL for typos and that the domain is live. See Connecting your WordPress site.
“SSL Error. Self-signed certificate in the chain of trust.”
The site’s HTTPS certificate chain includes a self-signed certificate, and Workover does not trust it. The site needs a certificate issued by a public certificate authority, which your host can usually provide.
“This site is behind Cloudflare Access, which intercepted our request before WordPress saw it. Add a Cloudflare service token for Workover and paste it into the site connection.”
Cloudflare Access answered with its sign-in page before the request reached WordPress. Add a service token in the Cloudflare Access card in the project’s settings. This message can appear while you connect the site and later in the editor’s WP tab. See reaching a site behind a firewall or Cloudflare Access.
“Something in front of this site answered instead of WordPress, usually a firewall or security plugin blocking our request.”
A firewall, web application firewall or security plugin returned its own page instead of the WordPress REST API. Let Workover’s requests through. See reaching a site behind a firewall or Cloudflare Access and, for that plugin, Patchstack hardening settings.
“WordPress did not accept this”
When a push or a first publish fails, the WP tab shows a red box with this title and a message underneath. The message names the cause. Step-by-step fixes are in How to fix a push to WordPress that failed.
“… refused the connection. The application password no longer works.”
The full message continues: “This is what a rotated, deleted or expired password looks like, and reconnecting the site issues a fresh one.” Reconnect the site to issue a new application password.
“… refused the connection. Application passwords are switched off for this site or for this user, so no password can authenticate until they are enabled again in WordPress.”
Application passwords were turned off for the whole site or for the connected WordPress user. A security plugin or a hostingfilter hardeningin settingthe theme or a plugin is the usual cause. See Application passwords not available.
“… refused the connection. The connected WordPress account signed in, but no longer has permission to read or edit the content we sync.”
The WordPress user behind the connection lacks a permission the push needs. For example, a Contributor cannot publish, and an Author cannot edit other people’s posts. Reconnect with an account that has those permissions, or change the user’s role in WordPress.
“… refused the connection (HTTP …). WordPress did not say why”
The status code is 401 or 403. WordPress gave no reason, which usually means the application password stopped working, a security plugin is blocking Workover, or the host is stripping the authorization header. Reconnecting the site rules out the password first.
“… has no post at that address any more.”
The linked post no longer exists on WordPress, usually because someone deleted it there. The full message continues: “disconnect and reconnect the document to link it to a post that exists.” When WordPress sends its own explanation with the error, a push shows that instead, as “WordPress rejected the push: …”.
“That is the site erroring rather than Workover, so this is worth retrying in a few minutes”
The message starts “… answered …” with the status code the site returned (500 or higher). Retry later. If it keeps happening, the site’s error log says why.
“WordPress rejected the push: …”
WordPress refused the content itself, for example a bad category ID, a slug clash or a field a plugin requires. The text after the colon is WordPress’s own explanation, followed by any parameters it objected to. A first publish shows the same kind of failure as “… rejected the request: …”. When WordPress gives no explanation, either one reads “… rejected the request (HTTP …).”
“This document is linked to a post on …, and this project is now connected to …. Link it to a post on this site before pushing, or connect the project back to its original site.”
The project was pointed at a different WordPress site after this document was linked. Workover refuses the push so it never overwrites an unrelated post that happens to have the same ID on the new site.
“WordPress credentials are not available”
Workover has no usable stored login for this site. Reconnect the site.
“… rejected the request: …”
WordPress refused the content itself, for example a bad category ID, a slug clash or a field a plugin requires. The text after the colon is WordPress’s own explanation. A first publish shows the same kind of failure as “… rejected the request: …”. When WordPress gives no explanation, either one reads “… rejected the request (HTTP …).”
“The push did not go through, and WordPress did not say why.”
The fallback when no reason came back. A first publish shows “The publish did not go through, and WordPress did not say why.” Try again, then contact support with the time it happened.
Before a push goes through
“This post was changed in WordPress since your last sync. Pushing overwrites those changes.”
A Before you push… dialog. Someone edited the post in WordPress after your last pull or push. See How to fix a push to WordPress that failed and Sync status and conflicts.
“Pushing would remove … that exists on WordPress but isn’t editable here.”
Also in the Before you push… dialog, naming a count such as “2 embeddedexactly videos/media”.what. The live post has moresomething embeddedthe videoseditor orcannot otherrepresent, iframesuch embedsas thana theshortcode, versionan youembed areor pushing,a sothird-party block, and pushing would deletedrop them.it. See How to fix a push to WordPress that failed.
“One link points at a document that isn’t live”
With more than one, it reads “… links point at documents that aren’t live”. The document links to other Workover documents that are not published yet. Publishing removes those links and keeps their text, and the links come back automatically the next time you push after those documents go live. See Sync status and conflicts.
“… unresolved suggestions, accept or reject them first.”
The Push button is disabled because the document has pending suggestions. Publishing them would put the tracked changes, including the replaced text, on the live site. See How to fix a push to WordPress that failed.
Sync status
“New changes in WordPress”
The editor’s WP tab shows this, and the document list shows a WordPressbadge updatefor pill,it, when the post changed in WordPress since your last sync. If it keeps coming back after you pull, see “New changes in WordPress” keeps coming back.
Images
No message: imagesImages are missing on the live post
An image that fails to uploadAlmost toalways the WordPress media library doesupload notrather stopthan the push, so there is no error to read.content. See How to fix images that are missing after publishing.
CLI and MCP
“This action is not available to a CLI/MCP token. Sign in through the browser.”
An agent connected through the CLI or MCP tried something tokens cannot do at all. Do it in the browser instead. Account security and billing are never available to a token. See The CLI and MCP server.
“This token was not granted the “publish” scope. Re-run workover login --publish and approve it, or do this from the browser.”
The action is open to tokens, but only with a scope this token does not hold. Tokens get read and propose by default. publish, draft, write and rules are opt-in, and the message names whichever one is missing along with the matching workover login flag.
“Changing a document’s status is not available to a CLI/MCP token. Publishing is a decision a person makes in the browser.”
A token cannot change a document’s status. Change it in the browser.
“This post was changed in WordPress since your last sync. Pushing would overwrite those changes.”
A push made through a token can never overwrite a WordPress edit. When the post changed in WordPress, a person needs to resolve the conflict in the browser.
Still stuck
Contact support, and include the exact message you see.
Still need help?
Can’t find what you’re looking for? Our team is here to help.