Der Browser-Administrator bei /webadmin und Internal Content API sind zwei Eingangstüren zu denselben CMS-Daten, aber sie wurden nicht zur gleichen Zeit erstellt und decken nicht den gleichen Bereich ab. Das Panel ist die komplette Bedienoberfläche. Die API ist eine bewusst schmalere Oberfläche für vertrauenswürdige KI- und Bedienertools.

Dieses Dokument ist die maßgebliche Übersicht darüber, wo sich die beiden einig sind, wo die API weniger abdeckt und wo die Lücke eher eine bewusste Grenze als unvollendete Arbeit darstellt. Es existiert so:

• an KI oder Bedienertool kann herausfinden, was es nicht kann, bevor es es versucht;
• Ein Prüfer kann eine absichtliche Grenze von einem fehlenden Endpunkt unterscheiden;
• Roadmap-Arbeit hat eine einzige Liste, gegen die geschlossen werden kann.

Es handelt sich um einen Statusdatensatz, nicht um eine Spezifikation. Wenn ein Endpunkt ausgeliefert wird, aktualisieren Sie die Zeile hier im selben Commit.

Jede Zeile trägt einen Status:

„Panel-only by design“ ist kein Synonym für „hart“. Dies bedeutet, dass der Ausschluss die im Abschnitt „Grenzen“ von Internal Content API beschriebene Sicherheitslage darstellt: keine automatische Veröffentlichung, kein Crawling oder Remote-Abruf, kein willkürlicher Import/Export-Ersatz und keine Rechteausweitung durch ein Token.

Die API ist kein einzelnes Präfix. Ein in das CMS integriertes Tool kommuniziert mit zwei:

Die Aufteilung ist eher historischer als prinzipieller Natur. /admin-api existierte vor dem Fähigkeitsmodell und seine Routen überprüften nichts über die Token-Gültigkeit hinaus, bis domains.write und domains.delete eingeführt wurden – jedes gültige Token konnte eine Domäne hinzufügen oder entfernen. Die Domänenrouten leben jetzt auch unter /webadmin/api, wohin neue Integrationen führen sollten; Das Legacy-Präfix funktioniert weiterhin für vorhandene Bereitstellungstools.

Fähigkeiten sind in CmsApiTokenCapabilities definiert. Eine Lücke in diesem Dokument ist manchmal eine fehlende Fähigkeit oder eine fehlende Route.

Die beiden, die diese Liste früher dominierten, sind geschlossen.

Seitenidentität und Seitenübersetzungen. create_draft_pageschreibtname,slug, Undpathauf eine Seitenübersetzungszeile für ein Gebietsschema, und bis zur Landung der Seitenübersetzungs-API konnte danach nichts mehr diese Zeile berühren: Die Ersetzungs- und Stufenaktualisierungsmodi normalisieren sichpageZunullund verarbeiten nur Slot-Inhalte. Eine Seite, die im falschen Pfad erstellt wurde, konnte nur durch Löschen und Neuerstellen behoben werden, keine Seite konnte ein zweites Gebietsschema erhalten und SEO auf Seitenebene –seo_title,seo_description,seo_keywords,og_title,og_description,og_image_media_id, die sich alle in dieser Zeile befinden, war nicht beschreibbar und fehlte auch in den Lesenutzdaten.

