Interne Content-API

Der Internal Content API ist ein sicheres CMS API für vertrauenswürdige KI- und Bedienertools. Damit können diese Tools CMS-Inhaltsverträge überprüfen, Inhalte zuerst als Entwurf erstellen, bestimmte seiteneigene Slots auf vorhandenen Entwurfsseiten ersetzen, explizite Veröffentlichungsvorgänge über strukturierte JSON ausführen und zugelassene Admin-Render-Snapshots für die visuelle Qualitätssicherung anfordern, ohne sich bei der Browser-Administrator-Benutzeroberfläche anzumelden, sie zu scrapen oder zu automatisieren.

Phase 1 wird als tokengeschütztes, nur JSON nicht öffentliches API für die schreibgeschützte Inhaltserkennung sowie die Erstellung von Entwurfsseiten durch validierte Inhaltspläne implementiert. Phase 2A fügt sichere Grundlagen für Navigationsmenüs, Shared Slots, und die explizite Seitenslot-Zuweisung Shared Slot hinzu. Phase 2B fügt einen kontrollierten Nur-Entwurf-Ersatz für seiteneigene Slot-Inhalte auf vorhandenen Seiten hinzu. Veröffentlichungsendpunkte sind explizit und erfordern content.publish; Der Inhalt gilt weiterhin als Entwurf und wird nicht veröffentlicht. Der API bleibt absichtlich eng: kein Remote-Abruf, keine breite Seitenlöschung durch Inhalt, kein Ersatz von durch Shared Slot unterstützten Slots und keine Shared Slot-Kaskadenveröffentlichung.

Die Interne Content-API ist:

• eine interne/Operator-CMS-API
• tokengeschützt
• nicht öffentlich
• keine Headless-CMS-Auslieferungs-API
• kein Ersatz für Admin-Berechtigungen
• kein Ersatz für Import/Export
• keine Integration eines KI-Anbieters

Der CMS-Kern sollte Eigentümer dieser API sein, weil sie auf zentralen Content-Konzepten arbeitet: Sites, Seiten, Layouts, Slots, Blöcke, Übersetzungen, Navigation und Shared Slots. KI- oder Operator-Tools dürfen die API aufrufen, aber der CMS-Kern sollte keine OpenAI-, LLM-, Crawler- oder anbieterspezifische Integrationslogik einbetten.

Das kanonische Präfix lautet:

Dadurch bleibt API innerhalb der CMS-Administratorgrenze, während ein prägnantes, vertrautes API-Segment verwendet wird. Endpunkte im Ressourcenstil sollten direkt unter diesem Präfix leben, z. B. /webadmin/api/pages und /webadmin/api/blocks.

Bevor Sie Inhalte planen, lesen Sie das Paket CMS Inventory mit GET /webadmin/api/inventory. Es handelt sich um den Design- und Authoring-Vertrag pro Block und um das erste Dokument, das eine KI lesen sollte. Der html-Block ist nur für Menschen bestimmt: Er bleibt durch API lesbar, aber jede ihn berührende API-Mutation wird mit 422 und dem stabilen Code block_type_not_api_writable zurückgewiesen, und keine Funktion überschreibt dies. Ermitteln Sie für einen application-Block zunächst eine fertige Definition und das zugehörige Einstellungsschema über GET /webadmin/api/applications. API-Schreibvorgänge verweisen möglicherweise auf registrierte Anwendungen, können jedoch keinen ausführbaren Code oder Dateipfade einführen.

API-Erkennung beginnt bei:

Nicht authentifizierte Anrufer erhalten nur den öffentlich-sicheren Bootstrap JSON. Authentifizierte Anrufer erhalten sichere Produktversionsmetadaten sowie Links zu OpenAPI, dem KI-Leitfaden, Inhaltsvertrag, Beispielen, Inhaltsvalidierung/-anwendung, Seiten, Blöcken, Medien, Navigation und Shared Slots. Externe KI-/Operator-Tools sollten von dieser Live-Erkennungsantwort ausgehen, anstatt das CMS-Repository oder das lokale Paket docs.

zu lesen

Planbasierte Inhaltsvorgänge verwenden:

Zu vermeidende Routenentscheidungen:

• /webadmin/internal-api, weil es unnötig lang ist
• /webadmin/api/content-plans/..., weil content-plans für den URL-Vertrag zu technisch und zu eng ist
• jede Ressource unter /webadmin/api/content/... zu platzieren, weil Ressourcen-APIs klar und direkt bleiben sollten
• /admin, weil das CMS nicht annehmen darf, dass der /admin-Pfad des Host-Produkts dem CMS gehört
• /cms, weil /cms ausschließlich für statische CMS-Assets reserviert bleibt

Die API verwendet Bearer-Token-Authentifizierung:

Das CMS verfügt über zwei Token-Oberflächen. Redakteure, Site-Administratoren und Superadministratoren erstellen persönliche API-Tokens aus Profile -> Personal API Tokens; Diese Token fungieren als ihr Besitzer innerhalb der Live-Rollen-, Site-, Workflow-, Netzwerk- und Fähigkeitsgrenzen. Superadministratoren erstellen System-API-Tokens aus System -> API Tokens für eine explizit autorisierte Automatisierung auf Installationsebene. Das CMS speichert lediglich einen SHA-256-Hash plus eine sichere Vorschau in der Datenbanktabelle cms_api_tokens. Das einfache Token wird unmittelbar nach der Erstellung einmal angezeigt und nie wieder angezeigt.

Der Bereich für einmalige Token bietet Kopiersteuerelemente sowohl für das vollständige Token als auch für das generierte lokale .env-Beispiel. Kopier-Feedback wird barrierefrei angekündigt und die Browser-Implementierung beinhaltet einen Fallback für Umgebungen ohne die moderne Zwischenablage API.

Tokens, die mit dem älteren Standard-Funktionssatz für die Seitenerstellung erstellt wurden, werden zur Laufzeit als für die schreibgeschützte Funktion admin.render geeignet behandelt, sodass vertrauenswürdige Operator-Tools nach der Aktualisierung die Snapshots der visuellen Qualitätssicherung des Administrators auf der Zulassungsliste verwenden können, ohne das Token zu rotieren. Schmale benutzerdefinierte Token, die den früheren Standardsatz nicht enthalten, bleiben eingeschränkt.

Bide Token-Bildschirme enthalten eine Verlaufsaktion für jeden Token. Es öffnet ein WebBlocks UI-Modal mit den neuesten 10 API-Aktivitätsdatensätzen für dieses Token. Aktivitätsdatensätze sind absichtlich klein: Anforderungszeit, Status, Methode, Pfad ohne Abfragezeichenfolge, Routenname, erforderliche Fähigkeit, wenn ein Fähigkeitswächter ausgewertet wurde, IP und ein kurzer Benutzeragentenwert. Das CMS speichert keine Anforderungstexte, Abfragezeichenfolgen, Antworttexte, Trägertokenwerte, Token-Hashes oder Tokenvorschauen in Aktivitätszeilen. Ältere Aktivitätszeilen werden automatisch bereinigt, sodass jedes Token nur die letzten 10 Datensätze behält.

Benutzer können ihre eigenen persönlichen Token bearbeiten, widerrufen und löschen; Superadministratoren verwalten Systemtokens. Durch das Bearbeiten werden Richtlinienmetadaten geändert, ohne dass das Geheimnis preisgegeben wird. Durch den Widerruf wird der API-Zugriff sofort deaktiviert, während die Prüfzeile erhalten bleibt. Durch das Löschen eines Tokens werden es und sein Aktivitätsverlauf dauerhaft entfernt.

Lokale KI- und Bedienertools sollten das generierte Token in einem vertrauenswürdigen Betreibergeheimnisspeicher speichern.

Verwenden Sie die Basis-URL Internal Content API in der lokalen Operatorkonfiguration:

Die CMS-Laufzeit erfordert kein WEBBLOCKS_CMS_INTERNAL_API_TOKEN.

Authentifizierungsregeln:

• fehlende, falsche oder widerrufene Token geben JSON 401
• widerrufene Token funktionieren sofort nicht mehr
• Tokens dürfen niemals in Protokollen, Diagnosen, Supportberichte, Tests oder Dokumentationsbeispiele
• Token-Vergleich muss einen Vergleich mit konstanter Zeit verwenden
• erfolgreiche API-Anfragen aktualisieren die Tokens last_used_at und last_used_ip
• erfolgreiche API-Anfragen speichern auch einen verkürzten Benutzeragenten für den Operator-Audit-Kontext
• normale Ressourcenantworten und alle Fehler sind JSON; Visuelle QA-Routen auf der Zulassungsliste können nur dann direkt HTML zurückgeben, wenn der Aufrufer explizit ein HTML-Format

anfordert

Beispielanfrage:

Token-Besitzer wählen Funktionen beim Erstellen oder Bearbeiten eines persönlichen Tokens; Superadministratoren machen dasselbe für Systemtokens. Durch die Bearbeitung wird das Geheimnis weder offengelegt noch rotiert. Ein persönliches Token-Formular zeigt nur Funktionen an, die die aktuelle Rolle des Besitzers delegieren kann, und bei jeder Anfrage wird diese aktive Rolle erneut überprüft. Discovery stellt die effektiven Funktionen bereit, ohne den Token-Wert, den Token-Hash oder die Token-Vorschau zurückzugeben. Standard-Token zur Seitenerstellung nutzen diese Funktionen:

• content.read
• content.validate
• content.apply
• navigation.write
• shared-slots.write
• media.read
• site-settings.write

Aerweiterte Funktionen sind separate Optionen und nicht standardmäßig ausgewählt:

• navigation.delete
• shared-slots.delete
• domains.write
• domains.delete
• site-assets.read
• site-assets.write
• engagement.read
• engagement.moderate
• plugins.read
• plugins.install
• plugins.manage
• plugins.setup
• plugins.uninstall
• commerce.read
• commerce.products.write
• commerce.orders.read
• media.write
• media.upload
• media.replace
• media.move
• media.delete
• content.publish
• pages.delete
• content.blocks.delete
• backups.create
• page-assets.write

Schreibendpunkte prüfen die relevanten Fähigkeiten serverseitig. Fehlende Funktionen geben JSON zurück403mitapi_discovery_url,openapi_url,documentation_url, Undexample_urlAnleitung. Normale Seitenerstellungs-Tokens sollten keine destruktiven Funktionen wie Navigationslöschung, Shared Slot-Löschen, Inhaltsveröffentlichung, Plugin-Installation/-Verwaltung/Einrichtung/Deinstallation oder Seitenlöschung enthalten. Das Lesen von Kommentaren/Bewertungsfeedback erfordert eine explizite Angabeengagement.read; Das Ändern des Kommentarstatus erfordert eine explizite Angabeengagement.moderate. Für die Automatisierung des Plugin-Lebenszyklus sind explizite Plugin-Funktionen erforderlich, und für den WebBlocks Commerce-Produkt-/Bestellzugriff sind explizite Commerce-Funktionen für den API-Zugriff erforderlich.

Jede /webadmin/api-Route und die alten /admin-api-Routen teilen sich zwei Anforderungsbudgets. Das Budget pro Client-IP und Token beträgt standardmäßig 120 Anfragen pro Minute (CMS_INTERNAL_API_RATE_LIMIT_PER_MINUTE). Ein unabhängiger IP-Backstop ist standardmäßig auf 300 Anfragen pro Minute für alle bereitgestellten Token und API-Pfade (CMS_INTERNAL_API_IP_RATE_LIMIT_PER_MINUTE) eingestellt, einschließlich Versuchen mit ungültigen Token. Durch das Rotieren von Token wird diese Rücklaufsperre nicht zurückgesetzt. Bei Überschreitung eines der beiden Budgets wird 429 mit einem Retry-After-Header zurückgegeben. Nichtpositive Konfigurationswerte fallen auf die Standardwerte zurück.

Live-Budgets von x-rate-limit auf GET /webadmin/api/openapi.json lesen: requests_per_minute ist das Token-und-IP-Budget und ip_requests_per_minute ist das unabhängige IP-Budget. Clients, die eine IP teilen, müssen ihr kombiniertes Anfragevolumen koordinieren.

An aktiver Superadministrator kann beide Budgets unter System → Einstellungen → Sicherheit überschreiben. Datenbankgestützte Panelwerte haben Vorrang vor der Installationskonfiguration und gelten für nachfolgende Anforderungen, ohne dass vorhandene Zähler zurückgesetzt werden. Installationsstandardwerte verwenden entfernt die Sicherheitsüberschreibungen und stellt die konfigurierten Budgets wieder her. Durch das Speichern oder Wiederherstellen werden weder .env noch die Servereinstellungen bearbeitet. Anforderungsbudgets akzeptieren positive ganze Zahlen bis zu 1.000.000. Persönliche Token-spezifische Limits bleiben zusätzliche Limits; Durch deren Änderung werden diese gemeinsamen API-Budgets nicht geändert.

