Betrieb

WebBlocks CMS enthält betriebliche Werkzeuge auf Installationsebene für Updates, Backups und Site-Transferpakete.

Settings befindet sich ebenfalls unter der Admin-Navigation System, da es die Einstellungen für Projektidentität, Sprache (Locale), Zeitzone, Datenschutz, Version und Umgebung auf Installationsebene steuert.

Admin -> System -> Block Types dient außerdem als Katalog-Prüfbildschirm auf Installationsebene. Der Filter Support ist für Blockfähigkeiten und Content-Source-Metadaten gedacht, während der Filter Usage tatsächliche Live-Nutzungszahlen aus der Tabelle blocks zeigt, damit Administratoren genutzte und ungenutzte Blocktyp-Zeilen überprüfen können.

Admin -> System -> Visitor Reports bietet datenschutzfreundliche Traffic-Berichte neben den Systemeinstellungen auf Installationsebene.

Maintenance bleibt die Gruppe der betrieblichen Werkzeuge für:

• Suchindex-Neuaufbau
• Backups
• Export / Import
• Update

Visitor Reports ist ein datenschutzfreundlicher Betriebsbericht für die Aktivität öffentlicher Seiten. Anonyme Seitenaufrufe können ohne einwilligungsbasierte Kennungen gezählt werden. Der Bericht speichert außerdem ausschließlich aggregierte Informationen zu Referrern, Kampagnen, Geräten und Bots:

• Referrer werden auf Host/Domain plus den Typ direct, internal oder external normalisiert; vollständige Referrer-URLs werden weder gespeichert noch angezeigt
• leere Referrer werden als Direct / Unknown gruppiert
• UTM-Quelle, -Medium und -Kampagne werden nur als normalisierte Werte gespeichert; der vollständige Query-String wird nicht gespeichert
• User-Agent-Strings werden zum Zeitpunkt der Anfrage auf die Gerätekategorie (desktop, mobile, tablet, bot oder unknown) sowie, sofern verfügbar, grobe Browser-/Betriebssystemfamilien reduziert; vollständige User-Agent-Strings werden nicht gespeichert
• bekannte Crawler- und Bot-User-Agent-Muster werden als Bot-Seitenaufrufe gezählt und bleiben im Bericht sichtbar, statt stillschweigend entfernt zu werden

Eindeutige Besucher, Sitzungen, Einstiegsseiten und durchschnittliche Seiten pro Sitzung erfordern einwilligungsbasiertes Sitzungs-Tracking. Wenn ein Datums-/Site-/Sprach-/Traffic-Filter Seitenaufrufe enthält, aber keine verwertbare Sitzungs- oder Besucherkennung, zeigt die Oberfläche Not tracked statt 0 an. Ältere Zeilen, die sich nicht sicher nachträglich befüllen lassen, bleiben je nach vorhandenen Aggregatfeldern Unknown, Direct / Unknown oder Not tracked.

Die Site-bezogene Autorisierung gilt weiterhin: Super-Admins können alle Sites sehen, während Site-Admins und Editoren nur die Daten der ihnen zugewiesenen Sites sehen. Der Site-Filter ist auf die für den Benutzer zugänglichen Sites beschränkt.

System-Updates vergleicht die laufende CMS-Codeversion mit dem konfigurierten Update-Dienst.

Der Update-Bildschirm kann unter anderem folgende Zustände melden:

• Update verfügbar
• auf dem neuesten Stand
• lokale/Quell-Version neuer als das zuletzt veröffentlichte Release
• inkompatibles Update verfügbar
• keine Releases gefunden
• Update-Server nicht erreichbar
• ungültige oder nicht unterstützte Antwort

Der In-App-Update-Ablauf lädt das Release-Paket herunter, wendet Regeln für geschützte Pfade an, führt erforderliche Update-Migrationen aus, leert Caches, verifiziert die angewendete WebBlocks-CMS-Codeversion gegen das Ziel-Release, protokolliert den Update-Lauf und persistiert die installierte Version.

Die Update-Verfügbarkeit basiert darauf, dass die zuletzt veröffentlichte Release-Version neuer ist als die laufende CMS-Codeversion. Historische fehlgeschlagene Update-Läufe und veraltete gespeicherte Werte der installierten Version bleiben über das Modal des letzten Laufs, den Support-Bericht, die CLI für aufbewahrte Läufe oder Update Readiness einsehbar, machen eine aktuelle Installation aber nicht von selbst handlungsbedürftig.

Der Bildschirm zeigt standardmäßig zwei Karten: zuerst Install Update, dann Update Details. Install Update ist der einzige primäre Aktionsbereich. Wenn ein kompatibles Update verfügbar ist, zeigt die Karte den Versionspfad von der aktuellen zur neuesten Version, den Kompatibilitätsstatus, den Installations-CTA und ein eingeklapptes Akkordeon Package Safety Details. Wenn kein Update verfügbar ist, zeigt sie eine zurückhaltende Meldung „auf dem neuesten Stand“ oder „nicht erreichbar“ und lässt die Paketsicherheitsdetails weg.

