Custom REST-API-Prefix und umbenannte Admin-Slugs

WordPress lässt dich die REST-API-Base-Path away von Default /wp-json/ ändern. Eine Handvoll “Hide-WordPress”-Plugins benennt auch wp-admin zu einem Custom-Slug um. Beides bricht Hubbees Default-Annahmen — Fix: Hubbee den echten Prefix mitteilen.

Wie du das Problem erkennst

Diagnose meldet rest_api_blocked oder unreachable, und curl https://your-site.com/wp-json/ returnt HTML (WordPress-Homepage) statt JSON. Heißt: REST-API ist remapped.

Welche Plugins das tun

• WPS Hide Login — Login-Slug, optional Admin-Area
• Hide My WP Ghost — /wp-admin/, /wp-content/, und REST-Path
• iThemes Hide Backend (in Solid Security) — Admin-Slug
• All In One WP Security → Brute Force → Rename Login URL — nur Login
• Custom rest_url_prefix Filter in functions.php oder Custom MU-Plugin

Echten Prefix bestätigen

WP-Admin → Settings → Permalinks, scroll runter — wenn ein Plugin REST-API remapped hat, zeigt die Seite typisch den neuen Prefix. Andernfalls Code-Check:

// wp-config.php oder functions.php
add_filter('rest_url_prefix', function() {
  return 'my-api';
});

Oder via URL testen:

curl -i https://your-site.com/my-api/ | head -5
# Expect: HTTP/1.1 200 OK mit JSON-Body

Der erste Pfad-Segment das JSON returnt ist dein Prefix.

Hubbee den Custom-Prefix mitteilen

Im Add Site-Dialog → Advanced → Custom REST prefix ohne Slashes:

my-api

Hubbee triggers https://your-site.com/my-api/bz/v1/* statt /wp-json/bz/v1/* für alle Folge-Calls. Bereits-verbundene Sites: Site → Settings → Connection → REST prefix.

Hide My WP Ghost — Spezialfall

Hide My WP Ghost rewriten REST-Paths in zwei Layern:

1. Frontend rewrite (im Browser sichtbar) — handled vom Prefix-Setting oben
2. Backend rewrite (eigentliche WP-Route-Registration) — abhängig vom Mapping mode

Wenn Hubbee nach Prefix-Setting fehlschlägt:

• Hide My WP → Settings → Tweaks
• Set REST API Mapping auf Full (nicht “Show old REST too”)
• Stellt sicher dass Plugin Routes unterm neuen Prefix generiert

Manche Hide-My-WP-Versions blocken auch Path-Probing. Whitelist Hubbee unter Hide My WP → Permissions → Whitelist IPs mit Hubbee-IP-Set aus Privacy Policy.

Multisite-Netzwerke

In Subdirectory-Multisite (example.com/site1/), REST-Endpoint pro Subsite:

https://example.com/site1/wp-json/bz/v1/*

Hubbee handled das automatisch — jede Subsite separat verbinden, kein Prefix-Change nötig.

In Subdomain-Multisite (site1.example.com) hat jede Subdomain ihren eigenen REST-Root /wp-json/. Gleich — jede Subdomain als eigene Hubbee-Site verbinden.

Connection nach Korrektur

Nach Update des REST-Prefix in Hubbee:

1. Save im Connection-Dialog oder Settings-Card
2. ~30 Sekunden auf nächsten Heartbeat warten
3. Site-Status flipped von connection_error zu online nach erfolgreichem Heartbeat

Wenn noch fehlschlägt, Site → Diagnose starten — Probe nutzt jetzt den korrigierten Prefix und sagt dir genau welcher Downstream-Check noch fehlschlägt.