Hosting-, Proxy- oder CDN-Schichten vor der Site erzwingen möglicherweise eine niedrigere Grenze als das CMS, daher sollte ein Massenclient, wie z. B. ein vollständiger Site-Übersetzungsdurchlauf, sich selbst beschleunigen und bei 429 zurücktreten, anstatt es sofort erneut zu versuchen.

Persönliche Token haben zusätzlich eine konfigurierbare Obergrenze von 30, 60, 120 oder 300 Anfragen pro Minute; Vorhandene persönliche Token ohne gespeicherten Wert verwenden 60. Sie können auch den Zugriff auf genaue IPv4/IPv6-Adressen oder CIDR-Netzwerke einschränken. Die authentifizierte Erkennung meldet diese Einstellungen unter token.network_policy. Die aufgelöste Client-IP von Laravel ist maßgeblich, daher müssen Hosts hinter einem Reverse-Proxy oder CDN nur ihren echten Proxy-Adressen und weitergeleiteten Headern vertrauen, bevor sie sich auf die Zulassungsliste verlassen.

Die API hat zwei sich ergänzende Modi.

Ressourcen-Endpunkte spiegeln einzelne admin-äquivalente Operationen wider:

• Seiten auflisten und lesen
• Blöcke auflisten und lesen
• Sites, Sprachen (Locales), Layouts und Blocktypen auflisten
• später Entwurfsseiten-Ressourcen direkt erstellen oder aktualisieren
• später Seiten-Slots auflisten oder sicherstellen
• später Blöcke über Ressourcen-Endpunkte hinzufügen, aktualisieren, verschieben und löschen
• später Kind-Blöcke über Ressourcen-Endpunkte hinzufügen
• später Navigation und Shared Slots verwalten

Ressourcen-Endpunkte in Phase 1:

GET /webadmin/api/locale-options gibt den kuratierten Standardsprachen-Gebietsschemaauswahlkatalog als flache locale_options-Liste zurück. API-Tools sollten beim Erstellen eines normalen Sprachgebietsschemas ein zurückgegebenes locale_option wählen, anstatt die Zeichenfolgen code und name zu erfinden.

POST /webadmin/api/locales und PATCH /webadmin/api/locales/{locale} erfordern site-settings.write und akzeptieren nur sichere Gebietsschemafelder: locale_option, code, name, is_default und is_enabled. Durch das Senden von locale_option werden der kanonische Code und der englische Name aus dem Standardkatalog kopiert. Direkte code und name bleiben für kontrollierte Ländervarianten oder kundenspezifische/Betreiberfälle verfügbar. Das Festlegen von is_default=true erzwingt die Aktivierung des Gebietsschemas und stuft alle vorherigen Standardeinstellungen durch die normale CMS-Gebietsschema-Invariante herab. Migrationstools sollten eine vorhandene Gebietsschema-ID patchen, wenn ein Fehler bei der reinen Spracheinrichtung behoben wird, z. B. beim Ändern einer deutschen Neuinstallation mit einem einzelnen Gebietsschema von en in de, damit bestehende Seiten-, Block- und Site-Gebietsschemabeziehungen ihre IDs behalten.

Content-Validate-/-Apply-Endpunkte verarbeiten vollständige, mehrstufige Content-Pläne:

validate prüft einen vollständigen Content-Plan und schreibt nichts. apply validiert den Plan erneut und erstellt anschließend die angeforderte Entwurfsseite, Navigationselemente, Shared Slots, Shared-Slot-Blockbäume und Shared-Slot-Zuweisungen für Seiten-Slots in einer Transaktion. Es kann außerdem benannte seiteneigene Slots auf einer bestehenden Entwurfsseite ersetzen, wenn der Plan mode: replace_existing_draft_page verwendet und eine optimistische Sicherheitsprüfung enthält. Das ist nützlich für KI-generierte Seiten, Vorlagen, Starterseiten, gemeinsame Header/Footer und Migrationshelfer, bei denen das CMS halb erstellte Inhalte vermeiden soll.

Der Request-Body darf weiterhin ein Feld plan oder eine andere strukturierte Content-Plan-Payload enthalten. Die URL sollte /content/validate und /content/apply bleiben.

Beide Modi werden benötigt:

• die Ressourcen-API stellt internen Tools das bestehende CMS-Content-Modell samt Verträgen bereit
• die Content-Validate-/-Apply-API vermeidet partielle Schreibvorgänge bei größeren Seitenaufbauten

POST /content/apply akzeptiert ein optionales create_restore_point: true-Flag der obersten Ebene. Wenn dies festgelegt ist, erstellt das CMS eine vollständige Systemsicherung (Datenbank plus Uploads) als Wiederherstellungspunkt , bevor den Plan anwendet, sodass ein Bediener ein Rollback von System -> Backups durchführen kann, wenn eine von der KI generierte Anwendung fehlschlägt.

Rules:

• es erfordert die engagiertebackups.createFähigkeit, die nicht Teil des standardmäßigen Seitenerstellungssatzes ist; Ohne diese Angabe gibt die Anfrage JSON zurück403
• Der Plan wird zuerst validiert, sodass ein ungültiger Plan zurückgegeben wird422ohne ein unnötiges Backup zu erstellen
• Wenn die Sicherung nicht erstellt werden kann, wird die Anwendung abgebrochen und gibt JSON zurück409; Inhalte werden niemals ohne das erforderliche Sicherheitsnetz angewendet
• Bei Erfolg enthält die Apply-Antwort arestore_pointObjekt mit dem Backupid,type(content_apply),label,status, Undcreated_at
• Das Backup ist vollständig und synchron, sodass es zu spürbarer Latenz kommt. Verwenden Sie es für große oder zerstörerische Anwendungen, nicht für Hochfrequenzautomatisierung

API macht absichtlich nur die Erstellung von Wiederherstellungspunkten verfügbar. Das Wiederherstellen, Herunterladen und Löschen von Backups bleibt in der Admin-Benutzeroberfläche des Operators und ist nicht Teil des Tokens API.

Diese Endpunkte erfordern jeweils plugins.read, plugins.install, plugins.manage, plugins.setup bzw. plugins.uninstall. Sie arbeiten mit Bearer-Authentifizierung und erfordern keine authentifizierte Browsersitzung. Der manuelle Installationsendpunkt akzeptiert ein validiertes Plugin-ZIP-Artefakt. Kataloglisten-/Detailanfragen erfordern plugins.read; Für die Installation und Aktualisierung des Katalogs sind plugins.install und die Wiederverwendung des CMS-Katalog-Clients, der Kompatibilitätsprüfungen, der Artefaktgröße/ZIP-Validierung und der SHA-256-Überprüfung erforderlich. Eine Katalogaktualisierung muss neuer als die installierte Version sein und stellt den vorherigen aktivierten Status des Plugins erst wieder her, nachdem die Startvalidierung und die Datenbankeinrichtung erfolgreich waren. Bei beiden Installationspfaden bleibt ein neu installiertes Plugin standardmäßig deaktiviert. Seit CMS 1.92.0 werden bei Installation, Updates und Aktivierung die erforderlichen Plugin-Datenbankänderungen automatisch angewendet. Bei einem fehlgeschlagenen Setup bleibt das Plugin mit einer expliziten Wiederholungsaktion deaktiviert. Panel/API aktiviert und richtet die Ablehnung inkompatibler Plugins mit HTTP 409 und plugin_incompatible ein, bevor der Status geändert wird. CMS 1.94.0 fügt eine obligatorische isolierte Startprüfung, beibehaltene Pakete, Laufzeitquarantäne und /webadmin/plugin-recovery hinzu; Informationen zu den Wiederherstellungsbedingungen finden Sie unter Plugin System. Die Deinstallation ist auf deaktivierte, manuell hochgeladene Plugins beschränkt und behält Plugin-eigene Tabellen bei.

Wenn WebBlocks Commerce aktiviert und einrichtungsbereit ist, können vertrauenswürdige Tools Produkte erstellen/auflisten und Bestellungen lesen:

Commerce-Produktlesevorgänge erfordern commerce.read, Produktschreibvorgänge erfordern commerce.products.write und Bestelllesevorgänge erfordern commerce.orders.read. Wenn das Plugin deaktiviert ist oder Setup-Migrationen nicht ausgeführt wurden, geben Commerce-Endpunkte JSON 409 mit Setup-Anleitung anstelle eines Rohdatenbankfehlers zurück.

Der Plugin-eigene Block webblocks-commerce-buy-button ist von GET /webadmin/api/block-types und GET /webadmin/api/content-contract nur erkennbar, wenn das Plugin aktiviert ist. Seine Einstellungen erfordern settings.commerce_product_id von GET /webadmin/api/commerce/products; „Validieren/Anwenden“ lehnt fehlende, unbekannte oder inaktive Produkt-IDs ab. Der Checkout erfolgt weiterhin über den öffentlichen Commerce/PayPal-Flow. Das CMS API erstellt Produkte und Seitenblöcke, sammelt jedoch keine Kartendaten und startet keinen Karteneingabefluss.

Verwenden Sie die Inhaltsvalidierung/-anwendung, um eine vollständige Seite in einer Transaktion zu erstellen. Für inkrementelle Entwurfsänderungen verwenden Sie die Seitenblocktopologie API, um einzelne seiteneigene Blöcke hinzuzufügen, neu anzuordnen oder zu löschen. Verwenden Sie den Aktualisierungsendpunkt für vorhandene Blöcke nur, wenn der Block bereits vorhanden ist und die Änderung einem sicheren nativen Feld zugeordnet ist:

Der Endpunkt erfordert content.apply. Wenn der Block Teil eines Shared Slot-Quellbaums ist, muss das Token auch shared-slots.write.

enthalten

Unterstützte Felder sind absichtlich schmal:

• media_idoderasset_idfürnavbar-brandUndsidebar-brandLogo-Medien
• media_idoderasset_idfürhero,section,card,cta, Undcontent_headerHintergrundmedien
• settings.url
• settings.target
• settings.aria_label
• settings.background_position
• settings.background_overlay
• settings.show_searchfürheader-actions
• settings.show_mode_togglefürheader-actions
• settings.show_accent_togglefürheader-actions
• settings.show_language_switcherfürheader-actions
• Textübersetzungen wie ztitleUndsubtitle
• Bildblockübersetzungen durchtranslations.image.alt_text,translations.image.caption, oder die Kurzschrifttranslations.alt_textUndtranslations.caption
• Bildergalerie-Viewer-Gruppierung durchsettings.viewer_enabledund ein Kleinbuchstabesettings.viewer_group; Aktivierte, nicht verknüpfte Bildblöcke, die eine Gruppe teilen, werden in einem vorhandenen CMS-Galerie-Viewer gerendert, bleiben aber unabhängig positioniert
• Kontaktformular-Übersetzungen durchtranslations.contact_form.submit_labelUndtranslations.contact_form.success_message, oder die gleichen Namen wie Kurzschrift, danebentitleUndcontent
• url
• variant

Übersetzte Felder werden in die Übersetzungsfamilie geschrieben, zu der der Blocktyp gehört, für das Gebietsschema in der Anforderung (das Site-Standardgebietsschema, wenn locale weggelassen wird):

A, das der Familie nicht gehört, wird mit 422 und dem Code unsupported_block_translation_fields abgelehnt, und ein Blocktyp ohne Übersetzungsfamilie lehnt translations direkt mit unsupported_block_translations ab – keines von beiden wird in die Texttabelle geschrieben, wo es nichts lesen würde. Ein Gebietsschema, das die Site des Blocks nicht aktiviert hat, wird mit invalid_block_translation_locale abgelehnt. Gespeicherte Zeilen werden unter block.translations zurückgegeben, kodiert nach „family.

“.

Für Bildblöcke löscht eine explizit leere Zeichenfolge oder null den caption oder alt_text des ausgewählten Gebietsschemas; Die Aliase title und subtitle weisen dasselbe Verhalten auf. Ausgelassene Felder behalten ihre gespeicherten Werte. Durch das Löschen redaktioneller Bildtexte bleiben andere Sprachen, Medienverweise und dynamische Bindungen erhalten. Eine leere redaktionelle Bildunterschrift erzeugt keine Bildunterschrift, es sei denn, eine dynamische Bindung liefert eine solche; Der bestehende Media/Dynamic-Source-Fallback für Alternativtext bleibt in Kraft.

A submit_label und success_message des Kontaktformulars sind Übersetzungen, keine Einstellungen: Sie sind die einzige Möglichkeit, die Schaltfläche und den Bestätigungstext des Formulars zu lokalisieren, und sie können nicht über settings.

festgelegt werden