Update Details enthält WebBlocks-UI-Akkordeonzeilen für Release Notes, Update Readiness und Last Update Run. Update Readiness beschreibt die aktuelle Installation und die Prüfungen des Update-Dienstes; es handelt sich nicht um Release-Note-Inhalte für die Zielversion. Last Update Run zeigt auf dem Hauptbildschirm nur die Zusammenfassung des letzten relevanten Laufs; Details sind in einem Modal verfügbar. Super-Admins können von derselben Karte aus einen Support-Bericht für Support-Workflows im Shared Hosting herunterladen; der Bericht vermeidet Tokens, Geheimnisse, absolute lokale Pfade und rohe Stacktraces, enthält aber die aktuelle/neueste Version, den Bereitschaftsstatus, Details zum letzten Lauf und Zusammenfassungen der aufbewahrten Läufe.

Die Update-Historie wird nicht mehr als Tabelle auf dem Hauptbildschirm dargestellt, und das Löschen von Zeilen ist nicht Teil der Admin-Oberfläche. Datensätze zu Update-Läufen werden automatisch bereinigt; standardmäßig bleiben die letzten fünf Läufe erhalten. Der letzte fehlgeschlagene Lauf wird aufbewahrt, bis ein neuerer erfolgreicher Lauf existiert. Operatoren mit Terminalzugriff können aufbewahrte Datensätze mit php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last oder php artisan webblocks:updates:runs --failed einsehen und mit php artisan webblocks:updates:prune-runs --keep=5 eine kontrollierte Bereinigung ausführen.

Der Update-Client unterstützt strukturierte Metadaten des Update-Dienstes, darunter Titel, Zusammenfassung, Highlights, Fehlerbehebungen, Kompatibilitätshinweise, Migrationshinweise, Asset-Hinweise, Operator-Hinweise und technische Hinweise. Diese Werte werden als escapeter Klartext in operatorbezogenen Gruppen innerhalb des Akkordeons „Release Notes“ dargestellt. Ältere Releases, die nur release_notes bereitstellen, zeigen diese Hinweise weiterhin sauber an, und Releases ohne Hinweise zeigen No release notes were provided for this release. Bereitschaftsprüfungen, die gespeicherte installierte Version und Low-Level-Werte des Update-Servers verbleiben in Update Readiness.

Die Kernkatalog-Synchronisierung ist nicht mehr Teil der normalen Anwendungskette des System-Updates. Release-Pakete wenden Code, Assets, erforderliche Update-Migrationen, Cache-Leerungen, die Versionsverifizierung nach der Anwendung, die Laufhistorie und die Persistierung der installierten Version an; die umfassende Katalogreparatur ist ein expliziter Wartungs-Workflow.

Für manuelle Wartung oder Wiederherstellung auf einer bestehenden Installation können Administratoren und Entwickler außerdem Folgendes ausführen:

webblocks:catalog-repair unterstützt --block-types, --slot-types, --page-layouts, --icons und --all. Der Befehl meldet erstellte, aktualisierte, unveränderte und übersprungene Zeilen, bewahrt installationsspezifische benutzerdefinierte Katalogzeilen und kann wiederholt ausgeführt werden. block-types:sync-core bleibt als niedrigstufiger Kompatibilitätsbefehl für den Blocktyp-Katalog bestehen.

Veröffentlichte Release-Pakete sind Kernproduktpakete. Sie enthalten wiederverwendbaren CMS-Quellcode, Assets, Migrationen, Views, Routen, Konfiguration, Dokumentation und Tests, jedoch keine installationsspezifischen Inhalte der Projektschicht aus project/.

Die Veröffentlichung von CMS-Releases/Updates ist ein nativer/lokaler Maintainer-Workflow:

release:prepare erstellt lokal das paketbasierte ZIP, die Prüfsumme und die Publisher-Payload. release:publish-update sendet das Paket und die Metadaten an den paketeigenen Standard-Veröffentlichungsendpunkt https://publisher.webblocksui.com/api/updates/publish und verifiziert anschließend die neuesten Update-Server-Metadaten für webblocks-cms auf dem Stable-Kanal. Installierte CMS-Sites konfigurieren in normalen .env-Dateien keine Umgebungsschlüssel für Publisher/Update-Server, Produkt oder Kanal; der CMS-Produktcode besitzt den Standard-Release-Server, den Produktschlüssel, den Stable-Kanal, den Latest-Pfad und den Publish-Pfad über ReleaseDefaults. Für die Veröffentlichung wird normalerweise nur WEBBLOCKS_PUBLISHER_TOKEN benötigt. Läufe mit gecachter Konfiguration aktualisieren nur dieses Token aus der Projekt-.env, und die Diagnose meldet nur den Konfigurationsstatus als Ja/Nein. Die frühere Brücke updates.webblocksui.com ist nur noch historisch und sollte nicht als aktiver Konfigurationspfad verwendet werden. Git-Commits und -Tags sind ausschließlich Schritte der Quellhistorie. GitHub Actions, GitHub-Releases, GitHub-Asset-URLs, die GitHub-API und die gh-CLI sind nicht Teil der CMS-Update-Veröffentlichung, und .github-Workflows fehlen absichtlich.

Installierte CMS-Arbeitskopien sind Update-Konsumenten. Sie dürfen bei Bedarf die Quellhistorie abrufen, dürfen aber nicht ins Upstream-Repository pushen oder CMS-Updates aus einem Installations-Checkout veröffentlichen.

