KakapoWP KakapoWP
Help Center/Troubleshooting/Connection to the Remote-Site fails

Connection to the Remote-Site fails

Applies to: All plugins· 4 min read

The plugins in the suite come with the “Remote Sites” (in German: „Remote-Sites“) area: there you connect further WordPress installations via an application password and operate them from here. Connecting, testing and removing run through the same shared code in every plugin, which is why the messages are worded identically everywhere. This article sorts out which is which.

The messages in detail

  • “Please provide a URL (http/https), user and application password.” — a field is empty or the address does not start with http:// or https://
  • “Site not reachable.” — no response came back at all; when you create the connection, “Connection failed:” appears in front of it, and when you check later, “Test failed:”
  • “Access data rejected (check application password).” — the target site responded with 401 or 403
  • “No valid REST response (code …).” — a response did arrive, but no JSON that can be evaluated; the code named is included
  • “Site not found.” — the entry you clicked is no longer in this installation's list

Creating a connection and checking it

  1. Open the page of the plugin in question in the WordPress menu and switch on the left to “Remote Sites” (in German: „Remote-Sites“) in the “Network” group.
  2. In the “Connect site” card, fill in the fields “Site URL”, “User name” and “Application password”.
  3. Click on “Connect & test”.
  4. You can check an existing connection at any time later via the “Test” button in the “Connected sites” table.
  5. Read off in the “Status” column whether the site is listed as “connected”, “error” or “unchecked”.

The test is an authenticated call to WordPress's own user route on the target site. It has 20 seconds and follows no redirects. Two address forms are tried: first the form with rest_route, which works with every permalink setting, then the path via /wp-json/. Only a genuine JSON response counts as success. After that the test looks up the name of the site through the root route; if that does not work, the host name appears in the list.

Green test, and the action still fails

  • The actions next to each site call dedicated routes on the target site: “Remote status” (in German: „Fernstatus“) and “Remote backup” (in German: „Fern-Backup“) in the Backup plugin, “Status” and “Clear cache” in Performance, “Send config” in Consent, “Security status” in Security, “SEO status” in SEO, “Fetch statistics” in Analytics, “Roles status” in Roles and “Provenance status” in Media
  • These routes require the manage_options capability on the target site — so the application password has to belong to an account with administrator rights
  • The plugin in question has to be installed and active on the target site. Otherwise the action fails: fetches such as “Remote status”, “Fetch statistics” or “Provenance status” report that nothing could be retrieved and give the response code, while “Remote backup”, “Clear cache” and “Send config” report “… failed:” with the target site’s response or its code
  • The fact that “Test” reports green only says that the address and the access data are correct — it says nothing about the plugin on the other side
  • In the Analytics plugin, the “Remote Sites” (in German: „Remote-Sites“) area only appears for administrators
The access data are stored unencrypted in this site's database. So create a separate application password for each connection, which you can revoke on the target site at any time — you will find it there under Users → Profile → Application Passwords.
Was this article helpful?