Der Endpunkt lehnt Topologie- und Datenbankimplementierungsfelder wie parent_id, slot_type_id, block_type_id, type, sort_order und children ab. Außerdem werden rohe HTML-URLs, Remote-Medien-URLs und Quell-URLs abgelehnt. Vorhandene Medien können aus der CMS-Medienbibliothek ausgewählt werden, aber dieser API importiert oder lädt keine neuen Remote-Medien herunter.

Beispiel:

Für einen vorhandenen Bildblock aktualisieren Sie die Bildübersetzungszeile im Besitz des Gebietsschemas mit:

Für die inkrementelle Bearbeitung von Entwurfsseiten kann die seiteneigene Blocktopologie jeweils einzeln geändert werden, ohne dass ein vollständiger Inhaltsplan gesendet werden muss:

{slot} ist ein seiteneigener Slot-Slug. Diese Endpunkte sind absichtlich entwurfssicher und schmal:

• Sie funktionieren nur auf Entwurfsseiten. Eine Nicht-Entwurfsseite gibt JSON zurück409mit Codepage_not_draft. Verwenden Sie gestaffelte Inhaltsaktualisierungen für veröffentlichte Seiten.
• Sie funktionieren nur auf seiteneigenen Slots. Ein von Shared Slot unterstützter Steckplatz gibt JSON zurück422. Verwenden Sie die Shared Slot-Endpunkte für Shared Slot-Inhalte.
• Ein unbekannter Seitenslot gibt JSON zurück404.

POST .../blocks fügt einen Block unter Verwendung derselben normalisierten Blocknutzlast wie der Inhalt hinzu (type, settings, translations und verschachtelter children). Neue Blöcke werden mit dem Status draft erstellt und am Ende des Steckplatzes angehängt. Übergeben Sie parent_id, um es unter einen vorhandenen Containerblock im selben Slot anzuhängen. Die Eltern müssen Kinder akzeptieren. Für das Erstellen und Neuanordnen ist content.apply.

erforderlich

PATCH .../blocks/reorder nummeriert eine Geschwistergruppe neu. Das blocks-Array muss jede Geschwister-ID für eine einzelne übergeordnete Gruppe genau einmal in der gewünschten Reihenfolge enthalten; Das übergeordnete Element wird aus den übermittelten Blöcken abgeleitet. Das Senden einer Teilgruppe gibt JSON 422.

zurück

DELETE .../blocks/{block} entfernt den Block und seinen gesamten Unterbaum und gibt deleted_blocks_count zurück. Zum Löschen ist die dedizierte content.blocks.delete-Funktion erforderlich, die nicht Teil der standardmäßigen Seitenerstellungsfunktionen ist. Shared Slot Quellblöcke können über diesen Endpunkt nicht gelöscht werden.

Jeder Schreibvorgang erfasst eine Seitenrevision, sodass Entwurfsänderungen reversibel bleiben.

hero und cta sind gewöhnliche Container, deren Aktionsschaltflächen einfache button_link-Kinder sind – deklarieren Sie sie wie jeden anderen verschachtelten Block unter children. Zwei optionale Blockfelder bleiben als Abkürzung für den üblichen Ein- oder Zwei-Tasten-Fall übrig:

Bide Felder akzeptieren ein Objekt mit einem erforderlichen label und einem erforderlichen url oder null, um die Aktion nicht festgelegt zu lassen. URLs müssen ein sicherer interner Pfad oder eine http(s)-URL sein. Die Kurzschrift schreibt die ersten beiden untergeordneten Elemente button_link, sodass das Ergebnis nicht von Schaltflächen zu unterscheiden ist, die ein Editor von Hand hinzufügt. Die explizite Deklaration der untergeordneten Elemente ist die kanonische Form und die einzige Möglichkeit, mehr als zwei Schaltflächen zu erstellen. Das Senden von primary_cta oder secondary_cta an einen anderen Blocktyp wird abgelehnt.

Die Felder funktionieren überall dort, wo eine Blocknutzlast akzeptiert wird: Inhaltsvalidierung/Pläne anwenden, POST /pages/{page}/slots/{slot}/blocks und POST /shared-slots/{sharedSlot}/blocks.

Seitenwiederherstellung verwendet einen Arbeitsablauf „Inspizieren, Vorschau und Anwenden“. Es gibt keinen direkten Wiederherstellungsendpunkt.

• GET /webadmin/api/pages/{page}/versions listet gespeicherte Versionen mit ihrem Seitenstatus, Prüffeldern und einer Zusammenfassung der Änderungen gegenüber der Vorgängerversion auf. GET .../versions/{version} gibt das vollständige Vergleichs- und Referenzzustandsergebnis zurück. Beide erfordern content.read.
• POST .../versions/{version}/candidate erfordert content.apply. Es erstellt aus dem Snapshot einen privaten Entwurfskandidaten und gibt seine Browser-Vorschau-URL zurück. Die Quellseite wird nicht geändert.
• POST .../version-candidates/{candidate}/apply erfordert sowohl content.apply als auch content.publish. Die Bewerbung wird mit JSON 409 und dem Code restore_candidate_stale abgelehnt, wenn sich die Quellseite nach der Vorbereitung des Kandidaten geändert hat. Bei einer erfolgreichen Anwendung werden die normalen Sicherheitsversionen vor und nach der Wiederherstellung erstellt und der technische Entwurf entfernt.
• DELETE .../version-candidates/{candidate} erfordert content.apply; Es entfernt den Kandidaten, ohne die Quellseite zu ändern.

Kandidaten werden bei der normalen Seitenerkennung und beim Site-Export bewusst nicht berücksichtigt. Tools sollten immer die Version prüfen, einen Kandidaten vorbereiten, dessen preview_url rendern oder öffnen und erst dann apply_url nach ausdrücklicher Genehmigung des Bedieners aufrufen.

GET /webadmin/api/pages/{page}/render erfordert content.read und gibt die gerenderte Seite genau so zurück, wie die Browser-Administratorvorschau sie rendert: Entwurfsblöcke enthalten, X-Robots-Tag: noindex, nofollow, und niemals über die öffentliche Route, sodass nichts darüber veröffentlicht wird.

Fügen Sie ?format=html für das Markup selbst anstelle des JSON-Umschlags und ?locale=de hinzu, um eine bestimmte Übersetzung zu rendern. Der Standardwert ist das Standardgebietsschema der Site. Ein Gebietsschema, für das die Seite keine Übersetzung hat, gibt 422 mit page_translation_missing und den Gebietsschemas zurück, über die es verfügt. Shared Slot-Quellseiten bearbeiten Gerüste und geben 422 mit page_not_renderable zurück, was dem eigenen 404-Fehler des Browser-Administrators entspricht.

Rendering war bereits erreichbar, bevor dieser Endpunkt existierte: GET /webadmin/pages/{page}/preview akzeptiert ein Bearer-Token mit content.read sowie eine Admin-Sitzung und tut dies auch weiterhin. Der API fügt einen JSON-Umschlag und Discovery-/OpenAPI-Links hinzu. Die Browservorschau akzeptiert auch einen locale-Code: Die Sprache muss für die Site aktiviert sein und über eine Seitenübersetzung verfügen. Wenn Sie es weglassen, bleibt die Standardsprache erhalten. Beide Vorschauen übergeben die ausgewählte Sprache, um das Rendern zu blockieren; Inhalte werden weder gespeichert noch veröffentlicht.

In jedem Fall muss gerendert werden, bevor eine Seite als beendet gemeldet wird. Content Apply gibt an, was gespeichert wurde, was nicht dasselbe ist wie das, was gerendert wird: ein Wrapper-Block ohne untergeordnete Elemente, ein Slot, der dem falschen Shared Slot zugewiesen ist, oder ein Layout ohne die Slots, von denen der Plan angenommen hat, dass sie alle sauber gelten und trotzdem eine Seite erzeugen, die niemand will.

Seitenübersetzungen besitzen eine lokalisierte Seitenidentität und die SEO- und Open Graph-Überschreibungen auf Seitenebene. Content Apply schreibt beim Erstellen einer Seite eine Übersetzungszeile für ein Gebietsschema. Anhand dieser Endpunkte wird diese Zeile zurückgelesen und anschließend geändert.

GET /webadmin/api/pages/{page}/translations listet jede Übersetzung auf einer Seite mit name, slug, path, seo_title, seo_description, seo_keywords, list_excerpt auf. og_title, og_description und og_image_media_id. list_excerpt ist der Satz pro Gebietsschema, der in einem Seitenlistenblock unter dem Titel dieser Seite auf einer Listenkarte angezeigt wird. Es ist auf 300 Zeichen begrenzt und greift auf die SEO-Beschreibung zurück, wenn es leer ist. Die gleichen Felder erscheinen jetzt in jeder Übersetzung in GET /webadmin/api/pages/{page}.

POST /webadmin/api/pages/{page}/translations/{locale} erfordert content.apply und fügt eine Übersetzung für ein Gebietsschema hinzu, das bereits für die Seitensite aktiviert ist. Das Segment {locale} akzeptiert einen Gebietsschemacode oder eine numerische ID. Es ist nur name erforderlich: Lassen Sie slug und path weg und beide werden vom Namen abgeleitet, genau so, wie der Browser-Administrator sie ableitet. Das Erstellen einer Übersetzung für ein Gebietsschema, über das die Seite bereits verfügt, gibt 422 mit dem Code page_translation_exists.

zurück

PATCH /webadmin/api/pages/{page}/translations/{translation} erfordert content.apply und schreibt nur die Felder, die die Anforderung trägt, sodass ein Tool seo_description festlegen kann, ohne die Seitenidentität erneut zu senden. Senden Sie null, um ein optionales Feld zu löschen.

Slug und Pfad bewegen sich immer zusammen. Durch das Senden von path wird der Slug aus seinem letzten Segment neu abgeleitet. Allein durch das Senden von slug wird die Seite nach /{slug} verschoben. Pfade werden kanonisiert, anhand reservierter CMS- und Host-Routen überprüft und müssen für die Site und das Gebietsschema eindeutig bleiben. Da Titel und Slug von Page bis zur Standardübersetzung vorgelesen werden, wird beim Umbenennen dieser Übersetzung die Seite selbst umbenannt.

Felder außerhalb der lokalisierten Identität und SEO werden mit 422 und dem Code unsupported_page_translation_fields abgelehnt, der sie in blocked_fields benennt. Seitenstatus, Layout und Blockinhalt haben ihre eigenen Endpunkte.

Seiten können ihre eigenen laden/site/...CSS- und JS-Dateien zusätzlich zu den standortweiten Assets:

{type} ist css oder js. Die Auflistung ist für jeden gültigen Token verfügbar; Für die Schreibendpunkte ist die dedizierte Opt-in-Funktion page-assets.write erforderlich, die nicht Teil des standardmäßigen Seitenerstellungssatzes

ist

Der path-Vertrag ist bewusst eng gefasst und stellt die Sicherheitsgrenze für diesen API:

dar