Kontaktformular-Einsendungen werden vor der Benachrichtigungszustellung gespeichert. Der E-Mail-Benachrichtigungsstatus spiegelt nur das Benachrichtigungsverhalten wider und ändert weder den redaktionellen Status noch die Spam-Klassifizierung. Sent bedeutet, dass Laravel den Versand über einen konfigurierten echten Mail-Transport ohne Exception akzeptiert hat; es garantiert keine Zustellung in den Posteingang. Failed bedeutet, dass ein echter Versand versucht wurde und einen bereinigten Fehler ausgelöst hat. Skipped oder Not configured bedeutet, dass kein echter Versand versucht wurde, weil die Benachrichtigung deaktiviert war, kein Empfänger aufgelöst werden konnte, der Mailer log, array oder null ist oder die SMTP-Konfiguration unvollständig ist. Als Spam bewertete Einsendungen werden absichtlich für die Admin-Prüfung gespeichert/quarantänisiert; nur Einsendungen mit ausgefülltem generiertem Prüffeld oder zu schnell abgesendete Einsendungen dürfen vor der Speicherung mit der generischen Erfolgsweiterleitung verworfen werden. Ein zukünftiger konfigurierbarer Schwellenwert wie CONTACT_SPAM_AUTO_DISCARD_SCORE kann in Betracht gezogen werden, sobald genügend Produktionsdaten vorliegen, um ihn sicher abzustimmen.

Empfänger von Kontaktformular-Benachrichtigungen werden in dieser Reihenfolge aufgelöst:

1. Kontaktformular-Block recipient_email
2. Standard-Kontaktempfänger der Site aus Site -> Edit -> Contact
3. .env CONTACT_RECIPIENT_EMAIL
4. sicherer MAIL_FROM_ADDRESS-Fallback

Typische Laravel-SMTP-.env-Einstellungen sind:

Leeren Sie nach dem Bearbeiten der .env-Mail-Einstellungen auf einer Produktions- oder Paketinstallation bei Bedarf die gecachte Konfiguration:

Verwenden Sie den geheimnisfreien Mail-Diagnosebefehl, wenn eine Kontaktnachricht einen Benachrichtigungsfehler anzeigt:

Der Befehl meldet den aufgelösten Mailer, Host, Port, die Schema-/Verschlüsselungsfelder, den Benutzernamen, die Absenderadresse, CONTACT_RECIPIENT_EMAIL, den Zustand des Konfigurations-Caches sowie optionale Empfänger-Fallbacks aus Kontaktformular-Block/Site. Er gibt niemals MAIL_PASSWORD oder Token-Werte aus. Der optionale Versandtest meldet nur Erfolg oder ein bereinigtes Fehlerdetail, sodass Operatoren veraltete Konfiguration, Host-/Port-/Verschlüsselungs-Unstimmigkeiten, Benutzername-/Absender-Unstimmigkeiten und ungültige Postfach-Zugangsdaten unterscheiden können, ohne Geheimnisse in Terminalprotokolle zu leaken.

Verwenden Sie die Kontaktnachrichten als maßgebliche Quelle für gespeicherte Einsendungen und den Benachrichtigungsstatus. Entwicklungs-Mailer wie log, array und null sollten in Betriebsberichten nicht als zugestellte E-Mails behandelt werden.

Betrieblicher Smoke-Test:

1. Veröffentlichen Sie eine Seite mit dem nativen contact_form-Block oder zeigen Sie sie in der Vorschau an.
2. Senden Sie eine Testnachricht ab.
3. Bestätigen Sie, dass die Nachricht unter /webadmin/contact-messages erscheint.
4. Prüfen Sie den Benachrichtigungsstatus und das sichere Fehlerdetail.
5. Führen Sie php artisan contact:mail-diagnose --block=ID aus, wenn die Empfängerauflösung unklar ist.
6. Führen Sie php artisan contact:mail-diagnose --send-test=operator@example.com nur für eine kontrollierte SMTP-Versandprüfung aus.

WebBlocks UI Manager ist ein internes/Operator-Plugin für produktspezifische Release-Operationen. Es ist nicht in normale CMS-Laufzeitpakete gebündelt, und gewöhnliche CMS-Installationen sollten es nicht installieren. Erstellen Sie sein lokales Artefakt aus dem Wartungs-Repository mit:

Laden Sie das erzeugte ZIP als Super-Admin über System -> Plugins hoch, prüfen Sie die Detailansicht des installierten Plugins und aktivieren Sie es anschließend explizit. Hochgeladene Plugins werden standardmäßig deaktiviert installiert. Deaktivierte oder inkompatible Installationen bleiben inaktiv, und der Zustand wird im deaktivierten Zustand nicht geprüft.

Wenn das Plugin Migrationen deklariert, bedeutet die Aktivierung nicht, dass die Einrichtung abgeschlossen ist. Die Plugin-Detailansicht zeigt Setup required / Plugin migrations pending, wenn plugineigene Tabellen fehlen. Verwenden Sie die Super-Admin-Aktion Run Plugin Migrations in der Plugin-Detailansicht, um nur die von diesem installierten Plugin deklarierten Migrationen und nur aus dem Plugin-Installationspfad auszuführen. Die Aktion ist idempotent, protokolliert ein Einrichtungsergebnis in der Datei für den Aktivierungszustand des Plugins und meldet geheimnisfreie Fehler. Aktivierte Plugin-Routen, die vor der Einrichtung sichtbar sind, müssen kontrollierte Einrichtungshinweise statt roher Datenbankfehler anzeigen.