/pages/{page}/translations/*deckt jetzt alles ab, und weilPageTitel und Slug werden bis zur Standardübersetzung durchgelesen. Durch das Umbenennen dieser Übersetzung wird die Seite umbenannt. SehenLokalisierungwarum diese Felder in die Übersetzungszeile gehören undInternal Content APIfür den Schreibvertrag.

SEO-Standardwerte auf Website-Ebene sind aus einem anderen Grund immer noch nicht erreichbar; siehe Websites unten.

Ab 1.91.0 machen acht native Medienblöcke auch mobile_media_id in Plänen und PATCH verfügbar, mit der gleichen Auswahl und dem gleichen Fallback wie im Panel. Siehe Medienbildvarianten.

Blocks sind der am besten ausgerichtete Bereich des CMS. Das Schreiben von Einstellungen wird zusätzlich durch BlockSettingsPatchPolicy eingeschränkt, was eher ein Schutz als eine Lücke ist.

Deletion erfordert die destruktive Funktion shared-slots.delete und weigert sich, einen Shared Slot von allen Seitenslots zu entfernen, auf die noch verwiesen wird, und listet die referenzierenden Slots auf, damit ein Tool sie zuerst trennen kann.

POST /media/folders lehnt einen Namen ab, der bereits unter demselben übergeordneten Ordner vorhanden ist, und gibt den vorhandenen Ordner zurück, sodass ein Wiederholungstool ihn wiederverwendet, anstatt Duplikate anzuhäufen.

Kontaktnachrichten haben überhaupt keine API-Darstellung. Ein Tool kann über die API ein Kontaktformular erstellen, aber weder seine Einsendungen lesen noch erfahren, wohin sie übermittelt werden – siehe Sites.

Das Panel-Site-Formular schreibt mehr als zwanzig Felder. Die API deckt sie durch schmale Einzweck-Endpunkte ab: branding, head, timezone, public-theme, seo, contact-recipient und locales.

Was hier noch fehlt, ist die Site-Identität – Name, Handle, primäres Flag – und Site-Variablen. Diese sind näher an der Bereitstellung als an Inhalten, und noch kein Tool hat sie benötigt.

Alles in dieser Gruppe ist lesbar und nichts davon ist beschreibbar.

Schreibgeschützter Schemazugriff ist vertretbar: Blocktypen und Layouts sind strukturelle Verträge, und wenn man sie von einem Token erfinden lässt, erweitert sich der Explosionsradius jedes späteren Schreibens von Inhalten. Es wird als „Teilweise“ und nicht als „Beabsichtigt“ erfasst, da eine solche Entscheidung nirgends niedergeschrieben ist.

Bis dies behoben wurde, war jede Lücke in diesem Dokument seitens des Anrufers still.

POST /content/validate und POST /content/apply lehnten eine feste Liste verbotener Schlüssel ab – Veröffentlichungs- und Planungsschlüssel, Site-Erstellung, Remote-Abruf und destruktive Verben – aber nichts, was lediglich unerkannt blieb. Die Plannormalisierung las die ihm bekannten Schlüssel und ignorierte den Rest, sodass ein Plan mit page.seo_title ok: true zurückgab und ein 201 nichts davon schrieb. Ein Tool hat einen Erfolg gemeldet; nichts war passiert. Auch das Zurücklesen der Seite brachte es nicht zutage, da die Felder, die die API nicht schreiben kann, auch in ihren Lese-Payloads fehlen.

Unerkannte Schlüssel werden jetzt mit 422 und dem stabilen Code unsupported_plan_fields abgelehnt, und der Fehlerpfad benennt jedes abgelehnte Feld. Der akzeptierte Schlüsselsatz ist auf den Plan mode beschränkt: replace_slots ist beim Ersetzen einer Seite sinnvoll und beim Erstellen einer Seite abgelehnt.

Dadurch wird keine Lücke geschlossen. Dadurch werden sie erkennbar, was die Voraussetzung dafür ist, dass ein Tool auf das Panel zurückgreifen kann, anstatt einen Schreibvorgang zu melden, der nie stattgefunden hat.

Sortiert danach, wie viel jeder entsperrt, nicht nach Aufwand.

Stufe 1 – abgeschlossen

1. Nicht erkannte Planschlüssel ablehnen mit422.Siehe Unbekannte Planschlüssel oben.
2. Schreibendpunkt für Seitenübersetzung. /pages/{page}/translations/*schreibt Name, Slug, Pfad, SEO und Open Graph und liest sie zurück.
3. Aktualisierung der Seitenidentität.Wird mit 2 geliefert: Titel, Slug und Pfad sind Übersetzungsfelder, und die Standard-Gebietsschema-Übersetzung ist die eigene Identität der Seite.
4. Shared Slot aktualisieren und löschen. PATCHUndDELETE /shared-slots/{sharedSlot}, Letzteres hinter dem Neuenshared-slots.deleteFähigkeit.

Stufe 2 – abgeschlossen

1. Erweitern Sie die Site-Einstellungen: SEO-Standards,contact_recipient_email,locale_ids. /sites/{site}/seo,/contact-recipient, Und/locales.
2. Seitenvorschau oder Render-Snapshot. GET /pages/{page}/render, mitformat=htmlund länderspezifisches Rendering. Als die Liste geschrieben wurde, wurde der Gültigkeitsbereich falsch festgelegt:/webadmin/pages/{page}/previewhat bereits ein Bearer-Token akzeptiert, daher bestand die Lücke in der Auffindbarkeit und der Auswahl des Gebietsschemas und nicht in der Fähigkeit zum Rendern.
3. Erstellung von Medienordnern. GET/POST /media/folders.
4. Capability-Gate für die Domänenrouten und Verschieben nach unten/webadmin/api.Fertig, undupdateUndset primarykam mit.

Was übrig bleibt

Alles, was oben noch als „Fehlend“ markiert ist, ist zweitrangig: Seitenduplizierung und Site-Verschiebungen, Massenvorgänge, der HTML-zu-Block-Konverter, Kommentarlöschung, Kontaktnachrichten, Schemaerstellung, Neuindizierung der Suche und Besucherberichte. Keines davon hindert ein Tool daran, eine Seite zu erstellen, zu prüfen, zu korrigieren und zu veröffentlichen, worum es bei den Stufen 1 und 2 ging. Wählen Sie nach Bedarf aus, anstatt die Liste durchzuarbeiten.

Stufe 3 – bewusste Grenzen

Benutzer, Token-Ausgabe, Systemeinstellungen, Backup-Wiederherstellung/-Download, Site-Erstellung und -Löschung, Klonen, Heraufstufen und Übertragen bleiben nur im Bedienfeld verfügbar. Systemaktualisierungen sind über separat gewährte, installationsweite API-Funktionen ab 1.90.0 verfügbar. Sie werden hier aufgelistet, sodass „nicht in der API“ eine aufgezeichnete Entscheidung und nicht eine ungeprüfte Abwesenheit ist.

Ab 1.92.0 übernehmen Panel- und API-Installation/-Aktualisierung/-Aktivierung erforderliche Plugin-Datenbankänderungen automatisch und behalten nach einem Fehler einen deaktivierten Status bei. Aktivieren/Setup verwendet dasselbe Kompatibilitätsgate; Inkompatible Anfragen geben HTTP 409 und plugin_incompatible zurück. Ab 1.94.0 wird die Startup-Validierung in einem neuen Prozess vor der Aktivierung ausgeführt, erfolgreiche Updates behalten das vorherige Paket bei und Laufzeitquellen-/Routenfehler stellen das Plugin unter Quarantäne.

Recovery bei /webadmin/plugin-recovery ist eine separate authentifizierte Paneloberfläche. CMS 1.94.2 erfordert einen aktiven Super admin mit normalem Administratorzugriff. Es kann ein fehlerhaftes verwaltetes Plugin deaktivieren oder das beibehaltene Paket nur dann wiederherstellen, wenn keine Datenbankmigration ausgeführt wurde. Der Tokenzugriff auf /plugins/* ersetzt nicht diese Browser-Wiederherstellungsberechtigung. Siehe Plugin System.