• Es muss ein lokaler Pfad sein, beginnend mit/site/und endet in.cssoder.jspassend zum Asset-Typ
• externe URLs (http://,https://), protokollrelativ (//),javascript:, Unddata:Pfade werden abgelehnt
• Verzeichnisdurchlauf, Backslashes, Abfragezeichenfolgen und Fragmente werden abgelehnt

Nur dieser Endpunkt fügt eine vorhandene Datei an eine Seite an; Es schreibt niemals Dateiinhalte. Schreiben Sie die Datei selbst mit den Site-Assets API (PUT /webadmin/api/sites/{site}/assets/{type}, was site-assets.write erfordert) oder über die Admin-UI.

Unterstützte Felder sind path (erforderlich beim Erstellen), sort_order, is_enabled und – nur für JS-Assets – is_defer, is_async und is_module. load_position wird vom Typ (head für CSS, body_end für JS) abgeleitet und passt zum Admin-Editor. Der Typ css/js ist bei der Aktualisierung unveränderlich; löschen und erneut hinzufügen, um es zu ändern.

Im Gegensatz zu den Endpunkten der Seitenblocktopologie sind Seitenressourcen nicht nur für Entwürfe gedacht: Sie können auf jeder Seite entsprechend der Registerkarte „Seitenressourcen“ des Administrators geändert werden. Jeder Schreibvorgang erfasst eine Seitenrevision.

Shared Slot Blockbäume haben ihre eigenen Topologie-Endpunkte, da sie auf jeder Seite gemeinsam genutzt werden, der der Slot zugewiesen ist:

Das Hinzufügen von Blöcken bleibt bei POST /shared-slots/{sharedSlot}/blocks und das Bearbeiten der sicheren Inhaltsfelder eines einzelnen Blocks bleibt bei PATCH /blocks/{block} (das bereits Shared Slot-Quellblöcke mit shared-slots.write akzeptiert). Die neuen Endpunkte fügen die fehlenden Topologieoperationen hinzu:

• PATCH .../blocks/reorder nummeriert eine Geschwistergruppe neu; Das blocks-Array muss jede Geschwister-ID für eine einzelne übergeordnete Gruppe genau einmal in der gewünschten Reihenfolge enthalten. Es ist erforderlich, dass shared-slots.write.
• DELETE .../blocks/{block} einen Block und seinen Teilbaum entfernt und zurückgibt. deleted_blocks_count.
• DELETE .../blocks löscht jeden Block im Steckplatz, sodass ein Werkzeug einen löschen und ersetzen kann Shared Slot; Es wird deleted_blocks_count.
• Beide Löschvorgänge erfordern shared-slots.write plus die dedizierte content.blocks.delete-Funktion.

Im Gegensatz zu Seitenblockbearbeitungen sind diese nicht nur auf Entwürfe beschränkt: Shared Slots haben kein Konzept für Entwurfsseiten. Das Neuanordnen oder Löschen eines bereits veröffentlichten Shared Slot-Blocks wirkt sich daher sofort auf jede zugewiesene Seite aus, weshalb das Löschen hinter der destruktiven content.blocks.delete-Fähigkeit erfolgt. Bei jedem Schreibvorgang werden die Seitenzuweisungen des Slots neu erstellt und eine Shared Slot-Revision erfasst, sodass Änderungen reversibel bleiben.

Aneben branding, head, timezone und public-theme sind drei weitere Site-Felder beschreibbar. Alle drei erfordern site-settings.write.

PATCH /webadmin/api/sites/{site}/seo schreibt seo_title, seo_description und seo_keywords: die Site-weiten Fallback-Metadaten, die eine öffentliche Seite erbt, wenn ihre eigene Seitenübersetzung keine Überschreibung enthält. Teilweise, und null löscht ein Feld. Überschreibungen auf Seitenebene gehören zur Seitenübersetzung. siehe die Seitenübersetzung API oben.

PATCH /webadmin/api/sites/{site}/contact-recipient schreibt contact_recipient_email, die Adresse, an die Kontaktformulareinsendungen gesendet werden. Senden Sie einen leeren Wert, um auf den Systemempfänger zurückzugreifen. Ein über API zusammengestelltes Kontaktformular hat erst dann einen Sinn, wenn dieser festgelegt ist.

PUT /webadmin/api/sites/{site}/locales ersetzt den Gebietsschemasatz der Site von locale_ids. Das Standardgebietsschema wird immer beibehalten, genau wie das Admin-Formular es behält, und Gebietsschemas müssen zuerst global über POST/PATCH /webadmin/api/locales aktiviert werden. Eine Seitenübersetzung kann nicht für ein Gebietsschema gespeichert werden, das die Site nicht aktiviert hat. Daher ist dies der Endpunkt, der ein neues Gebietsschema auf einer Site nutzbar macht.

Dieser Endpunkt ist in einer Hinsicht strenger als das Admin-Formular: Er weigert sich, ein Gebietsschema zu trennen, das noch Seitenübersetzungen auf der Site hat, und 422 benennt das Gebietsschema und die Anzahl. Das Formular ermöglicht es einem Bediener, dies wissentlich zu tun; Ein unbeaufsichtigtes Tool würde den Inhalt stillschweigend verwaisten.

Domain-Einträge entscheiden, welcher Hostname zu welcher Site aufgelöst wird, sodass der Browser-Administrator sie hinter dem Zugriff auf Systemebene behält. Die API-Endpunkte sind:

• PATCH /webadmin/api/sites/{site}/seo
• PATCH /webadmin/api/sites/{site}/contact-recipient
• PUT /webadmin/api/sites/{site}/locales
• GET /webadmin/api/sites/{site}/domains erfordert content.read
• POST /webadmin/api/sites/{site}/domains erfordert domains.write
• PUT /webadmin/api/sites/{site}/domains/{domain} erfordert domains.write
• POST /webadmin/api/sites/{site}/domains/{domain}/primary erfordert domains.write
• DELETE /webadmin/api/sites/{site}/domains/{domain} erfordert das destruktive domains.delete
• GET /webadmin/api/domains/{domain}/status erfordert content.read

Diese Endpunkte lebten zuvor nur unter einem /admin-api-Präfix und überprüften nichts über die Token-Gültigkeit hinaus, sodass jedes Token überhaupt eine Domäne hinzufügen oder entfernen konnte. Sie befinden sich jetzt unter /webadmin/api mit dem Rest von API und jede Route verfügt über eine Funktion. Das Präfix /admin-api funktioniert weiterhin für vorhandene Bereitstellungstools, mit denselben Leistungsanforderungen und einer zusätzlichen Route, GET /admin-api/sites; Neue Integrationen sollten /webadmin/api verwenden, dessen Pfade auch von der CSRF-Ausnahme abgedeckt sind, die das Legacy-Präfix nie hatte.

PATCH /webadmin/api/shared-slots/{sharedSlot} erfordert shared-slots.write und ändert den Shared Slot selbst und nicht seine Blöcke: label, handle, slot, layout und is_active. Es werden nur die vorhandenen Felder geschrieben. Handles bleiben pro Site eindeutig, der Slot-Name muss in einen veröffentlichten Slot-Typ aufgelöst werden und die Shared Slot-Quellseite und ihre Zuweisungen werden anschließend genau so neu erstellt, wie der Browser-Administrator sie neu erstellt. Eine Metadaten- oder Statusänderung erfasst eine Shared Slot-Revision.

Das Verschieben eines Shared Slot auf eine andere Site wird hier nicht unterstützt und mit 422 und dem Code unsupported_shared_slot_fields abgelehnt, der auch alle anderen Felder außerhalb dieses Satzes abdeckt. Site-übergreifende Verschiebungen bleiben zusammen mit den anderen Site-Übertragungsvorgängen im Browser-Administratorbereich.

DELETE /webadmin/api/shared-slots/{sharedSlot} erfordert die destruktive Funktion shared-slots.delete und wendet denselben Schutz an wie der Browser-Administrator: Ein Shared Slot, auf den noch immer von einem Seitenbereich verwiesen wird, wird niemals gelöscht. Die 422-Antwort enthält den Code shared_slot_in_use und ein usage-Array, das die referenzierenden Seitenslots benennt, sodass ein Tool sie zuerst mit PUT /webadmin/api/pages/{page}/slots/{slot}/source trennen kann. Wenn die Shared Slot-Referenzspalten noch nicht migriert wurden, gibt der Endpunkt 409 mit shared_slots_not_ready anstelle von „guesing.

“ zurück

Die Medienbibliothek API ist absichtlich von allgemeinen Inhaltsberechtigungen getrennt, sodass KI-/Operator-Tools Medienerkennung oder Metadatenbereinigung gewährt werden können, ohne unabhängige Schreibrechte zu erhalten.

Funktionen:

• media.read: Vorhandene Datensätze der CMS-Medienbibliothek auflisten und prüfen.
• media.upload: Dateien in die Medienbibliothek hochladen.
• media.write: Sichere Metadaten für vorhandene Mediendatensätze aktualisieren.
• media.replace: Ersetzen Sie eine vorhandene Mediendatei unter Beibehaltung ihrer Medien-ID.
• media.move: Medien zwischen Ordnern verschieben oder den Ordner löschen.
• media.delete: Löschen Sie nicht verwendete Medien mit demselben Nutzungsschutz wie im Admin-Panel.

Phase-1-Bereich:

GET /webadmin/api/media gibt vorhandene Mediendatensätze mit sicheren Feldern wie ID, Art, Titel, Dateiname, Originalname, MIME-Typ, Sichtbarkeit, öffentliche URL (falls verfügbar), Alternativtext, Abmessungen, Vorschaufähigkeit und kompakte Metadatenbezeichnung zurück. Es erfordert media.read. Während des Übergangs von älteren API-Tokens wird content.read möglicherweise auch für die schreibgeschützte Medienerkennung akzeptiert, sodass bestehende Seitenerstellungsintegrationen weiterhin funktionieren.

GET /webadmin/api/media/folders listet Medienbibliotheksordner mit ihrer Medienanzahl auf, und POST /webadmin/api/media/folders erfordert media.write und erstellt einen aus name, optional mit slug und parent_id. Ein Name, der bereits unter demselben übergeordneten Ordner vorhanden ist, wird mit 422 und dem Code media_folder_exists abgelehnt, und die Antwort enthält den vorhandenen Ordner, sodass ein Wiederholungstool ihn wiederverwendet, anstatt Duplikate zu erstellen. Datei-Uploads in einen Ordner mit folder_id; Verschieben Sie vorhandene Medien mit POST /webadmin/api/media/{media}/move.

POST /webadmin/api/media erfordert media.upload und akzeptiert multipart/form-data-Uploads in die normale CMS-Medienbibliothek. Die hochgeladene Datei wird zu einer regulären media-Zeile und ist im Browser-Admin-Medienbildschirm und in der Medienauswahl sichtbar. Die Upload-Validierung spiegelt die zulässigen Dateitypen der Browser-Admin-Medienbibliothek wider: gängige Bilder, Videos, PDFs, Office-Dokumente, Text/CSV/RTF und ZIP-Dateien.

Unterstützte Metadatenfelder sind folder_id, title, alt_text, caption und description. Der Endpunkt gibt das erstellte Medienobjekt mit seiner ID und öffentlichen URL zurück, sofern verfügbar.

PATCH /webadmin/api/media/{media} erfordert media.write und aktualisiert nur sichere beschreibende Metadaten:

• title
• alt_text
• caption
• description

POST /webadmin/api/media/{media}/replace erfordert media.replace und ersetzt die gespeicherte Binärdatei unter Beibehaltung der Medien-ID und vorhandener Referenzen. Die Ersatzdatei muss in denselben Medientyp wie der vorhandene Datensatz aufgelöst werden, z. B. Bild-zu-Bild oder Dokument-zu-Dokument. Die Antwort enthält aktuelle Nutzungsdetails, sodass Tools erkennen können, ob sich die Ersetzung auf Blöcke, Website-Branding oder Seiten-SEO auswirkt.

POST /webadmin/api/media/{media}/move erfordert media.move und akzeptiert folder_id, einschließlich null zum Löschen der Ordnerzuweisung.

DELETE /webadmin/api/media/{media} erfordert media.delete und verwendet denselben Nutzungsschutz wie der Browser-Administrator. Medien, auf die durch Blöcke, Galerien, Anhänge, Website-Branding oder Seiten-SEO verwiesen wird, werden nicht gelöscht; Der API gibt stattdessen 422 mit Nutzungsdetails zurück.

Dieser API unterstützt Folgendes ausdrücklich nicht:

• Datenträger, Pfad, Dateiname, MIME-Typ, Art, Sichtbarkeit, Größe, Abmessungen, Uploader oder Nutzungsbeziehungen direkt ändern
• Remote-Medien-URLs abrufen oder importieren

Diese Grenze ermöglicht es KI-/Bediener-Tools, nur die Medienleistungen zu erhalten, die sie benötigen. Beispielsweise kann ein Seitenerstellungstoken Medien lesen und hochladen, ohne vorhandene Dateien löschen oder ersetzen zu können, während einem vertrauenswürdigen Wartungstoken explizit media.replace oder media.delete gewährt werden kann.

Das Ersetzen auf bestehenden Entwurfsseiten bleibt innerhalb des Validate-/Apply-Vertrags:

Verwenden Sie mode: replace_existing_draft_page, um einen oder mehrere seiteneigene Slots auf einer vorhandenen Entwurfsseite zu ersetzen. Der Vorgang erfordert content.validate zum Validieren und content.apply zum Anwenden. Es ist kein pages.delete erforderlich, da es sich nicht um einen allgemeinen Seitenlöschvorgang handelt.

Seitenübersetzung path ist die kanonische öffentliche URL. Neue Pläne sollten Pfade wie /contact, /features, /games/fruit-train oder /docs/internal-content-api verwenden; /p/... ist nur mit älteren Versionen kompatibel. Pfade mit Schrägstrichen werden Segment für Segment normalisiert, sodass /docs/internal-content-api/ zu /docs/internal-content-api wird und nicht in docsinternal-content-api reduziert wird. CMS leitet den Kurzseiten-Slug aus dem letzten Pfadsegment ab, daher speichert /games/fruit-train den Slug fruit-train und den Pfad /games/fruit-train. Reservierte Routenbereiche wie /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install und Host-Authentifizierungsrouten können nicht als öffentliche Seitenpfade erstellt werden.

Beispiel:

Regeln:

• die Zielseite muss den Status draft haben
• expected_path oder expected_updated_at ist erforderlich
• expected_path verwendet den kanonischen öffentlichen Seitenübersetzungspfad, keinen /p/...-Alt-Alias
• die Zielseite muss zur angeforderten Site gehören, und die Sprache (Locale) muss für diese Site aktiviert sein
• jeder Slot muss auf der Seite existieren und seiteneigene Blöcke verwenden
• Slots mit Shared-Slot-Anbindung werden abgelehnt statt geleert
• nur Blöcke in den benannten replace_slots werden entfernt
• alte Blöcke werden entfernt und neue Blöcke in einer Transaktion geschrieben
• Seitenrevisionen werden vor und nach dem Apply festgehalten
• es findet kein Veröffentlichen, kein Medienabruf/-import, kein breites Löschen und kein Leeren von Shared-Slot-Zuweisungen statt

Veröffentlichte Seiten können nicht direkt ersetzt werden. Für mit der Quelle verknüpfte Dokumentseiten oder andere Live-Seiten, die während der Vorbereitung von Inhaltsänderungen öffentlich bleiben müssen, verwenden Sie die gestaffelten Aktualisierungsmodi:

create_staged_update_for_published_page erstellt nur dann eine Entwurfs-Staging-Seite aus der veröffentlichten Quellseite, wenn diese Quellseite nicht bereits über einen aktiven Entwurf einer bereitgestellten Aktualisierung verfügt. Durch Wiederholen des Erstellungsaufrufs für dieselbe Quellseite wird der vorhandene aktive bereitgestellte Entwurf mit data.reused_staged_update=true zurückgegeben, anstatt eine weitere technische Seite zu erstellen. Die Quellseite bleibt unter ihrem bestehenden öffentlichen Pfad veröffentlicht. Die bereitgestellte Seite speichert settings.staged_update-Metadaten mit der Quellseiten-ID, dem Quellpfad, dem aktualisierten Zeitstempel der Quelle, dem Lebenszyklusstatus und den verwalteten Slots. Es verwendet einen internen Entwurfspfad wie /staged-updates/page-123/update-456, sodass es nicht mit dem kanonischen Quellpfad kollidiert und nicht öffentlich weitergeleitet wird. Die normale Admin-Vorschau-URL /webadmin/pages/{page}/preview kann die bereitgestellte Seite für authentifizierte Admin-Sitzungen oder CMS API Bearer-Tokens mit content.read.

rendern

replace_staged_page_update verwendet die Entwurfsersetzungsregeln für die bereitgestellte Entwurfsseite wieder. Verwenden Sie es für jede weitere Überarbeitung, nachdem ein gestaffelter Entwurf vorliegt. Es ersetzt nur seiteneigene Slots und lehnt Shared Slot-unterstützte Slots ab.

promote_staged_page_update wendet gestaffelte seiteneigene Slot-Inhalte in einer Transaktion wieder auf die veröffentlichte Quellseite an. Der Quellseitenpfad, der Status, das Layout, die Shared Slot-Zuweisungen und die Seiteneinstellungen bleiben erhalten, es sei denn, es wird ein zugelassenes source_sync-Update bereitgestellt. Gesponserte seiteneigene Blöcke werden als published geschrieben, sodass die öffentliche Seite den gesponserten Inhalt sofort widerspiegelt. Shared Slot-Inhalte werden niemals kaskadiert. Nachdem die Sicherheitsversionen der Quellseite vor/nach der Promotion erfasst wurden, wird die technisch bereitgestellte Seite in derselben Transaktion gelöscht; Eine fehlgeschlagene Beförderung lässt den Entwurf daher zur Korrektur zurück. Für „Promote“ ist die normale Routenfunktion content.apply und die erweiterte Funktion content.publish erforderlich.

Beim Aufgeben eines aktiven gestaffelten Entwurfs wird DELETE /webadmin/api/pages/{staged_page}/staged-update verwendet. Dieser schmale Verwerfungsendpunkt erfordert content.apply, akzeptiert nur eine Entwurfsseite mit aktiven Staged-Update-Metadaten und ändert niemals die veröffentlichte Quellseite oder ihre gespeicherten Versionen. Es wird vermieden, einem Seitenerstellungstool die umfassende pages.delete-Fähigkeit zu gewähren, nur um seinen eigenen technischen Entwurf zu bereinigen.

Wenn ein normalisierter Apply-Plan die Validierung besteht, aber bei transaktionalen Schreibvorgängen fehlschlägt, gibt API die normale Validierung JSON mit ok=false und einen Fehler bei plan.apply zurück. Die detaillierte Ausnahme wird in Anwendungsprotokollen aufgezeichnet; API-Antworten bleiben öffentlich sicher und enthalten keine Stack-Traces, Datenbankinterna, Token oder lokalen Pfade.

Beispiel für einen gestaffelten Workflow:

Ersetzen Sie dann den bereitgestellten Inhalt:

Heraufstufen nach Vorschau und ausdrücklicher Genehmigung:

Für diesen Workflow ist keine neue Schematabelle erforderlich. Aktive Metadaten des bereitgestellten Lebenszyklus verwenden die vorhandene Spalte Seite settings JSON. Hochgestufte technische Seiten werden nicht beibehalten, da Quellseitenversionen den Wiederherstellungspfad bereitstellen.

Installationen, die ein Upgrade von einer Version durchführen, bei der hochgestufte bereitgestellte Seiten archiviert wurden, können diese Legacy-Datensätze einmal in der Vorschau anzeigen und entfernen:

Der Befehl wählt nur archivierte Seiten aus, deren bereitgestellte Metadaten explizit type=published_page_update und state=promoted lauten. Aktive Entwürfe und gewöhnliche archivierte Seiten sind niemals Kandidaten.

Content-Pläne dürfen ein begrenztes, geheimnisfreies source_sync-Objekt für KI-/Operator-Doku-Sync-Workflows persistieren. Beliebige Seiteneinstellungen werden abgelehnt. Die akzeptierte Form ist:

Apply persistiert diese Metadaten in den Seiteneinstellungen, und die API-Antworten für Seitenliste und -detail geben dieselben freigegebenen source_sync-Felder für die spätere Zuordnung zurück. Fügen Sie keine Tokens, Umgebungswerte, absoluten lokalen/Server-Pfade oder anderen Geheimnisse ein.

Das Veröffentlichen ist von Content-Apply getrennt und erfordert ein Token mit content.publish.

POST /webadmin/api/pages/{page}/publish veröffentlicht den Seitendatensatz. Die Standard-Payload betrifft nur die Seite:

Rules:

• weggelasseninclude_page_owned_blocksverhält sich wiefalse
• include_page_owned_blocks: falseVeröffentlicht nur den Seitendatensatz und lässt Entwurfs- oder Überprüfungsblöcke unverändert
• include_page_owned_blocks: trueveröffentlicht Entwürfe und in Prüfung befindliche Blöcke, die den nicht freigegebenen Seitenslots der Seite gehören, einschließlich verschachtelter untergeordneter Blöcke
• bereits veröffentlichte Blöcke bleiben unverändert
• Von Shared Slot unterstützte Slots werden ausgeschlossen und in der Antwort gemeldet
• nicht unterstützte Shared Slot-Kaskadenfelder wie zpublish_shared_slots,include_shared_slot_blocks, odershared_slot_cascadeGeben Sie JSON zurück422
• Die Antwort enthält Seiten-ID/Status/Pfad-Metadaten, ob seiteneigene Blöcke enthalten waren, die veröffentlichte Anzahl, ausgeschlossene Shared Slot-Zusammenfassungen und die Seitenrevisions-ID

POST /webadmin/api/pages/{page}/publish-page-owned-blocks veröffentlicht nur unveröffentlichte seiteneigene Blöcke und ändert den Seiten-Workflow-Status nicht. Es verwendet dieselbe content.publish-Funktion und dieselbe Shared Slot-Ausschlussregel.

POST /webadmin/api/pages/{page}/archive entfernt die Seite von der öffentlichen Website: Archivierte Seiten geben 404 an Besucher zurück und ihre mit der Seite verknüpften Menüelemente werden nicht mehr in öffentlichen Menüs angezeigt. Es verwendet die gleiche content.publish-Funktion und spiegelt die Administrator-Workflow-Regeln wider: Erlaubt von in_review und published, eine Entwurfsseite gibt JSON 422 zurück, das erneute Archivieren einer archivierten Seite ist kein Erfolg und gestaffelte Aktualisierungsseiten werden abgelehnt (stattdessen hochstufen oder löschen). Die Antwort enthält die Seitenmetadaten from_status und die erfasste Seitenrevisions-ID. Durch erneutes Veröffentlichen der Seite wird das Archiv rückgängig gemacht.

I/Operator-Tools dürfen nicht davon ausgehen, dass die Seitenveröffentlichung alle Blockinhalte öffentlich macht. Verwenden Sie include_page_owned_blocks: true nur, wenn der Benutzer der Veröffentlichung aller unveröffentlichten seiteneigenen Blöcke für diese Seite ausdrücklich zugestimmt hat. Shared Slot-Inhalte müssen separat geprüft und veröffentlicht werden.

GET /webadmin/api/content-contract ist ein schreibgeschützter Erkennungsendpunkt für vertrauenswürdige KI-/Operator-Tools. Es gibt das Präfix API, URLs zum Validieren/Anwenden, eine URL-Vorlage für die Admin-Vorschau, Sicherheitsflags, Erkennungs-URLs, empfohlene Seitenerstellungsmuster, einen maschinenlesbaren Entwurfsrichtungsvertrag und bereinigte Blockvertragsmetadaten zurück.

Vor der Auswahl eines Blockbaums müssen die Tools design_direction lesen und jeweils einen Wert für character, density, typography, geometry, imagery, corners auswählen. contrast und framing und erklären Sie, wie die Kompositionszuordnung diese Auswahlmöglichkeiten umsetzt. Hierbei handelt es sich eher um einen Planungsvertrag als um einen versteckten Content Store: Das Ergebnis wird durch native Blockeinstellungen, öffentliche Theme-Tokens und eine stabile Site CSS ausgedrückt. Seine Zusammensetzungsrichtlinie macht Spalten standardmäßig für neue API-Pläne einfach, behält die Opt-In-Funktion für Karten bei und erfordert eine Inhaltsgrenzen-/Aktionsbegründung für jede Kartensammlung. Eine Quelle, die drei kurze Elemente enthält, ist keine solche Begründung.

framing ist eine Planungsdimension, keine persistenten Seitendaten. Wählen Sie je nach Inhalt und Kontext open, restrained, framed oder dense-ui. Verwenden Sie eine Karte oder ein umrandetes Feld nicht nur zum Organisieren eines Abschnitts. Das Framing muss semantische Unabhängigkeit, Interaktion oder Entitätsgrenzen kommunizieren. Äußere Hero-Container, Feature-/Prinzipgruppen, Abschnittswrapper, Navigations-/Fußzeilenspalten, CTA-Bänder, dekorative Statistiken und redaktionelle Aufteilungen sind standardmäßig ohne Rahmen. Bevorzugen Sie Leerraum, Typografiehierarchie, asymmetrisches Layout, Trennlinien, Tonänderungen, breite Abschnitte, Ausrichtung, Versatz/Überlappung und zurückhaltende Regeln. Die erforderliche Prüfung der gerahmten Oberfläche muss jede gerahmte Oberfläche begründen, die keine Entität ist. „Um den Abschnitt optisch zu trennen“ ist nicht ausreichend.

Der angrenzende Abschnitt design_fixtures veröffentlicht kanonische native Blockbäume, kompatible Designrichtungen, erwartete öffentliche Hooks, Anti-Patterns und deterministische Desktop-/Mobile-Erfassungsgrößen. Sein Status unterscheidet einen quellengestützten Rendervertrag von von Menschen genehmigten Screenshots. Tools können einen Gerätebaum als Kompositionsreferenz verwenden, dürfen jedoch keine visuelle Genehmigung beanspruchen, während die Registrierung render_contract_ready_capture_pending meldet. Prüfen Sie die verfügbaren Fixture-Verträge unter design_fixtures in der Discovery-Antwort.

Der Endpunkt ist generisches CMS-Produktverhalten. Es darf keine installspezifischen Geheimnisse, Tokenwerte, rohen Blade-Inhalte, absolute Dateisystempfade, private Serverpfade oder standortspezifische Anweisungen zurückgeben. Blockvertragszeilen können Handle/Slug, Bezeichnung, Kategorie, Status, Container- und Kinderunterstützung, übersetzbare Felder, Felder für gemeinsame Einstellungen und das Stammverhalten des öffentlichen Renderers enthalten.

I-Tools sollten diesen Endpunkt oder GET /webadmin/api/block-types aufrufen, bevor sie einen Plan erstellen, und dürfen nur Handles verwenden, die in der aktuellen Installation vorhanden sind.

Block-Verträge können optionale öffentliche Symbol- und Badge-Felder offenlegen, einschließlich settings.icon_slug, settings.icon_tone, settings.icon_size, settings.badge_tone und übersetzter eyebrow/badge_label-Kopie. Tools müssen Symbol-Slugs als kataloggestützte Auswahl und nicht als freien Text behandeln; Beim öffentlichen Rendering werden unbekannte oder inaktive Symbole übersprungen und nur sichere wb-icon wb-icon-{slug}-Klassen für aktive WebBlocks UI-Katalogzeilen ausgegeben. settings.icon_tone ist eine gemeinsam genutzte öffentliche visuelle Farbtoneinstellung, keine Kopie im Besitz des Gebietsschemas und akzeptiert nur default, soft, brand, accent, highlight, bold und quiet; settings.icon_size akzeptiert default, sm, lg oder xl und wird der entsprechenden Größenklasse WebBlocks UI zugeordnet. info, success, warning und danger bleiben semantische Statustöne für Ausweise, Warnungen, Validierung und Feedback. Unbekannte Symboltöne oder -größen werden während der Validierung des Inhaltsplans abgelehnt oder beim öffentlichen Rendering als sichere Alternative ignoriert. Der Badge-Ton wird nur angezeigt, wenn der Block auch über die übersetzte Badge-Label-Kopie verfügt.

GET /webadmin/api/icon-catalog?context=content gibt die aktiven Safe-Icon-Slugs zurück, die API-Clients öffentlichen Inhaltsblöcken zuweisen können. Verwenden Sie context=navigation, um mit der Navigation markierte Vorschläge bei der Auswahl von Navigationselementsymbolen an erster Stelle zu platzieren. Beide Kontexte geben weiterhin jedes aktive Symbol zurück, da der Kontext eher ein Hinweis als eine Zulassungsliste ist. API-Tools sollten diesen Endpunkt lesen, bevor sie settings.icon_slug- oder Navigations-icon-Werte senden, und dürfen keine Symbolnamen aus dem WebBlocks UI-Manifest erraten.

Der contact_form-Vertrag enthält zusätzliche sichere Formularmetadaten: Einstellungsschema, übersetzte Felder, der öffentliche POST /contact-messages-Übermittlungsendpunkt, erforderliches CSRF-Browserverhalten, Servervalidierungsregeln, das CMS-eigene versteckte generierte Anti-Spam-Prüffeld, generisches Prüffeld-Erfolgsverhalten, Spam-Klassifizierung/Quarantänehinweise, Speicher-vor-Benachrichtigungsverhalten, Empfänger-Fallback-Reihenfolge, sicher Aufzeichnung von Benachrichtigungsfehlern und /webadmin/contact-messages-Überprüfungsverhalten. Das Prüffeld wird vom Renderer generiert, ist nicht Teil der normalen Besuchereingabe und sollte nicht manuell von API oder KI-/Operator-Tools erstellt werden. Kontaktseiten-Tools sollten diesen nativen Block anstelle von Trusted HTML, Rohformular-Markup oder mailto:-Formularen verwenden. Das alte Feld website ist nicht mehr das öffentliche Kontaktformular-Vertrag.

Der für Menschen lesbare Leitfaden zum Erstellen von KI-Seiten wird in paketnativen Installationen unter vendor/fklavyenet/webblocks-cms/docs/ai-page-building-guide.md.

ausgeliefert

• GET /webadmin/api
• GET /webadmin/api/openapi.json
• GET /webadmin/api/ai-guide
• GET /webadmin/api/examples
• GET /webadmin/api/examples/contact-page
• GET /webadmin/api/examples/landing-page
• GET /webadmin/api/sites
• GET /webadmin/api/locales
• GET /webadmin/api/locale-options
• POST /webadmin/api/locales
• PATCH /webadmin/api/locales/{locale}
• GET /webadmin/api/page-layouts
• GET /webadmin/api/block-types
• GET /webadmin/api/icon-catalog
• GET /webadmin/api/content-contract

• GET /webadmin/api/pages
• GET /webadmin/api/pages/{page}
• GET /webadmin/api/pages/{page}/render
• GET /webadmin/api/pages/{page}/translations
• POST /webadmin/api/pages/{page}/translations/{locale}
• PATCH /webadmin/api/pages/{page}/translations/{translation}
• POST /webadmin/api/pages/{page}/sync-layout-slots
• PATCH /webadmin/api/pages/{page}/layout
• POST /webadmin/api/pages/{page}/slots/{slot}/shared-slot
• PUT /webadmin/api/pages/{page}/slots/{slot}/source

• GET /webadmin/api/blocks
• GET /webadmin/api/blocks/{block}

• GET /webadmin/api/navigation-menus
• GET /webadmin/api/navigation-menus/{navigationMenu}
• POST /webadmin/api/navigation-menus
• POST /webadmin/api/navigation-menus/{navigationMenu}/items
• PATCH /webadmin/api/navigation-menus/{navigationMenu}/items/{item}
• PATCH /webadmin/api/navigation-menus/{navigationMenu}/items/reorder
• DELETE /webadmin/api/navigation-menus/{navigationMenu}/items/{item}

Navigationsmenüs verwenden das vorhandene CMS-Modell navigation_items.menu_key. Phase 2A unterstützt die mitgelieferten CMS-Menü-Handles wie primary, footer, mobile, legal und docs; Es wird keine separate Menütabelle hinzugefügt. Das Erstellen eines Navigationsmenüs wird als Erstellen einer sicheren, standortbezogenen Menügruppe mit optionalen Anfangselementen behandelt. Es weigert sich, eine Site/ein Menü zu überschreiben, die/das bereits Elemente enthält.

Navigationselement erstellen, aktualisieren, Sichtbarkeitsänderungen und Neuordnung erfordern navigation.write. Zum Löschen ist die explizite destruktive Funktion navigation.delete erforderlich. Artikelaktualisierungen unterstützen label/title, url, link_type, page_id, target, visibility, sort_order/position, parent_id und icon, wobei diese Felder für den ausgewählten Linktyp gültig sind. Aktualisierungen sind teilweise: Felder, die in der Nutzlast fehlen, behalten ihre gespeicherten Werte ohne erneute Validierung, sodass ältere Zeilen (eine Sortierreihenfolge vor dem Baumeditor von 0, ein untergeordnetes Element, das unter einem übergeordneten Element vom Seitentyp verschachtelt ist) aktualisierbar bleiben. Die Regeln gelten für die Werte, die eine Anfrage tatsächlich sendet.

Elementaktualisierungen akzeptieren auch einen optionalen locale-Schlüssel (einen Gebietsschemacode, der für die Site des Elements aktiviert ist) und spiegeln Blockübersetzungsschreibvorgänge wider. Ohne locale oder mit dem Site-Standardgebietsschema schreibt label/title den kanonischen Titel des Standardgebietsschemas. Bei einem nicht standardmäßigen locale wird der label/title-Wert als gebietsschemabasierte Übersetzungszeile für dieses Element gespeichert und der kanonische Titel bleibt unberührt; Andere Felder in derselben Anfrage (Sichtbarkeit, Position usw.) bleiben gemeinsam genutzt und gelten für das Element selbst. Beim öffentlichen Rendering wird der Navigationstitel für das angeforderte Gebietsschema ausgewählt und auf den kanonischen Titel des Standardgebietsschemas zurückgegriffen, wenn keine Übersetzungszeile vorhanden ist. Element-Lese-Nutzlasten stellen die pro Gebietsschema gespeicherten Titel als title_translations-Karte bereit, die durch den Gebietsschemacode verschlüsselt ist. Nachbestellungs-Payloads müssen jeden Artikel in der ausgewählten Site/im ausgewählten Menü genau einmal enthalten. Beim Löschen werden übergeordnete Elemente abgelehnt, die noch untergeordnete Elemente haben. Daher müssen Tools zuerst untergeordnete Elemente verschieben oder löschen, anstatt sich auf cascades.

zu verlassen

Navigationselement-URLs können interne Pfade wie /, /about, /contact und /#platform oder sichere http/https-URLs sein. Verwenden Sie einen Pfad plus Fragment für Anker auf derselben Seite. Rohfragmentwerte wie #platform sind keine Navigations-URLs. Der API lehnt javascript:, data:, protokollbezogene URLs, Traversal, fehlerhafte URLs, nicht unterstützte Ziele und leere Beschriftungen ab. Navigationsendpunkte erstellen keine Seiten, veröffentlichen keine Seiten, crawlen keine Websites, rufen keine Remote-URLs ab oder löschen untergeordnete Elemente kaskadiert.

Die Erstellung von

• GET /webadmin/api/shared-slots
• GET /webadmin/api/shared-slots/{sharedSlot}
• PATCH /webadmin/api/shared-slots/{sharedSlot}
• DELETE /webadmin/api/shared-slots/{sharedSlot}
• POST /webadmin/api/shared-slots
• POST /webadmin/api/shared-slots/{sharedSlot}/blocks
• POST /webadmin/api/shared-slots/{sharedSlot}/publish-blocks

Shared Slot erfolgt auf Site-Ebene und lehnt doppelte Handles für dieselbe Site ab. Shared Slot-Blöcke verwenden denselben Block-Payload-Writer, der von seiteneigenen Blöcken verwendet wird, sodass die gebietsschemaeigene Kopie in den Übersetzungszeilen verbleibt und gemeinsam genutzte Einstellungen im Blockdatensatz-/Einstellungspfad verbleiben. Shared Slot-Blockanhängeanforderungen können parent_id oder parent_block_id enthalten, um einen Block unter einem vorhandenen Block im gleichen Shared Slot-Quellbaum hinzuzufügen, wenn dieser übergeordnete Block den angeforderten untergeordneten Typ akzeptiert. Shared Slot-Blöcke werden als Entwurfsinhalt erstellt und erfordern explizites POST /webadmin/api/shared-slots/{sharedSlot}/publish-blocks mit shared-slots.write plus content.publish, bevor sie öffentlich gerendert werden. Medienimport und Medienzuordnung bleiben außerhalb dieser Phase.

Der shared-slot-Endpunkt weist einem vorhandenen Seitenslot einen vorhandenen kompatiblen aktiven Shared Slot am selben Standort zu. Die Seite wird nicht veröffentlicht. Es lehnt standortübergreifendes, inaktives und inkompatibles Shared Slots ab. Es weigert sich auch, einen Slot zu wechseln, der noch seiteneigene Blöcke enthält, da Phase 2A diese Blöcke nicht automatisch löscht oder ersetzt.

PUT .../source schreibt die Inhaltsquelle des Slots und ist der Ausweg: source_type akzeptiert page, shared_slot oder disabled. Es erfordert content.apply und shared_slot zusätzlich shared-slots.write und die gleichen Kompatibilitätsregeln wie der Zuweisungsendpunkt, an den es delegiert. Durch das Trennen wird shared_slot_id gelöscht und seiteneigene Blöcke bleiben unberührt, sodass page sie erneut rendert und disabled den Slot-Wrapper ohne Inhalt behält. Bevor dieser Endpunkt existierte, konnte API eine Shared Slot-Referenz erstellen, die er nicht entfernen konnte – der einzige Ausgang war der sitzungsauthentifizierte Admin-Bildschirm.

Wenn das Seitenlayout einen Slot wie header enthält, der Seitendatensatz jedoch erstellt wurde, bevor dieser Seitenslot existierte, rufen Sie zuerst POST /webadmin/api/pages/{page}/sync-layout-slots auf. Die Slot-Synchronisierung ist idempotent und erstellt nur fehlende Seitenslots aus dem ausgewählten Seitenlayout. Es löscht niemals vorhandene Slots, Blöcke, deaktivierte Zustände, Shared Slot-Zuweisungen, Übersetzungen oder Revisionen. Veröffentlichen Sie für einen neuen Shared Slot-Header die Shared Slot-Blöcke explizit, bevor Sie die öffentliche Ausgabe erwarten.

Schreibt das Seitenlayout einer vorhandenen Seite (public_shell). Das Admin-Bearbeitungsformular könnte dies jederzeit ändern; Der API konnte es bisher nur beim Erstellen einer Seite festlegen. content.apply deckt es ab. layout (oder handle) muss einer der aktiven Handles von GET /webadmin/api/page-layouts sein – der alte Alias ​​dashboard normalisiert sich weiterhin zu docs. Entspricht dem eigenen Vertrag von PageController::update(): Seitenslots werden bei einer einfachen Layoutänderung nicht mutiert, dieser Endpunkt also auch nicht. Rufen Sie sync-layout-slots separat auf, wenn das neue Layout Slots definiert, die die Seite noch nicht hat.

Dieser Endpunkt aktualisiert nur die Voreinstellung für das öffentliche Design der sicheren Site, die beim öffentlichen Rendering verwendet wird. Senden Sie public_theme_preset oder theme mit einem der unterstützten Site::PUBLIC_THEME_PRESETS-Werte wie canvas, atlas, pulse, prism, graphite oder horizon. Verwenden Sie dies, wenn die API-Erkennung ein Site-Rendering mit der falschen data-wb-public-theme-Voreinstellung anzeigt; Versuchen Sie nicht, die Voreinstellung mit Inhaltsblöcken zu überschreiben.

PATCH /webadmin/api/sites/{site}/branding erfordert site-settings.write und aktualisiert sichere Branding-Felder für öffentliche Websites, die auch in Sites -> Edit Site -> Branding:

sichtbar sind

• display_name
• tagline
• favicon_media_id
• social_image_media_id
• Medienersetzung behält die Medien-ID und redaktionelle Referenzen bei, löscht veraltete Bildtransformationen und leitet zukünftige Varianten aus der Ersatzbinärdatei ab.

Die Favicon- und Social-Image-Felder müssen auf Bilddatensätze aus der CMS-Medienbibliothek verweisen, und null löscht die ausgewählten Medien. Bei Favicon-Änderungen an öffentlichen Websites sollte dieser Endpunkt verwendet werden, damit das Ergebnis weiterhin vom Administrator bearbeitet werden kann. /cms/brand/* nicht überschreiben; Bei diesen Dateien handelt es sich um CMS-Produkt-/Administrator-Shell-Assets und nicht um öffentliches Branding auf Site-Ebene.

PATCH /webadmin/api/sites/{site}/timezone erfordert site-settings.write und legt die eigene Zeitzone einer Site fest – eine Standard-IANA-Kennung wie Europe/Berlin. Alles, was die lokale Uhrzeit für diese Site auflöst, z. B. die Buchungsverfügbarkeitsfenster eines Plugins, wird anhand dieses Werts interpretiert. Senden Sie ein leeres timezone, um es von Admin -> System Settings.

zurück in die installationsweite Systemzeitzone zu löschen

GET /webadmin/api/sites/{site}/assets/{css|js} erfordert site-assets.read und liest die kanonische Überschreibungsdatei auf physischer Standortebene. Es werden relative_path, public_path, exists, contents, checksum, size, updated_at, readiness, guidance und CSS zurückgegeben analysis, ohne den absoluten Serverpfad offenzulegen. Das Objekt readiness meldet, ob das Site-Verzeichnis, das Asset-Verzeichnis und die Datei ausreichend beschreibbar sind, damit CMS das Asset erstellen oder aktualisieren kann. Das guidance-Objekt weist KI-/Operator-Tools an, CSS token-first, mode-aware und native-block-first beizubehalten. Für CSS meldet asset.analysis.mode_awareness status, Warnmeldungen, erkannte Anti-Pattern-Schlüssel, Signale wie die Anzahl der Literalfarben und empfohlene --wb-public-*-Token. PUT /webadmin/api/sites/{site}/assets/{css|js} erfordert site-assets.write und akzeptiert:

• contents
• expected_checksum

Der Schreibendpunkt verwendet denselben physischen Dateispeicher wie Sites -> Edit Site -> Assets. Es schreibt nur public/site/{site_handle}/css/site.css oder public/site/{site_handle}/js/site.js, erstellt fehlende Verzeichnisse beim ersten Speichern, lehnt veraltete expected_checksum-Werte ab und speichert einen Revisions-Snapshot vor dem Überschreiben, bevor eine vorhandene geänderte Datei ersetzt wird. Es gibt keine Datenbank-Fallback-Route und keinen beliebigen /site/...-Pfadschreiber. Wenn Hosting-Berechtigungen das Erstellen von Verzeichnissen oder das Schreiben von Dateien verhindern, gibt der Endpunkt JSON 422 mit errors.0.path = asset.write und den aktuellen Bereitschaftsmetadaten anstelle eines Serverfehlers HTML zurück.

Für CSS-Schreibvorgänge verwenden Sie native Blockstruktur/-einstellungen, Hintergrundfelder der Medienbibliothek, öffentliche Design-Tokens und geerbte WebBlocks UI-Komponentenstile, bevor Sie benutzerdefinierte Selektoren hinzufügen. Wenn benutzerdefinierte Farben unvermeidbar sind, definieren Sie semantische benutzerdefinierte Eigenschaften mit Hell- und Dunkelwerten, die an aktive Modusselektoren oder öffentliche Design-Tokens gebunden sind, damit öffentliche Seiten im Hell-/Dunkel-/Auto-Modus kohärent bleiben. Vermeiden Sie seitenweite fest codierte helle Hintergründe, dunklen Text, weiße Karten oder einmalige Dunkelmodus-Paletten, wenn öffentliche Design-Tokens das Design zum Ausdruck bringen können. PUT lehnt Warnungen zur Moduserkennung nicht ab, da einige Markensysteme absichtlich benutzerdefinierte Farben benötigen. Tools sollten asset.analysis.mode_awareness.status = warning jedoch als Arbeit behandeln, die überprüft, gemeldet oder behoben werden muss, bevor eine Migration oder die Einrichtung einer neuen Site in Betracht gezogen wird.

Kommentare werden vor der Analyse entfernt: Ein Stylesheet, das sich selbst dokumentiert, indem es die von ihm reparierte Regel zitiert, meldet die zitierte Farbe nicht als eine eigene, und ein nur in einem Kommentar genannter Dark-Mode-Bereich zählt nicht als vorhanden.

Bei den anti_patterns-Prüfungen geht es um seitenweites Malen, daher muss bei jeder Prüfung das Token die letzte Verbindung des Selektors sein und dort enden, wo der Name endet: body { background: #fff } wird gemeldet, body .promo { background: #fff } und .wb-public-body { ... } nicht, und .wb-card-title wird nicht gelesen als .wb-card. Eine Regel, die ein Element malt, wird den Literal-Farbsignalen überlassen und nicht als seitenweites Anti-Muster gemeldet.

asset.analysis.mode_awareness ist absichtlich ein heuristischer Vertrag, kein CSS-Linter. Es meldet pass oder warning, warnings, erkanntes anti_patterns, einfaches signals wie wörtliche Farbdeklarationen, uses_public_theme_tokens und has_dark_mode_scope sowie die empfohlenen --wb-public-*-Tokenrollen. Tools sollten dieses Signal verwenden, um wahrscheinliche Regressionen im gemischten Modus frühzeitig zu erkennen und sich dennoch auf die visuelle Qualitätssicherung für die endgültige Designparität verlassen.

Anwendungscode sollte nicht mit dem globalen site.css oder site.js einer Site zusammengeführt werden. Ein registrierter Embedded Application kann den physischen CSS, JavaScript und einen verwalteten index.html-Eintrag in seinem standortbezogenen öffentlichen Verzeichnis besitzen:

CSS und JavaScript verwenden den deterministischen öffentlichen Pfad /site/{site_handle}/applications/{application_handle}/{type}/{filename}. Der Typ HTML akzeptiert nur index.html, speichert es im Stammverzeichnis der Anwendung und gibt den vom Host ausgewählten stabilen öffentlichen Pfad /webblocks-applications/{application_handle}/index.html zurück. Durch das Schreiben dieses verwalteten Eintrags wird die Definition in den Iframe-Modus umgeschaltet und diese URL aktiviert. GET, PUT und DELETE erfordern jeweils applications.read, applications.write und applications.delete. Dateinamen sind nur Basisnamen und müssen mit der ausgewählten Erweiterung .css, .js oder .html enden. HTML akzeptiert keinen anderen Dateinamen als index.html; Durchquerung, verschachtelte Pfade, andere Dateitypen und Remote-URLs werden abgelehnt.

PUT akzeptiert contents und expected_checksum. Senden Sie null nur, wenn Sie eine fehlende Datei erstellen. Lesen Sie zuerst eine vorhandene Datei und senden Sie deren Prüfsumme, wenn Sie sie ersetzen. Durch Ersetzungen und Löschungen bleiben Revisionskopien erhalten. Das Löschen wird abgelehnt, solange die Embedded Application-Definition noch auf den öffentlichen Pfad des Assets verweist. Nachdem Sie ein Asset geschrieben haben, verwenden Sie dessen zurückgegebenes public_path in css_assets oder js_assets. Der Anwendungsblock lädt ihn dann nur dort, wo die Anwendung platziert ist.

Complete-Anwendungen sollten den Paketendpunkt verwenden, anstatt Dateien einzeln zu schreiben. Es erfordert applications.write und multipart/form-data mit einem package-ZIP-Feld (maximale Upload-Größe 50 MB). Erhöhen Sie zunächst den version der registrierten Anwendung mit PATCH /webadmin/api/applications/{application}. Laden Sie dann eine ZIP-Datei hoch, die im Stammverzeichnis index.html enthält, und verwenden Sie darin relative Asset-URLs. Eine erfolgreiche Antwort gibt die Paketversion, den aktivierten unveränderlichen entry_url, die Dateianzahl und die erweiterte Bytegröße sowie die aktualisierte Anwendungsdefinition zurück. Installierte Versionen können nicht überschrieben werden. Validierungs- und Archivsicherheitsfehler geben strukturierte JSON 422-Fehler unter errors[0].path = application_package (oder application_package.package für das mehrteilige Feld) zurück.

• POST /webadmin/api/content/validate
• POST /webadmin/api/content/apply

Inhaltspläne können bereits hochgeladene Datensätze der CMS-Medienbibliothek nativen mediengestützten Blöcken zuweisen. Verwenden Sie media_id oder asset_id auf den Blöcken image, navbar-brand, sidebar-brand, file, download und video mit Medien der passenden Art. Verwenden Sie media_id oder asset_id auf hero, section, card, cta und content_header, wenn das Medium das Blockhintergrundbild ist, optional mit settings.background_position und settings.background_overlay. Verwenden Sie gallery_items oder gallery_media_ids für gallery-Blöcke mit Bildmediendatensätzen. Der API behält beim Schreiben von block_media.position die übermittelte Reihenfolge der Galerieelemente bei. Erstellen Sie für Karteninhaltsbilder die normale verschachtelte Struktur, z. B. card -> card_body -> image, und fügen Sie media_id in den untergeordneten Block image ein. Inhaltspläne lehnen remote_url und source_url weiterhin ab; Laden Sie Dateien über POST /webadmin/api/media hoch oder importieren Sie zuerst eine genehmigte öffentliche Datei-URL über POST /webadmin/api/media/fetch und weisen Sie dann die zurückgegebene Datei media.id.

zu

Inhaltspläne verwenden ausdrückliche Entwurfs- oder Staging-Modi. Validieren Sie vor Anwendung und lassen Sie Veröffentlichung separat genehmigen. Live-Seiten benötigen ein eigenes geprüftes Staging-Update statt direkten Ersatzes.

Ein Plan darf freigegebene Mediatheksdatensätze referenzieren. Abrufe, Uploads und andere Ressourcenoperationen verwenden eigene Endpunkte und Fähigkeiten; ein Plan verleiht diese Rechte nicht. Entdecken Sie zuerst die aktuellen Endpunkte.

Bearer-Token-JSON-Schreibzugriffe verwenden Token-Autorisierung. Minimale unauthentifizierte Discovery erlaubt keinen Inhaltszugriff. Authentication und Capabilities erläutern den Umfang.

API-Fehler sind ausschließlich JSON. Sie dürfen nicht zum Login umleiten, keine CSRF-Seiten rendern und keine Stacktraces offenlegen. Übliche Felder:

Erwartete Status:

• 401 invalid_internal_api_tokenfür fehlende, ungültige, widerrufene, abgelaufene oder nicht mehr vom Benutzer gesicherte Token
• 403 missing_internal_api_capabilityfür fehlende Fähigkeiten
• 403 delegated_site_access_deniedwenn ein persönlicher Token auf eine Site außerhalb seines Live-Bereichs abzielt
• 403 delegated_workflow_access_deniedwenn der Eigentümer die Seite in ihrem aktuellen Workflow-Status nicht bearbeiten kann
• 403 delegated_operation_deniedfür Vorgänge auf Installationsebene, die persönliche Token ablehnen
• 403 delegated_network_access_deniedwenn die aufgelöste IP außerhalb der persönlichen Token-Zulassungsliste liegt
• 429 personal_api_token_rate_limit_exceededwenn die persönliche Obergrenze erreicht ist; Kunden müssen ehrenRetry-After
• 422für Validierungsfehler

Rerfordert admin.render und ein Token, das von einem Benutzer erstellt wurde, der auf System zugreifen kann. Die JSON-Antwort enthält den gerenderten Administrator HTML für den zugelassenen System Updates-Bildschirm; ?format=html gibt direkt text/html zurück, sodass Bedienertools den Snapshot in einen lokalen Browser laden und Screenshots zum visuellen Vergleich erfassen können. Der Endpunkt ist schreibgeschützt und darf nicht auf den Aktualisierungsstatus klicken, ihn installieren, veröffentlichen oder ändern.

Rerfordert engagement.read. Unterstützte Filter sind status, site_id, page_id, block_id, search und per_page. Zu den Antworten gehören Kommentartext, Status, Spam-Score/Gründe, Quellseiten-/Blockreferenzen und Zeitstempel, sie stellen jedoch keine Besucher-Hashes, IP-Hashes oder User-Agent-Werte offen.

Rerfordert engagement.moderate. Unterstützte Status sind pending, approved, rejected, spam und hidden.

Rerfordert engagement.read. Unterstützte Filter sind status, site_id, page_id, block_id und per_page. Die Antworten umfassen Bewertungszeilen sowie Gesamt-, Durchschnitts- und Wertzusammenfassungen, stellen jedoch keine Besucher-Hashes, IP-Hashes oder Benutzeragentenwerte offen.

Dieselbe Payload kann an beide Endpunkte übermittelt werden:

Beispiel eines englischen Marketing-Homepage-Entwurfs:

• Planfelder, die der API nicht versteht, werden mit abgelehnt422und der stabile Codeunsupported_plan_fields, und der Fehlerpfad benennt jeden einzelnen; Der akzeptierte Schlüsselsatz ist auf den Plan beschränktmode, sodass ein Schlüssel, der in einem Modus sinnvoll ist, in einem anderen dennoch abgelehnt wird
• Site-Handle oder ID müssen aufgelöst werden
• Das Gebietsschema muss vorhanden und für die Zielsite aktiviert sein
• Das Layout muss vorhanden sein
• Pfadkonflikt blockiert Seitenerstellung
• Der Blocktyp muss veröffentlicht und verwendbar sein
• Für den Kindesunterhalt müssen, sofern verfügbar, Pauschalverträge gelten
• Inhaltsplan-Blockbäume müssen verschachtelt seinchildren; Wohnungid,parent_id,block_id,slot_type_id, Undblock_type_idBeziehungsfelder werden abgelehnt, da API Datenbank-IDs und übergeordnete Zuordnungen besitzt
• Blocktranslationsmuss direkte Feldschlüssel für das ausgewählte Plangebietsschema enthalten, ztitle,subtitle, Undcontent; Lokale-spezifische Formen wie ztranslations.en.titlewerden abgelehnt, anstatt stillschweigend ignoriert zu werden
• Wrapper-Blöcke wie zsection,container,stack,split,cluster,grid,card,card_body,card_footer,sticky-navbar, Undsidebar-navigationmüssen untergeordnete Blöcke enthalten, damit sie nicht als leeres öffentliches Chrome validiert werden können;spliterfordert genau zwei direkte untergeordnete Elemente, und jede Seite kann verschachtelt seinstack
• Für den Benutzer sichtbarer Text gehört in Übersetzungszeilen
• Geteilte Einstellungen bleiben geteilt
• Neue oder geänderte Kerneinstellungen müssen mit dem ermittelten Block-Authoring-Schema übereinstimmen. Unbekannte Felder und ungültige Werte werden bei Feldpfaden abgelehnt
• historische unbekannte Einstellungen bleiben lesbar und überdauern unabhängige Aktualisierungen; Ein exakt unveränderter Wert kann PATCH begleiten, berechtigt jedoch nicht zur Änderung eines nicht deklarierten Felds
• apply validiert vor dem Schreiben erneut
• apply ist transaktional
• „Content Apply“ lehnt weiterhin Veröffentlichungs-, Site-Erstellungs-, Medienimport-, Remote-Abruf-, nicht unterstützte Überschreib-, nicht unterstützte Ersetzungs- und Löschvorgänge ab
• Die Erstellung von Shared Slot bleibt schreibgeschützt, es sei denn, in einer späteren Phase werden explizite entwurfssichere Mutationsverträge hinzugefügt
• Navigationselement-Ressourcenendpunkte unterstützen explizite Aktualisierungs-, Sichtbarkeits-, Neuordnungs- und Löschvorgänge außerhalb der Inhaltsanwendung mit Capability Guards

Antworten sollten vorhersehbares JSON sein:

Validierungsfehler sollten einen Pfad und eine Meldung enthalten:

edit_url einbeziehen, wenn dies für erstellte oder aktualisierte CMS-Ressourcen nützlich ist.

renderability ist eine Plan-Sanity-Zusammenfassung für KI-/Operator-Tools. Ein erfolgreicher strukturierter Seitenplan sollte normalerweise wrapper_blocks_without_children, text_blocks_without_visible_content und button_blocks_without_label_or_url bei 0 enthalten. html_blocks über 0 bedeutet, dass im Plan die vertrauenswürdige Fluchtluke HTML verwendet wurde; Tools sollten dies nur mit ausdrücklicher Zustimmung des Betreibers und nur dann tun, wenn erstklassige Blocktypen den Inhalt nicht darstellen können.

Content-Pläne dürfen navigation_menus, shared_slots und page_slot_shared_slots neben dem bestehenden Seiten-/Slot-Plan enthalten. validate schreibt nichts. apply schreibt alle gültigen Abschnitte in einer Transaktion und rollt den gesamten Plan zurück, wenn ein späterer Abschnitt fehlschlägt.

Navigationselemente tragen link_type: custom_url (standardmäßig ist ein sicherer interner Pfad oder eine http(s)-URL erforderlich), page (erfordert page_id für eine Seite auf derselben Site; die Bezeichnung greift auf den Seitennamen zurück) oder group (ein Label, das seine untergeordneten Elemente öffnet und keine URL trägt). Nur ein group akzeptiert children, die mit bereits verknüpftem parent_id erstellt wurden. Ein Dropdown-Menü ist also ein Plan und nicht ein POST plus ein PATCH pro Artikel. Inhaltspläne sind auf einer Ebene verschachtelt; Tiefere Bäume verwenden POST /navigation-menus/{menu}/items. Ein nicht unterstützter link_type wird namentlich abgelehnt, anstatt zu custom_url.

gezwungen zu werden

page_slot_shared_slots[].page kann auf die Seite verweisen, die mit demselben Plan mithilfe von created erstellt wurde, oder auf eine vorhandene Seiten-ID. shared_slot kann sich auf einen Shared Slot beziehen, der zuvor im selben Plan erstellt wurde, oder auf ein vorhandenes Shared Slot-Handle am selben Standort.

Content-Pläne speichern eine abgeschlossene Seitenversion nach allen Blockschreibvorgängen und Shared Slot-Zuweisungen sowie eine abgeschlossene Version pro neu erstelltem Shared Slot. Bestehende Seitenzuweisungspläne speichern eine Sicherheitsversion vor der Änderung pro betroffener Seite. Slot-Ersetzung und gestaffelte Werbung behalten ihre expliziten Sicherheitskontrollpunkte. Bei einer unveränderten aufeinanderfolgenden Erfassung wird der letzte vollständige Schnappschuss wiederverwendet und ein separates Erfassungsereignis aufgezeichnet. Unabhängige HTTP-Anfragen bleiben separate Vorgänge. Versionsdetaillesevorgänge umfassen begrenztes inspection.capture_history mit aktuellen Erfassungsereignissen und ein has_more-Flag. Siehe Revisions.

• zuerst Sites, Sprachen (Locales), Layouts und Blocktypen erkunden
• vor dem Apply validieren
• Entwurfsinhalte erstellen
• strukturierte Blöcke aus docs/public-block-render-markup.md bevorzugen
• Safe HTML nur als geprüften Fallback verwenden
• generierte öffentliche Texte in der Zielsprache halten, etwa Englisch für eine englische Homepage

• keine OpenAI- oder LLM-Integration im CMS-Kern
• kein Crawling oder Fetching
• kein beliebiger Import-/Export-Ersatz
• kein automatisches Veröffentlichen
• kein destruktives Löschen in Phase 1
• keine Annahme einer Host-Route /admin
• keine Verwendung des Routen-Präfixes /cms
• kein QuizTem-spezifischer Laufzeitcode; die QuizTem-Homepage-Generierung ist ein späterer Consumer-Anwendungsfall für diese generische CMS-API

Den vollständigen Blockkatalog, die Speicherzuständigkeiten und Renderer-Verträge beschreibt Blocktyp-Verträge. Die Schemata ergänzen das CMS-Inventar. Sie erteilen keine Zugriffsrechte und machen einen ausschließlich für menschliche Bearbeitung vorgesehenen Block nicht über die API beschreibbar.

Ab CMS 1.105.9 enthalten Blocktyperkennung und Inhaltsverträge zusätzlich ein authoring_settings_schema-Objekt. Die bisherigen settings_schema-Antwortformate bleiben erhalten. Schemarevision 1 umfasst alle veröffentlichten Kernblöcke und stellt mode, unknown_fields und fields bereit. Jedes Feld beschreibt Typ, Auswahl-, Bereichs- und Längengrenzen, das Leeren mit null oder leeren Werten, die Beibehaltung nicht übermittelter Felder und getrennte Entscheidungen für writes.admin, writes.create und writes.patch, gegebenenfalls mit einer Begründung unter closed_reason.

Lesen Sie diese Operationsflags vor dem Schreiben. Ein beim Erstellen eines Blocks akzeptiertes Feld ist über PATCH nicht automatisch beschreibbar. Kontaktübermittlungs-/Datenschutzfelder behalten ihre absichtlich bestehenden PATCH-Ausschlüsse bei, HTML bleibt nur für Menschen zugänglich und Medienreferenzen verwenden ihre dedizierten Beziehungsfelder. Feldschemata gewähren keine Berechtigungen und fragen keine externen Inhaltsanbieter ab.

Inhaltspläne und Slotblock POST lehnen unbekannte Schlüssel und ungültige bereitgestellte Werte vor dem Schreiben ab. PATCH validiert nur Änderungen und führt sie mit den aktuellen Einstellungen zusammen. Ein falsch geschriebener Wert aligment wird abgelehnt, anstatt einen Wert zu akzeptieren, der keine sichtbare Auswirkung hat. Ein ungültiger alignment-Wert wird abgelehnt, anstatt die vorhandene Auswahl stillschweigend zu löschen. Fehlende Werte führen bei Aktualisierungen nicht zum Einfügen von Standardwerten. Deklarierte Kompatibilitätsaliase werden weiterhin unterstützt: Slider fade normalisiert sich zu slide, Gallery masonary zu masonry und vorhandene Kontaktformular-Kopierschlüssel in den Erstellungseinstellungen werden vom Locale-Übersetzungs-Writer verwendet. PATCH verwendet translations für diese Kopie. Ganzzahlige Werte werden nicht stillschweigend geklemmt und überlanger Text wird nicht stillschweigend abgeschnitten. Vorhandene Erstellungsvorgaben wie „Spalten plain“ und „Split stack“ bleiben erhalten.

Historische unbekannte oder fehlerhafte Werte bleiben lesbar, werden mit vorhandenen Fallbacks gerendert und überdauern unabhängige Aktualisierungen. Ein Client darf ein identisches historisches Feld nur dann übertragen, wenn der Server es mit genau diesem vorhandenen Block vergleichen kann; Dies berechtigt nicht zum Hinzufügen oder Ändern unbekannter Einstellungen. Bei neuen Blöcken und vollständigen Ersatznutzlasten handelt es sich um neue Autoren, daher kann für sie keine Ausnahme wegen historischem Wert gelten. Vertrauenswürdiges Klonen, Staging und Revisionswiederherstellung behalten ihre verlustfreien Speicherpfade.

Plugins ohne Schemata behalten ihr eigenes bestehendes Einstellungsverhalten bei. Plugins können sich über die Blockdefinition anmelden oder sich mit Skalarregeln manifestieren; Eine ungültige Deklaration blockiert Schreibvorgänge für dieses Schema, ohne nicht verwandte Kernblöcke zu blockieren. Anwendungseinstellungen, aktive Symbole und Dynamic Content-Bindungen verwenden nach der gemeinsamen Feldprüfung weiterhin ihre speziellen Validatoren.

Serverbetreiber können php artisan webblocks:blocks:audit-settings für einen schreibgeschützten Kompatibilitätsbericht ausführen, bevor sie vorhandenen Inhalt erstellen. Es druckt Identitäten, Feldpfade und Codes anstelle von Einstellungswerten, scannt ohne Reparaturen oder Anbieterabfragen und beendet 1, wenn inkompatible Einstellungen vorhanden sind. --limit=100 begrenzt gemeldete Blöcke (maximal 1000); Die Zusammenfassung zählt weiterhin den gesamten Scan. Dadurch wird die Kompatibilität des Skalarschemas überprüft, nicht der Zustand externer Anbieter oder Anwendungen. Schemalose Plugins werden separat gezählt. Neu geänderte deklarierte Einstellungen sind auf 128 Felder, 256 KiB, 32 verschachtelte Ebenen und 4096 Knoten beschränkt, ohne dass diese Beschränkungen rückwirkend auf unveränderte historische Daten angewendet werden.