Wenn eine Installation kurzzeitig v1.32.67 ausgeführt und webblocks_ui_manager_*-Tabellen erstellt hat, löscht dieser Patch sie nicht automatisch. Auch die manuelle Plugin-Deinstallation bewahrt plugineigene Tabellen. Lassen Sie sie bestehen, sofern nicht ein Operator bestätigt hat, dass das Plugin nicht benötigt wird, und eine separate manuelle Datenbankbereinigung mit Backup durchführt.

Wenn das Plugin manuell installiert, aktiviert und eingerichtet wurde, fügt es /webadmin/plugins/webblocks-ui-manager/releases für WebBlocks-UI-Release-Metadaten, Dry-Run-Validierung und lokales statisches CDN-Publishing hinzu. CMS-Benutzer mit der Rolle super_admin können aktivierte Plugin-Routen über die im Manifest deklarierten plugineigenen Berechtigungen öffnen; Rollen ohne Super-Admin-Rechte benötigen explizite Plugin-Berechtigungszuweisungen. Wenn webblocks_ui_manager_releases, webblocks_ui_manager_artifacts oder webblocks_ui_manager_publish_runs fehlt, zeigt der Releases-Bildschirm Hinweise zur erforderlichen Einrichtung und verlinkt zurück zur Plugin-Einrichtung, statt fehlende Tabellen abzufragen. Bereiten Sie ein Release mit lokalen WebBlocks-UI-Dist-Dateien vor:

Der Befehl protokolliert Release-Metadaten, berechnet SHA-256-Prüfsummen und bereitet Manifest-Metadaten für die First-Party-Statik-Konvention public/cdn/webblocks-ui/{version}/... vor. Die erwarteten Dist-Dateien werden über webblocks-plugins.webblocks_ui_manager.expected_dist_files konfiguriert und sind standardmäßig webblocks-ui.css, webblocks-icons.css und webblocks-ui.js.

Validieren Sie den Publish-Plan, ohne Dateien zu schreiben:

Wenden Sie das lokale Publishing an, nachdem die Dry-Run-Validierung bestanden wurde:

Der Publish-Workflow validiert vor dem Schreiben Quellpfade, die Übereinstimmung von Version und Zielpfad, erwartete Dist-Dateien, gespeicherte Prüfsummen, Manifest-Konsistenz und Idempotenz. Vorhandene Dateien mit übereinstimmenden Prüfsummen werden übersprungen. Vorhandene Dateien mit abweichenden Prüfsummen blockieren das Publishing. Das Ziel ist über WEBBLOCKS_UI_MANAGER_CDN_BASE_PATH=cdn/webblocks-ui standardmäßig lokal/projekteigen; WEBBLOCKS_UI_MANAGER_CDN_BASE_URL ist optionale Anzeige-/URL-Metadaten. Der Workflow stellt weder auf einen externen Produktionsserver bereit noch veröffentlicht er Update-Server-Metadaten oder ändert die WebBlocks-UI-Asset-URLs des CMS-Kerns.

System -> Plugins meldet die Zustände deaktiviert, aktiviert, inkompatibel, fehlende Dateien und Fehler getrennt voneinander. Deaktivierte Plugins zeigen einen inaktiven Zustand, keinen Fehler. Ein als aktiviert konfiguriertes, aber inkompatibles Plugin bleibt inaktiv: Keine Plugin-Routen, -Befehle, -Menüs, -Berechtigungen, -Einstellungsrouten, -Widgets, -Assets, -Blockdeklarationen oder Health-Reporter-Verhalten werden aktiv.

Die manuelle Deinstallation ist nur für manuell hochgeladene Plugins verfügbar, nachdem sie deaktiviert wurden. Sie entfernt das im Storage liegende Verzeichnis des installierten Pakets und die Datei für den Aktivierungszustand, niemals CMS-Kerndateien, öffentliche /cms-Assets, Projektdateien, Vendor-Dateien oder Storage außerhalb des konfigurierten Plugin-Stammverzeichnisses. Sie führt keine destruktiven Migrationen aus und löscht keine plugineigenen Datenbanktabellen.

Externes Produktions-CDN-Deployment, Smoke-Checks für gehostete CDNs, generisches Installations-/Updateverhalten von Drittanbieter-Plugins, beliebige Remote-Installer, Composer-Paketinstallation, Update-Server-Veröffentlichung sowie Marketplace-/Katalog-Abläufe bleiben bewusst zurückgestellt.

Backup / Wiederherstellung ist das Wiederherstellungswerkzeug auf Umgebungsebene.

Backups können enthalten:

• Datenbank-Dump
• vom CMS verwaltete Uploads aus storage/app/public
• Archiv-Metadaten in manifest.json

Das Wiederherstellungsverhalten ist explizit definiert:

• nur abgeschlossene Backups mit einem gültigen Archiv können wiederhergestellt werden
• Archiv-Download, Detailansicht, Wiederherstellungsberechtigung und Löschaktionen lösen Pfade über dieselbe backups-Disk-Wurzel auf und blockieren Pfad-Traversal, Symlink-Ausbrüche und absolute Pfade außerhalb dieser Wurzel
• fehlende oder nicht lesbare Archivdateien werden als kontrolliertes Admin-Feedback statt als rohe Dateisystem-Exceptions angezeigt
• die Wiederherstellung erstellt zuerst ein frisches Sicherheits-Backup vor der Wiederherstellung
• die Wiederherstellung ersetzt die aktuelle Datenbank
• die Wiederherstellung ersetzt storage/app/public, wenn Uploads im Archiv enthalten sind
• MySQL-/MariaDB-Wiederherstellungen führen den Import mit temporär deaktivierten Fremdschlüssel- und Unique-Prüfungen aus, sodass gültige Voll-Dumps auch dann portabel bleiben, wenn sich die Reihenfolge der Tabellenerstellung zwischen Umgebungen unterscheidet
• bestehende Installationen, die über System Update aktualisiert werden, führen bei Bedarf auch paketeigene Reparatur-Migrationen aus; dadurch bleiben Schema-Verträge wie der Elternschlüssel pages(id, site_id) mit Backups abgeglichen, die site-bezogene page_translations-Fremdschlüssel enthalten

Verwenden Sie Backup / Wiederherstellung, wenn Sie die Installationsumgebung wiederherstellen müssen, nicht nur eine einzelne Seite.

Export / Import ist das Werkzeug für Site-Portabilität.

Verwenden Sie es, um die Inhalte einer Site zwischen Installationen zu verschieben.

Site-Transferpakete werden auf der Laravel-Dateisystem-Disk namens site-transfers gespeichert, die standardmäßig auf storage/app/site-transfers zeigt. Frische Composer-Consumer-Installationen registrieren diese Disk automatisch, und webblocks:install bereitet das Speicherverzeichnis vor, sodass Host-Anwendungen config/filesystems.php nur bearbeiten müssen, wenn sie eine eigene Disk bereitstellen möchten.

Site-Importe setzen voraus, dass die datenbankgestützten Blocktyp- und Slottyp-Kataloge der Zielinstallation die vom Paket referenzierten Zeilen enthalten. Frische Composer-Installationen befüllen diese Kataloge während webblocks:install, eine explizite Katalogpflege kann mitgelieferte Zeilen mit webblocks:catalog-repair reparieren, und der Import-Runner führt vor der Validierung eine abschließende idempotente Synchronisierung des Kernkatalogs durch, wenn ein Paket eine fehlende mitgelieferte Kernzeile referenziert. Referenziert ein Paket einen installationsspezifischen benutzerdefinierten Block oder Slot, der auf dem Ziel nicht vorhanden ist, listet die Admin-Fehlermeldung die genauen fehlenden Bezeichner auf.

Der Admin-Workflow hat jetzt zwei zusammengehörige Einstiegspunkte:

• Admin -> Sites enthält pro Site eine Export-Zeilenaktion, die ein Modal für die ausgewählte Site öffnet, den Site-Namen und das Handle anzeigt und Mediendateien einschließen kann, bevor das Paket erstellt wird.
• Admin -> Maintenance -> Export / Import ist der kombinierte operative Bildschirm für Transferhistorie und Transferaktionen. Er zeigt Site Exports und Site Imports zusammen an, mit den Aktionen Run Export und Run Import in den Kopfzeilen der jeweiligen Listenkarten.
• Der Import-Prüfbildschirm hält die Aktion für das validierte Paket direkt unter der Status- und Manifest-Zusammenfassung und zeigt anschließend die Paketzähler in einer kompakten Tabelle für schnelleres Überfliegen.
• Frische Composer-Consumer-Installationen rendern die Export-/Import-Bildschirme aus dem View-Namespace des Pakets, sodass sie keine Root-Blade-Dateien unter resources/views/admin/site-transfers/* benötigen.

Beziehung zwischen den Werkzeugen:

• Die Export-Zeilenaktion unter Sites erstellt ein Paket für eine ausgewählte Site und kehrt mit einer Erfolgsmeldung zur Sites-Liste zurück.
• Export / Import verwaltet die Pakethistorie und den zentralen Export- bzw. Import-Betriebsbildschirm.
• Sites -> Promote wendet ein Export- oder Promotion-Paket mit Dry-Run, Strategie, Sicherheits-Backup und Erhaltungsregeln auf eine bestehende Ziel-Site an.

Export / Import deckt site-bezogene Inhalte ab, etwa:

• Site-Datensatz und Sprach-Zuweisungen (Locales)
• in site_variables gespeicherte Site-Variablen
• Seiten und Seitenübersetzungen
• in page_assets gespeicherte Seiten-Assets
• Slots und Blöcke
• Shared Slots und Shared-Slot-Blockbäume
• Page-Layout-Einstellungen auf Seitenebene wie default und docs (intern weiterhin auf public_shell gespeichert)
• Blockübersetzungen
• Navigationselemente, einschließlich optionaler Icon-Slugs von Navigationselementen, die von öffentlichen Sidebar-Navigation-Renderern verwendet werden
• optionale Mediendateien
• kanonische öffentliche Override-Dateien auf Site-Ebene unter public/site/{site_handle}/css/site.css und public/site/{site_handle}/js/site.js, wenn Include media files aktiviert ist und diese Dateien existieren

Page Assets durchlaufen die Site-Portabilität in zwei Schichten:

• page_assets-Zeilen sind immer in den Export- und Import-Payloads der Site enthalten.
• Wenn Include media files aktiviert ist, werden referenzierte öffentliche /site/...-Dateien ebenfalls im Exportarchiv verpackt und beim Import wieder nach public/site/... zurückgespielt.
• Wenn Include media files deaktiviert ist, werden die Metadaten der Seiten-Assets trotzdem importiert, die referenzierten physischen Dateien müssen jedoch auf der Zielinstallation bereits vorhanden sein.
• Fehlende Seiten-Asset-Dateien werden beim Export gemeldet und in der aktuellen Version übersprungen, statt den gesamten Paketbau abstürzen zu lassen.

Öffentliche Override-Assets auf Site-Ebene sind bewusst enger gefasst als Page Assets: Nur css/site.css und js/site.js unter dem Handle der Quell-Site werden einbezogen, und der Import stellt sie unter dem endgültigen Handle der Ziel-Site wieder her. Beliebige public/site/...-Bäume, CMS-Kern-Assets und public/storage sind nicht Teil dieses Pfads.

Shared Slots werden als vollwertige Site-Inhalte exportiert und importiert:

• Shared-Slot-Metadaten wie Handle, Name, Slot-Kompatibilität, Shell-Kompatibilität und Aktivstatus sind im Paket enthalten.
• Shared Slots können außerdem eine optionale Page-Layout-Kompatibilitätsbeschränkung tragen. Das gespeicherte Feld bleibt aus Gründen der Abwärtskompatibilität public_shell, ein leerer Wert bleibt generisch, und nicht leere Werte erfordern weiterhin exakte Übereinstimmungen des Page-Layout-Handles.
• Shared-Slot-Blockbäume, verschachtelte Reihenfolge, Übersetzungen und Medienreferenzen durchlaufen dieselbe Block- und Medien-Verpackungspipeline wie normale Seiten.
• Seiten-Slots, die shared_slot verwenden, exportieren eine stabile Shared-Slot-Handle-Referenz und werden beim Import dem importierten Shared Slot der Ziel-Site neu zugeordnet.
• Seiten-Payloads bewahren das Page Layout jeder Seite, sodass Seiten mit Docs-Shell nach dem Import kompatible Docs-Shared-Slot-Zuweisungen behalten.
• Page-Layout-Definitionen und Page-Layout-Slot-Definitionen auf Installationsebene selbst sind in V1 nicht Teil des Site-Exports/-Imports.
• Benutzerdefinierte public_shell-Handles von Seiten werden weiterhin mit dem Seiten-Payload übertragen; Zielinstallationen sollten daher passende Page-Layout-Handles bereitstellen, wenn sie auf benutzerdefinierte Layouts angewiesen sind.
• Existiert ein passendes Page-Layout-Handle auf der Zielinstallation nicht, fällt das öffentliche Rendering sicher zurück.
• Versteckte Shared-Slot-Quellseiten bleiben intern und werden im Paket nicht wie gewöhnliche nutzerseitige Seiten behandelt.
• Die Revisionshistorie von Shared Slots ist vom Export/Import ausgeschlossen, entsprechend der aktuellen Portabilitätsgrenze für Seitenrevisionen.

Site-Variablen sind ebenfalls portable Site-Inhalte:

• site_variables-Zeilen werden mit dem Site-Paket exportiert und importiert.
• Variablenschlüssel, Beschriftungen, Werte, Sortierreihenfolge und Aktivierungsstatus bleiben erhalten.
• Das öffentliche Token-Verhalten wird beim Export oder Import nicht ausgewertet; Rohwerte werden so übertragen, wie sie gespeichert sind.

Nicht enthalten sind installationsweite Laufzeitdaten wie Benutzer, Backups, Update-Historie, Sitzungen oder Kontaktformular-Einsendungen.

Der abgeleitete öffentliche Suchindex wird ebenfalls nicht als portabler Inhalt benötigt:

• public_search_index sind zur Laufzeit abgeleitete Daten
• Export-/Import-Payloads benötigen keine Suchzeilen, um die Site wiederherzustellen
• verwenden Sie nach dem Import php artisan search:rebuild, wenn Sie sofort frische Suchzeilen benötigen

Der Einzelseiten-JSON-Import ist der seitenbezogene Admin-Workflow zum Erstellen einer neuen Seite aus einer JSON-Datei.

• Admin-Pfad: Admin -> Pages -> Import Page
• Umfang: eine neue Seite in einer ausgewählten Site
• Schema: webblocks.cms.page.v1
• Ergebnis: erstellt in V1 immer eine neue Entwurfsseite
• aktualisiert in V1 keine bestehende Seite
• importiert keine Revisionshistorie der Quellseite
• ersetzt nicht den Site-weiten Export / Import-Workflow

Was V1 importiert:

• Kernfelder der Seite, die für die Entwurfserstellung benötigt werden, einschließlich des Page Layouts auf Seitenebene
• Seitenübersetzungen, nach Locale-Code für aktivierte Sprachen (Locales) der Ziel-Site
• Seiten-Slots, einschließlich shared_slot-Referenzen über kompatible Shared-Slot-Handles derselben Site
• seiteneigene Blockbäume mit verschachtelter Eltern-Kind-Reihenfolge
• unterstützte Blockübersetzungszeilen für übersetzte Blockfamilien
• Seiten-Asset-Metadaten für gültige lokale /site/...-CSS- und -JS-Pfade

Einschränkungen in V1:

• Konflikte bei übersetzten Pfaden der Ziel-Site blockieren den Import vor jeglichen Schreibvorgängen
• Shared-Slot-Referenzen müssen auf der Ziel-Site bereits existieren und hinsichtlich Site, Aktivstatus, Shell und Slot-Name kompatibel sein
• der Importer erstellt Shared Slots nicht automatisch
• nicht unterstützte Schemawerte werden explizit abgelehnt
• der Importer ist transaktional und hinterlässt keine unvollständige Seite, wenn die Validierung fehlschlägt

Siehe docs/examples/page-import-v1.json für das Beispiel-Payload.

Site-Promotion ist der paketbasierte Workflow, um site-eigene Inhalte aus einem Quellpaket in eine bestehende Ziel-Site zu befördern.

Verwenden Sie sie, wenn:

• die Ziel-Site bereits existiert
• site-eigene Inhalte kontrolliert in diese Site befördert werden müssen
• Daten auf Installationsebene, umgebungsspezifische Daten und Live-Laufzeitdaten erhalten bleiben müssen

Unterschiede zu den anderen Werkzeugen:

• Export / Import erstellt oder verwaltet Site-Transferpakete und erstellt standardmäßig eine neue lokale Site aus einem Paket
• Site-Promotion wendet Paketinhalte auf eine bestehende Ziel-Site an
• Site-Klonen dupliziert site-eigene Inhalte innerhalb der aktuellen Installation ohne Paket
• Backup / Wiederherstellung ist Umgebungswiederherstellung und kann die aktuelle Datenbank oder Uploads ersetzen
• Updates ändern den CMS-Produktcode und die installierte Version, nicht die site-eigenen Inhalte

V1-Workflow:

• Admin-Pfad: Admin -> Sites -> Promote
• Befehle: site-promotion:inspect, site-promotion:dry-run, site-promotion:apply
• vor dem Anwenden ist ein Dry-Run erforderlich
• das Anwenden erstellt zuerst ein normales Sicherheits-Backup
• das Anwenden baut nach Erfolg die abgeleiteten Suchzeilen der Ziel-Site neu auf

Zu den erhaltenen Bereichen gehören:

• Benutzer und Rollen
• Sitzungen, Cache, Jobs und Queues
• Backups und Update-Historie
• Besucherberichte und Kontaktformular-Einsendungen
• Live-Domains und Site-Domain-Datensätze
• Umgebungskonfiguration, Installationsgeheimnisse und interne Tokens
• abgeleitete public_search_index-Zeilen

Unterstützte Strategien:

• additive_update: erstellt fehlende Quellinhalte und aktualisiert passende Zielinhalte, ohne zusätzliche Zielinhalte zu entfernen
• mirror: erstellt und aktualisiert passende Quellinhalte und archiviert, deaktiviert oder entfernt anschließend nicht vorhandene site-eigene Zielinhalte, wo dies in V1 sicher ist

Installationsspezifische Migrations- und Website-Import-Workflows gehören in project/, nicht in den CMS-Kern.

Search V1 fügt einen operativen Bildschirm auf Installationsebene und einen Befehl für den abgeleiteten öffentlichen Suchindex hinzu.

• Admin-Bildschirm: Admin -> Maintenance -> Search Rebuild
• Rebuild-Befehl: php artisan search:rebuild

Der Bildschirm Search Rebuild prüft die Abdeckung des abgeleiteten öffentlichen Suchindex für veröffentlichte Seiten nach Site und Sprache (Locale) und kann den Index sicher neu aufbauen, wenn abgeleitete Zeilen aufgefrischt werden müssen.

Unterstützte Rebuild-Bereiche:

• gesamte Installation
• eine Site mit --site=
• eine Sprache (Locale) mit --locale=
• eine Seite mit --page=

Der Such-Rebuild ist nicht destruktiv:

• er löscht und erstellt nur abgeleitete Zeilen innerhalb des angeforderten Bereichs neu
• er verändert keine Seiten-, Block-, Übersetzungs-, Shared-Slot- oder Medieninhalte
• er erfordert keine destruktiven Datenbank-Reset-Befehle

Systemeinstellungen ist der kompakte Konfigurationsbildschirm auf Installationsebene. Editierbare Gruppen sind in separate fokussierte Karten mit eigenen Speicheraktionen aufgeteilt; die Laufzeitinformationen sind schreibgeschützt.

Er umfasst:

• Projektname und Projekt-Tagline für den nur im Admin sichtbaren Installationskontext
• Standard-Sprache (Locale)
• Zeitzone
• Zeilen pro Seite für paginierte Admin-Listenbildschirme
• CMS-Mail-Modus und benutzerdefinierte Mail-Einstellungen für CMS-eigene Benachrichtigungen
• Einstellungen für Cookie- bzw. Datenschutzbanner
• Produktversionsinformationen
• Umgebungsinformationen

Er steuert nicht:

• die festen Admin-Markenbeschriftungen von WebBlocks CMS
• das öffentliche Site-Branding
• die öffentlichen SEO-Standardwerte der Site
• öffentliches Favicon, öffentlichen Suchumfang oder SEO der Seitenübersetzungen
• Host-/Root-Auth-Mail oder das Routing des Site-Kontaktformulars
• Inhalte der .env-Datei oder Umgebungsvariablen

Die Projektidentität hilft, eine CMS-Installation in der Admin-Topbar und im Browsertitel von einer anderen zu unterscheiden. Diese öffentlich sichtbaren Werte liegen weiterhin auf der jeweiligen Site oder Seitenübersetzung.

Admin listing rows per page hat den Standardwert 15, akzeptiert benutzerdefinierte numerische Werte wie 10 oder 12 und ändert nur die Standard-Zeilenanzahl paginierter Admin-Listenbildschirme. Die öffentliche Paginierung ist davon nicht betroffen.

CMS Mail verwendet standardmäßig die Laravel-Umgebungs-Mailkonfiguration. Wird der Modus auf benutzerdefinierte CMS-Einstellungen umgestellt, verwenden CMS-eigene Passwort-Reset-E-Mails und künftige CMS-eigene Systembenachrichtigungen die datenbankgestützten CMS-Mail-Einstellungen über einen abgegrenzten CMS-Mailer. Benutzerdefinierte Mail-Felder werden nur angezeigt, wenn der benutzerdefinierte CMS-Mail-Modus ausgewählt ist. Benutzerdefinierte CMS-Mail-Einstellungen überschreiben .env nicht; wird die benutzerdefinierte CMS-Mail deaktiviert, kehrt die CMS-Mail zur bestehenden Laravel-MAIL_*-Konfiguration zurück. Gespeicherte Mail-Geheimnisse werden nie im Klartext angezeigt, leere Geheimnis-Updates behalten den vorhandenen gespeicherten Wert bei, und die Diagnose meldet sensible Felder nur als konfiguriert oder nicht konfiguriert. Die benutzerdefinierte SMTP-Diagnose warnt jetzt, wenn erforderliche Versandeinstellungen unvollständig oder ungültig sind, und Sendefehler bei Passwort-Reset-Mails liefern einen kontrollierten CMS-Mail-Fehler, während nur geheimnisfreier technischer Kontext protokolliert wird. Die Diagnosetabelle enthält eine Super-Admin-Aktion Send Test Email, die eine einfache CMS-Systemnachricht über denselben CMS-Mail-Resolver-Pfad wie CMS-eigene Passwort-Reset-Mails sendet, ohne Geheimnisse, Reset-Tokens oder rohe Konfigurationsdumps einzuschließen.

Site-Klonen dupliziert site-eigene Inhalte von einer Site in eine andere Site innerhalb derselben Installation.

Verwenden Sie Site-Klonen, wenn:

• Sie eine zweite Site innerhalb der aktuellen Installation benötigen
• Sie die Struktur aus Seiten, Slots, Blöcken, Navigation und Sprachen (Locales) duplizieren möchten, ohne zuerst ein Exportpaket zu erstellen
• Sie möchten, dass Shared Slots und Shared-Slot-gestützte Seiten-Slot-Zuweisungen mit der geklonten Site mitwandern

Site-Klonen unterscheidet sich von Export / Import:

• Site-Klonen arbeitet innerhalb der aktuellen Installation
• Export / Import dient dazu, ein Site-Paket zwischen Installationen zu verschieben
• Sowohl Site-Klonen als auch Export / Import umfassen Shared Slots, Shared-Slot-Blockbäume, Übersetzungen, Medienreferenzen und Page-Layout-Einstellungen auf Seitenebene und ordnen konsumierende Seiten-Slots den Shared Slots der Ziel-Site neu zu, statt site-übergreifende Referenzen zurückzulassen
• Sowohl Site-Klonen als auch Export / Import umfassen außerdem site-bezogene site_variables.
• Die Revisionshistorie von Shared Slots wird nicht geklont, entsprechend der aktuellen Klongrenze für Seitenrevisionen.

• eine einzelne Seite wiederhergestellt werden muss
• Sie redaktionelle Wiederherstellung innerhalb der aktuellen Installation benötigen

• die Umgebung wiederhergestellt werden muss
• Datenbank oder Uploads gemeinsam zurückgesetzt werden müssen

• eine Site auf eine andere Installation verschoben werden muss
• Sie ein portables Paket für eine Site benötigen

• Sie eine Site innerhalb derselben Installation in eine andere Site duplizieren müssen
• Sie die Arbeit innerhalb der aktuellen Umgebung halten möchten

• ein veröffentlichtes CMS-Release auf die aktuelle Installation angewendet wird

• Updates, Backups, Wiederherstellung und Site-Transfer-Werkzeuge sind Funktionen auf Installationsebene
• Seiten, Medien, Navigation und redaktioneller Workflow sind primär site-bezogene Inhaltsfunktionen
• Benutzer sind Konten auf Installationsebene, auch wenn manche Rollen auf zugewiesene Sites beschränkt sind
• Release-Paketierung und Erhalt installierter Pfade sind getrennte Anliegen: Releases liefern project/ nicht mit, während installierte project/-Inhalte über Updates hinweg erhalten bleiben