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 enthält die konsolidierte Übersicht neben den vorhandenen operativen Tools:

• Systemzustand
• Suchindex neu aufbauen
• Backups
• Bereinigung
• Export / Import
• Update

Da CMS 1.98.0, Wartung → Systemzustand einen Ort zur Überprüfung der Installation und ihrer Standorte bietet. Für Benutzer mit System Health-Zugriff zeigt das Dashboard eine kompakte Zusammenfassung der Prüfungen an, bei denen Maßnahmen erforderlich sind, die überprüft werden sollten oder die noch nicht überprüft wurden, mit einem Link zur vollständigen Übersicht. Nullzählungen zeigen, dass bei den verfügbaren Prüfungen keine Probleme gefunden wurden. Die Seite beginnt mit Zählungen und den dringendsten Elementen, gefolgt von Karten für System, Sites, Backups, geplante Arbeit, Speicher, Suche, Plugins und Updates. Jedes Element erläutert den nächsten Schritt und enthält Links zum vorhandenen Tool. Technische Details, aktuelle Sicherungs-/Wiederherstellungs-/Aktualisierungsergebnisse und die vorhandenen Systeminformationswerte werden standardmäßig angezeigt.

Die Karte Geplante Benachrichtigungen enthält die detaillierte Planerbenachrichtigung, die Auswirkung auf ausstehende E-Mails, UTC Zeiten für den letzten geplanten Heartbeat und den abgeschlossenen Benachrichtigungslauf, Einrichtungsanweisungen und einen Link zum Installationshandbuch. Durch die Links zur Planungsüberprüfung wird dieser Abschnitt geöffnet und der ausgewählte Site-Filter beibehalten. Standortbetriebsleiter, die nicht auf den Systemzustand zugreifen können, behalten die detaillierte, standortbezogene Planerkarte in ihrem Dashboard und in den Kontakteinstellungen des Standorts. Die Zusammenfassung des Panel-Benachrichtigungseingangs verbleibt im Dashboard.

Die Status unterscheiden zwischen gesund, Prüfung erforderlich, dringend, noch nicht geprüft und nicht anwendbar. Eine nicht verfügbare Prüfung wird nicht als gesund gemeldet. Suchprüfungen vergleichen geeignete veröffentlichte Seiten-/Sprachpaare mit der Indexabdeckung; sie bestätigen nicht die Aktualität des Textes. Backup-Prüfungen erfassen kürzlich erfolgreiche Datensätze und die Verfügbarkeit von Archiven; sie bestätigen nicht die Integrität einer Wiederherstellung. Update-Bereitschaft ist vom Installationszustand getrennt. Die Verfügbarkeit einer Version nutzt ein kürzlich zwischengespeichertes Update-Ergebnis. Öffnen Sie Updates, um eine neue Versionsprüfung anzufordern.

Site-Prüfungen werden fünf Minuten lang zwischengespeichert; Auf dem Bildschirm „Systemzustand“ werden bei jedem Besuch aufgezeichnete Planernachweise angezeigt. Dashboard, Backups und Cleanup zeigen den letzten abgeschlossenen Bericht mit seiner Messzeit an. Sie analysieren Backup SQL beim Öffnen nicht. Fehlende Berichte werden nicht überprüft und alte oder ungültige Berichte werden ausdrücklich als veraltet gekennzeichnet. Die Einstellungen bleiben bis zum ersten Bericht verfügbar. Auf den Registerkarten „Speicher und Verlauf“ und „Bereinigungsaktionen“ von Cleanup werden nicht verfügbare Berichte erläutert und direkt Aktualisierungsprüfungen angeboten. Durch eine Aktualisierung wird zur gleichen Registerkarte zurückgekehrt. Die Schaltfläche „Aktualisieren“ zeigt die Aktivität während der Übermittlung an, und das Ergebnis bestätigt den Abschluss, meldet, dass bereits eine weitere Aktualisierung ausgeführt wird, oder zeigt eine Fehlermeldung an. Systemzustandsaktualisierungen behalten den ausgewählten Site-Filter bei.

Cache-Einträge für Wartungsberichte enthalten versionierte Arrays und Skalarwerte, sodass bei Installationen die Deserialisierung von Cache-Objekten deaktiviert bleiben kann. Aktualisierungsprüfungen bestätigen den Erfolg erst nach dem Zurücklesen des genauen Snapshots, den es geschrieben hat. Ein Fehler bei der Cache-Überprüfung zeigt einen Fehler an und versucht, den zuvor abgeschlossenen Bericht beizubehalten. Fehlende Aufbewahrungsentscheidungen für Backups werden als nicht verfügbare Vorschauen und nicht als Schemaaktualisierungsanforderungen angezeigt. Nach einem Produktupdate wird der erste Bericht für diese Version durch Aktualisierungsprüfungen oder den Planer generiert.

Der Laravel-Planer führt php artisan system:reports:refresh alle fünf Minuten aus. Aktualisierungsprüfungen für den Systemzustand können diese Arbeit auch manuell ausführen. Jeder Aufruf validiert höchstens acht vorhandene Wiederherstellungs-Backup-Archive und aktualisiert dann den gemeinsamen Bericht. Bei einer großen Installation sind möglicherweise mehrere Aufrufe erforderlich, um die Erstvalidierung abzuschließen. Neue Backups und Uploads zeichnen die Validierung auf, wenn sie erstellt werden. Aufgrund der ausstehenden Validierung wird die Berechtigung zur Bereinigung im Panel-Bericht zurückgehalten. Für die automatische Aktualisierung ist ein funktionierender Zeitplaner erforderlich; Beim Öffnen einer Seite wird keine synchrone Aktualisierung gestartet. Zwischengespeicherte Berichte ersetzen niemals die aktuellen Sicherheitsprüfungen, die vor der Bereinigung oder Wiederherstellung durchgeführt werden. Der letzte abgeschlossene Bericht wird bis zu sieben Tage lang aufbewahrt und nach fünf Minuten als veraltet angezeigt. Der Site-Filter schränkt standortbezogene Prüfungen ein und behält gleichzeitig installationsweite Prüfungen bei. Die Übersicht führt keine Bereinigung durch, sucht nicht nach Neuerstellungen, startet keine Sicherungen, installiert keine Updates und erstellt keine Zeitplanungsnachweise. Bestehende Websites und Seiten zur Betriebswartung bleiben weiterhin verfügbar. Aus CMS 1.98.1 wurden der separate Systeminformationsbildschirm und der Link zur Seitenleiste entfernt; Seine neun Laufzeitinformationsfelder verbleiben in System Health → Systemdetails und /webadmin/system/information leitet zu System Health mit derselben Systemzugriffsanforderung weiter. Hilfe ist ein direkter Dokumentationslink zu https://cms.webblocksui.com/docs; Plugin-Ziele, die zuvor zur Hilfe beitrugen, bleiben unter System erreichbar.

Der schreibgeschützte Internal-API-Endpunkt ist GET /webadmin/api/system/health, optional mit site_id. Er erfordert die ausdrücklich erteilte Berechtigung system-health.read für ein uneingeschränktes System-Token, dessen aktiver Ersteller aktuell Systemzugriff hat. Persönliche und auf Sites beschränkte Tokens können den installationsweiten Zustand nicht lesen. Antworten verwenden kontrollierte Meldungen und normalisierte Ergebnisse anstelle von Ausnahmetexten, Vorgangsprotokollen, Archivpfaden oder Plugin-Geheimnissen. Den Antwortvertrag beschreibt die Internal Content API.

Besucherberichte bieten betriebliche Zusammenfassungen der Aktivitäten auf öffentlichen Seiten. Für einfache Seitenaufrufdatensätze sind keine einwilligungsbasierten Identifikatoren erforderlich. Zu den Datensätzen gehören reduzierte Referrer-, Kampagnen-, Geräte- und Bot-Informationen:

• 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.

Ab CMS 1.105.26 zeigt der Fortschrittsdialog eine übersetzte aktuelle Phase an, während die Ausführung bestätigt wird. Der Titel identifiziert die Zielversion, ohne darauf hinzuweisen, dass die Arbeit nach Abschluss noch ausgeführt wird. Wenn die Verfolgung stoppt oder das Ergebnis endgültig wird, verschwinden die Phase, die Fortschrittsanzeige und der Wartehinweis gleichzeitig. Die verstrichene Zeit und das Ergebnis bleiben sichtbar. Bei bestätigtem Erfolg wird automatisch auf Updates zurückgegriffen. Fehler- oder wiederhergestellte Backup-Ergebnisse bleiben zur Überprüfung verfügbar. Unbekannte Phasenbezeichner verwenden einen lesbaren Fallback anstelle eines Übersetzungsschlüssels.

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-Aktualisierungsablauf ist mit einem Klick erledigt. Eine einzelne Update to X-Aktion lädt das Release-Paket herunter, erstellt eine automatische Sicherung vor dem Update, wendet Regeln für geschützte Pfade an, führt erforderliche Paket-Update-Migrationen aus, löscht Caches, überprüft die angewendete WebBlocks CMS Codeversion anhand der Zielversion, zeichnet die Update-Ausführung auf und behält die installierte Version bei. Wenn die Anwendung fehlschlägt, stellt der Updater automatisch die Sicherung vor dem Update wieder her und zeichnet den Lauf mit dem Status restored auf; Wenn auch die automatische Wiederherstellung fehlschlägt, wird der Lauf als failed mit beiden Fehlerpfaden aufgezeichnet. Bei der manuellen Wiederherstellung verbleibt die Sicherung vor dem Update zum Herunterladen und Wiederherstellen auf dem Bildschirm „Sicherungen“ und php artisan system:backup:restore führt eine CLI Wiederherstellung durch.

Maintenance → Cleanup besitzt installationsweite Aufbewahrungsrichtlinien. Die folgenden Lebenszykluskontrollen sind in CMS 1.105.12 verfügbar.

Vorhandene gespeicherte Richtlinien, einschließlich 30-tägiger Wiederherstellungssicherheitsaufbewahrung, bleiben unverändert. Alters- und Mindestanzahlschutz gelten gemeinsam. Nur verfügbare, strukturell validierte, unterschiedliche physische Archive zählen zur Mindestanzahl gültiger erfolgreicher Archive eines Typs. Ein abgelaufenes Backup kann durch diese Mindestanzahl geschützt bleiben. Ausgefallene/fehlende Archive ersetzen keine gültigen Wiederherstellungspunkte. Laufende Backups und Wiederherstellungspunkte, die mit kürzlich fehlgeschlagenen/wiederhergestellten Updates verknüpft sind, bleiben geschützt.

Verwenden Sie das Schloss-/Einstellungssymbol bei Backups, um die Markierung Geschützt eines Archivs und seinen Modus policy, never oder expires zu verwalten. Der Schutz blockiert das einmalige, erzwungene und Massenlöschen, bis er entfernt wird. Der unbestimmte Modus verhindert den automatischen Ablauf, ermöglicht aber dennoch das explizite Löschen. Wenn Sie ein Datum auswählen, wird dieses Archiv explizit für die Bereinigung ausgewählt, einschließlich manueller und hochgeladener Archive. Es gelten weiterhin Schutz und erfolgreiche Mindestanzahlen. Die Termine richten sich nach der Zeitzone der Anwendung. Der manuelle Erstellungsdialog zeichnet den ausgewählten Schutz/Aufbewahrung vor der Erfassung auf SQL.

Das optionale Budget wird in GiB (1024³ Bytes) gemessen, ist standardmäßig nicht festgelegt, gibt eine Warnung bei 80 % aus und meldet eine Überschreitung bei 100 %. Es setzt niemals den Schutz oder die Aufbewahrung außer Kraft. Sicherungen und Bereinigungen zeigen den gesamten physischen Speicher, explizit geschützte Bytes, berechtigte Bytes, den geschätzten Speicher nach der Bereinigung und alle verbleibenden Überschreitungen. Nicht registrierte Dateien werden auf die Festplattennutzung angerechnet, aber nie automatisch ausgewählt. Teilweise/nicht verfügbare Messungen sind explizit. Ein freigegebenes Archiv wird nicht mehrfach gezählt und das Löschen eines Datensatzes hebt niemals die Verknüpfung mit der Datei eines anderen Datensatzes auf.

Speichererklärung (CMS 1.105.13): Die Sicherungsaufbewahrungskarte in der Registerkarte „Speicher und Verlauf“ der Bereinigung und die Liste „Sicherungen“ fügen eine Ursachentabelle hinzu. Es zeigt die Anzahl der Sicherungsdatensätze, die Anzahl der einzelnen physischen Dateien und die gemessenen Bytes für den Mindestanzahlschutz, Aufbewahrungsfristen, expliziten Schutz, unbegrenzte Aufbewahrung, deaktivierte manuelle Bereinigung und andere aktuelle Entscheidungen an. Geeignete Archive werden separat angezeigt. Sowohl Alters- als auch Mindestanzahlregeln schützen Backups. „Das neueste N behalten“ ist eine Untergrenze und keine Obergrenze für die Gesamtzahl der behaltenen Daten.

Freigegebene Archivdateien tragen einmal Bytes unter dem ersten anwendbaren Grund in der Tabelle bei. Die Datensatzanzahl richtet sich weiterhin nach dem Status jedes Datensatzes, sodass ein Grund möglicherweise Datensätze ohne zusätzliche physische Bytes enthält. Andere Dateien im Backup-Speicher, einschließlich Sperr- oder Supportdateien, werden separat angezeigt und nie automatisch entfernt. Bei einem Teilscan werden bekannte Archivgrößen mit unbestätigten Gesamtwerten und andere Dateigrößen als nicht verfügbar angezeigt. Die vorhandene Backup-Bereinigung API enthält die gleiche Aufschlüsselung unter preview.overview.reason_summary.

Die Backup-Bereinigung wird täglich bei 03:30 unter der vorhandenen aktivierten Einstellung ausgeführt. Das Paket ruft nach einem erfolgreichen Update keine Backup-Bereinigung auf; Für die automatische Ausführung ist ein funktionierender Host-Scheduler erforderlich. Vorschau mit php artisan system:backups:cleanup --dry-run -v; Bei der normalen Ausführung wird dieselbe Richtlinie verwendet. --force umgeht nur die aktivierte Einstellung. Es umgeht niemals Schutz, Mindestanzahl oder aktive Vorgänge. Der Scheduler-Aufruf fügt --scheduled hinzu, um seine Quelle aufzuzeichnen. Bei schreibgeschützten Vorschauen werden kein Ausführungsverlauf oder Festplattenwurzeln erstellt. Abgeschlossene Läufe zeichnen ein begrenztes SQL Ergebnis mit tatsächlich gelöschten Bytes auf.

Eine gemeinsame, nicht blockierende Dateisystem-Lease serialisiert die Erstellung, das Hochladen, die Wiederherstellung, Aufbewahrungsänderungen und das Löschen von Backups. Es überlebt die SQL-Wiederherstellung und wird beim Beenden des Prozesses freigegeben. Dateisysteme für gemeinsam genutzte Sicherungen müssen empfohlene Dateisperren unterstützen. Aktuelle Paketmigrationen sind erforderlich. Die Wiederherstellungswartung repariert das additive Aufbewahrungs-/Zusammenfassungsschema, wenn ein älterer SQL Snapshot älter ist.

Die interne API behält GET/PUT /webadmin/api/system/backup-cleanup mit backups.read / backups.settings.write und den löschenden POST /webadmin/api/system/backup-cleanup/run mit backups.delete bei. Die ursprünglichen Richtlinienfelder bleiben erforderlich; optionale Lebenszyklusfelder ändern nur übermittelte Werte, ausgelassene Werte bleiben erhalten. Null bei budget_gb entfernt das Budget. GET/PUT /webadmin/api/system/backups/{backup}/retention liest oder setzt Schutz und Ablauf mit denselben getrennten Lese-/Einstellungsschreibrechten. Erforderliche Felder und gültige Modi stehen im API-Discovery-Vertrag. Die Auslagerung in entfernten Speicher bleibt eine spätere Phase.

Der Arbeitsbereich „Bereinigung“ zeigt physische Dateizahlen und Bytes für Systemsicherungen, Export-/Importpakete, öffentliche Uploads mit Ausnahme generierter Varianten, generierte Varianten, bekannte temporäre Arbeitsbereiche, Asset-Revisionsdateien, öffentliche Site-Dateien und Standardanwendungsprotokolle. Die Messungen sind mit einem Zeitstempel versehen und unterscheiden fehlende Verzeichnisse, Teilscans und nicht verfügbaren Speicher. Sie messen weder das Hosting-Kontingent noch die zugewiesenen Datenbanktabellen. Benutzerdefinierte Protokollspeicherorte sind ausgeschlossen; Gemeinsam genutzte Festplattenstämme können dazu führen, dass sich Kategorien überschneiden. Fügen Sie sie daher nicht zu einer installationsweiten Quotenzahl hinzu. Vorhandene Revisionsgrößen pro Standort beschreiben die logischen Snapshot-Nutzlasten separat. Eine nicht verfügbare Bereinigungsvorschau wird explizit angezeigt.

Die fünf Wartungskategorien sind asset-revisions, media-variants, temporary-workspaces, page-revisions und shared-slot-revisions. Bei Asset-Revisionen bleiben standardmäßig mindestens 90 Tage Verlauf und die neuesten 20 Revisionen je Asset geschützt. Für temporäre Arbeitsbereiche gelten standardmäßig 24 Stunden. Bei Seiten- und Shared-Slot-Revisionen bleiben mindestens 90 Tage Verlauf und die neuesten 50 Revisionen je Eigentümer geschützt; aktive Quellen einer Revisionswiederherstellung bleiben ebenfalls erhalten. Originaldateien der Medienbibliothek und aktuelle Varianten-Fingerabdrücke sind niemals für die Variantenbereinigung geeignet. Übertragungsarchive und Protokolle bleiben unter Kontrolle des Betreibers.

Revisionsalter und Mindestanzahlschutz gelten gemeinsam. Beispielsweise behält eine Seite mit 20 Revisionen alle 20, auch wenn sie älter als 90 Tage sind, da die neuesten 50 geschützt sind. Explizite gespeicherte Richtlinien, einschließlich 365 Tage Aufbewahrung, bleiben erhalten; Nur der Fallback für eine nicht festgelegte Einstellung ändert sich auf 90 Tage. Durch das Speichern der Einstellungen wird die Berechtigung aktualisiert, und der nächste aktivierte geplante Job kann sie anwenden.

Von CMS 1.105.25 gruppiert Aufbewahrungsrichtlinie Kategoriezeitpläne, Sicherungsaufbewahrung und Revisions-/Arbeitsbereichsaufbewahrung in reaktionsfähigen Tabellen. Unter Aufbewahrung versteht man einen Altersschwellenwert plus der geschützten Mindestanzahl, nicht eine maximale Backup-Anzahl. Die Einbindung manueller Backups und das Speicherbudget bleiben getrennte Kontrollen; Ein Budget hat niemals Vorrang vor dem Schutz. Vorhandene gespeicherte Werte bleiben beim Upgrade und nach Validierungsfehlern erhalten.

Der Link Scheduler-Setup und -Überprüfung öffnet einen autorisierten, schreibgeschützten Bildschirm mit installationsspezifischen Befehlen und aufgezeichneten Heartbeat-Beweisen. Es unterstützt Standard-Hosting cron ohne Herne sowie optionale bestätigte CLI Einrichtung für das Anwendungskonto. Siehe Planer-Setup. Das Hinzufügen eines cron-Eintrags ist kein Nachweis der Ausführung. Aktualisieren Sie nach 1–2 Minuten, um die tatsächliche Aktivität zu überprüfen; Die Bereinigung wird weiterhin nach dem in der Tabelle gezeigten Zeitplan ausgeführt.

Der Arbeitsbereich verwendet native Registerkarten für Speicher und Verlauf, Aufbewahrung und Automatisierung sowie Bereinigungsaktionen. Die Einstellungen verwenden benannte WebBlocks UI Gruppen mit gepaarten Alters-/Anzahlfeldern, ohne HTML Feldsatz-/Legendenrahmen. Validierungs-/Aktionsweiterleitungen behalten das relevante Panel bei. Die Zahnradaktionen des beibehaltenen Verlaufs öffnen die Registerkarte „Einstellungen“ der entsprechenden Revisionsrichtlinie und die Augenaktion öffnet die Transferpaketverwaltung. Alle verwenden die Standard-Symbolaktionen des Panels mit zugänglichen Beschriftungen. Leere Kategorien zeigen den neutralen Status „Nichts zu reinigen“ an; Kategorien mit berechtigten Artikeln behalten das vorhandene destruktive Bestätigungsmodal bei. Die automatische Auswahl zeigt die eigene geplante Zeit jeder Kategorie an.

Führen Sie vor Nutzung der neuen Ausführungsübersichten die aktuellen Installations-/Paket-Update-Migrationen aus. Jede Kategorie speichert nur ihr letztes manuelles oder geplantes Ergebnis mit Start, Ende, letztem Erfolg, Anzahlen, Bytes und Fehlern. Bei teilweiser Löschung zählen nur tatsächlich entfernte Bytes. Fehlt das Übersichtsschema, wird die Bereinigung blockiert; ein veralteter laufender Vorgang erscheint als unterbrochen. Berichtszugriffe und Probeläufe erzeugen keine Ausführungs- oder Zeitplanernachweise.

Aktivieren Sie geplante Kategorien einzeln unter Wartung → Bereinigung. Neue Flags sind standardmäßig deaktiviert. Tägliche Zeitpläne führen Asset-Revisionen unter 04:00, veraltete Medienvarianten unter 04:10 und temporäre Arbeitsbereiche unter 04:20 durch. Die Bereinigung der Seiten und Shared Slot Revisionen findet sonntags um 04:30 und 04:45 statt. Die Zeiten richten sich nach der Planungszeitzone der Anwendung. Der Host muss Laravel Scheduler ausführen und einen gemeinsam genutzten Cache mit atomaren Sperren verwenden, wenn mehrere Worker arbeiten. Die bestehende Asset-Write-Revisionsbereinigung gilt nach Asset-Änderungen weiterhin, auch wenn der zusätzliche tägliche Zeitplan deaktiviert ist. Für die Bereinigung vorhandener Backups gelten separate Richtlinien und Zeitpläne.

Die temporäre Bereinigung umfasst erkannte Zeitstempel-/UUID-Update-Läufe und abgebrochene Backup-/Wiederherstellungs-Scratch-Läufe unter storage/app/temp/system-backups und storage/app/temp/system-backup-restores. Jeder verschachtelte Eintrag muss älter als der Aufbewahrungsschwellenwert sein. Der Standardwert bleibt 24 Stunden; Eine Senkung ist nicht erforderlich, um aufgegebene Arbeiten wiederherzustellen. Die Installationsidentität, unbekannte Dateien oder Laufnamen, Updater-Wiederherstellungs-Backup-Ordner, symbolverknüpfte Bäume und speicherüberlappende Backup-Archive oder öffentliche Uploads bleiben erhalten. Die physische Nutzung umfasst aufbewahrte Dateien, daher kann der gemessene Speicher ungleich Null sein, ohne dass ein geeigneter Kandidat vorliegt.

Der veraltete Aktualisierungsverlauf running/pending allein blockiert die Bereinigung nicht mehr. Kürzliche Zulassungen, neue Herzschläge, in der Warteschlange befindliche Bedienerjobs und tatsächlich gehaltene Aktualisierungssperren schützen weiterhin die Arbeit. Leases für Sicherungs-/Wiederherstellungsprozesse schützen auch Vorgänge, in deren Datenbank-Snapshot bereits completed steht. Durch die Löschung werden beide Betriebspachtverträge aufgehoben und Alter und Baumidentität werden erneut überprüft. Der Update-Verlauf wird nicht neu geschrieben. Wenn der Lease-Heartbeat nicht geschrieben und zurückgelesen werden kann, wird die Bereinigung sicher beendet. Katalog-Downloads nutzen während der Installation Datei-Leases; Nur abgelaufene, entsperrte catalog-plugin- temporäre Dateien sind berechtigt. Andere Dateien in diesem Verzeichnis werden nicht ausgewählt. Die automatische temporäre Bereinigung bleibt eine explizite Option pro Installation in Aufbewahrung und Automatisierung; Durch die Aktivierung werden weder die Altersgrenze noch die anderen Kategorie-Flags geändert.

Das letzte Formular wird nur ausgeführt, wenn die automatische Wartung für diese Kategorie aktiviert ist. Verwenden Sie einen der fünf Kategorienamen für das Kategorieargument. Bei einem Probelauf werden niemals Dateien entfernt oder eine Ausführungszusammenfassung geschrieben. Befehle geben einen Fehler zurück, wenn die Bereinigung oder ihre Vorschau nicht abgeschlossen werden kann.

Die interne API legt GET und PUT /webadmin/api/system/cleanup bis maintenance.read und maintenance.settings.write sowie destruktive POST /webadmin/api/system/cleanup/{category}/run bis maintenance.delete offen. Vorhandene Aufbewahrungsfelder bleiben bei Einstellungsschreibvorgängen erforderlich. Die optionalen automatic Objekt-Patches mit dem Namen boolesche Kategorie-Flags; Ausgelassene Flags behalten ihre Werte. Die Leseantwort fügt physikalische Messungen und aktuelle Ergebnisse unter overview.storage_report und overview.automation hinzu. Unbekannte Flags und nicht boolesche Werte werden abgelehnt. Ein fehlgeschlagener Lauf gibt ok: false und eine Fehleranzahl zurück, anstatt eine erfolgreiche Bereinigung zu behaupten.

Die Verfügbarkeit von Updates basiert darauf, dass die neueste veröffentlichte Release-Version neuer ist als die aktuelle CMS-Codeversion. Historische fehlgeschlagene Update-Läufe und veraltete gespeicherte Werte der installierten Version bleiben über die modalen Ausführungsdetails und die beibehaltene Ausführung CLI einsehbar, machen eine aktuelle Installation jedoch nicht selbst umsetzbar.

Der Bildschirm ist eine einzelne Statuskarte. Wenn ein kompatibles Update verfügbar ist, werden der Pfad von der aktuellen zur neuesten Version, ein gefalteter What's new-Änderungsprotokollbereich, die Ein-Klick-Aktion Update to X mit einem Backup-Hinweis und ein Server-Backup-Hinweis mit Link zum Bildschirm „Backups“ angezeigt, damit Bediener vor einem größeren Update ein neues vollständiges Backup erstellen können. Wenn kein Update verfügbar ist, wird eine leise Aktualisierungsmeldung mit der installierten Version und dem Zeitpunkt der letzten Überprüfung angezeigt.

Superadministratoren verfügen über eine Async-Update-Indikator-Shell in der oberen Admin-Leiste. Es ist standardmäßig ausgeblendet, überprüft den Aktualisierungsstatus asynchron und wird nur sichtbar, wenn eine neuere vertrauenswürdige Version verfügbar ist.

Die Preflight-Bereitschaft ist eine explizite Pass/Fail-Checkliste auf dem Bildschirm: Datenbankverbindung, ZIP- und Natrium-PHP-Erweiterungen, PHP/Composer/Prozessausführung, Anwendungs-Root- und Update-Workspace-Schreibzugriff und freier Speicherplatz. Die Aktualisierungsaktion ist nur verfügbar, wenn jede Prüfung erfolgreich ist und kein anderer Aktualisierungslauf die Sperre hält.

Der Aktualisierungsverlauf stellt beibehaltene Läufe als geschlossenes Akkordeon dar; Jeder Lauf öffnet sein Protokoll modal und das Löschen von Zeilen ist nicht Teil des Administrators UI. Aktualisierungslaufdatensätze werden automatisch bereinigt, wobei standardmäßig die letzten fünf Läufe beibehalten werden. Der letzte fehlgeschlagene Lauf bleibt erhalten, bis ein neuerer erfolgreicher Lauf existiert. Bediener 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 überprüfen und mit php artisan webblocks:updates:prune-runs --keep=5 eine kontrollierte Bereinigung durchführen.

Der Update-Client unterstützt strukturierte Metadaten vom Update-Service, einschließlich Titel, Zusammenfassung, Highlights, Korrekturen, Kompatibilitätshinweise, Migrationshinweise, Asset-Hinweise, Betreiberhinweise und technische Hinweise sowie kumulative Änderungsprotokolleinträge pro Version für das What's new-Akkordeon. Die native CMS Release-Vorbereitung leitet Zusammenfassungen und Highlights aus dem passenden CHANGELOG.md Release-Abschnitt ab und fügt releasespezifische technische Metadaten hinzu, sodass die Release-Karte die tatsächlich veröffentlichte Version beschreiben sollte und nicht wiederholte Platzhalter für den Veröffentlichungsworkflow. Diese Werte werden als maskierter Klartext gerendert. Ältere Versionen, die nur release_notes bereitstellen, zeigen diese Notizen immer noch sauber an, und Versionen ohne Notizen zeigen No release notes were provided for this release.

Die Synchronisierung des ausgelieferten Katalogs wird automatisch als Best-Effort-Schritt der Update-Anwendungskette ausgeführt (webblocks:catalog-repair --all); Ein Synchronisierungsfehler führt nicht zum Scheitern des Update-Laufs und kann anschließend manuell repariert werden.

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, --plugin-block-types, --slot-types, --page-layouts, --icons und --all. Es meldet erstellte, aktualisierte, unveränderte und übersprungene Zeilen, behält installspezifische benutzerdefinierte Katalogzeilen bei und kann wiederholt ausgeführt werden. block-types:sync-core bleibt als untergeordneter Kompatibilitätsbefehl für den Blocktypkatalog erhalten.

--plugin-block-types schreibt eine Katalogzeile für jeden Blocktyp, der von einem installierten Plugin deklariert wird, ob aktiviert oder nicht, sodass der Block im Editor platziert werden kann; Die Blöcke eines deaktivierten Plugins werden weiterhin von PluginBlockCatalog aus den Pickern herausgefiltert. Plugin-Lebenszyklusaktionen (Installieren, Aktivieren, Deaktivieren, Einrichten, Aktualisieren) führen diese Synchronisierung bereits über PluginRuntimeRefresher durch, daher handelt es sich bei dem Umfang eher um einen Reparaturpfad als um den normalen. Bei einer erneuten Synchronisierung werden die Plugin-eigenen Spalten (name, description, source_type, is_system, is_container) korrigiert und category, sort_order und status absichtlich in Ruhe gelassen, sodass die Kuratierung durch den Bediener – das erneute Tabulieren eines Blocks, seine Neuordnung oder die Einstellung auf „Entwurf“, um ihn auszublenden – die Reparatur überlebt.

Veröffentlichte Release-Pakete enthalten die wiederverwendbare CMS Laufzeit: Quelle, öffentliche Assets, Migrationen, Ansichten, Routen, Konfiguration, Sprachdateien und Installations-Stubs. Entwicklungstests, Skripte, Repository-Metadaten, lokale Konfiguration, Dokumentationsquellen und installationsspezifische Projektinhalte sind vom Verteilungsarchiv ausgeschlossen. Die kanonische Dokumentation wird in ihrem unabhängigen Repository verwaltet.

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

release:push sendet den Release-Zweig und das mit Anmerkungen versehene Tag in einem Git-Push an origin, sodass die Pre-Push-Validierungssuite einmal ausgeführt wird. Anschließend werden die verifizierten Verweise auf backup gespiegelt, ohne diesen Hook erneut auszuführen. release:prepare erstellt das Paket ZIP, die Prüfsumme und die Nutzlast Publisher aus dem Commit HEAD; Es erfordert einen sauberen Baum, eine passende Quellversion, das exakt annotierte v{VERSION}-Tag und ein überprüftes Inventar mit passender Dokumentationsherkunft.

Führen Sie die lokalen Prüfungen durch und überprüfen Sie vor der Veröffentlichung die GitHub CI des Release-Commits. release:publish-update -- --dry-run validiert das Artefakt und die Konfiguration ohne Hochladen. Der eigentliche Veröffentlichungsbefehl erfordert eine GitHub CLI Authentifizierung, signiert und lädt das Artefakt auf Publisher hoch, überprüft Stable-Channel-Metadaten und veröffentlicht oder aktualisiert die entsprechende GitHub Version. Publisher bleibt die Installations-Update-Quelle; Eine GitHub-Version allein veröffentlicht nicht den CMS-Update-Kanal. Wenn eine Antwort unterbrochen wird, überprüfen Sie beide Veröffentlichungsstatus, bevor Sie es erneut versuchen.

Für die Maintainer-Veröffentlichung sind WEBBLOCKS_PUBLISHER_TOKEN und WEBBLOCKS_PUBLISHER_SIGNING_KEY erforderlich, die bei der Ausführung aus der etablierten Maintainer-Konfiguration geladen werden. Kopieren Sie diese Anmeldeinformationen nicht in eine CMS Installation oder Dokumentation. Installierte Sites verwenden die paketeigenen Standardeinstellungen für Release-Server, Produkt und Stable-Channel. Für normale Installationen sind keine Publisher Server- oder Kanalumgebungseinstellungen erforderlich. Die ehemalige updates.webblocksui.com Bridge ist historisch und kein aktiver Konfigurationspfad.

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.

Eingesandte Kontaktformulare werden vor der Zustellung der Benachrichtigung gespeichert. Der E-Mail-Benachrichtigungsstatus spiegelt nur das Benachrichtigungsverhalten wider und ändert nichts an der redaktionellen Klassifizierung. Sent bedeutet, dass Laravel den Versand ausnahmslos über einen konfigurierten echten E-Mail-Transport akzeptiert hat; Es kann keine Zustellung per Posteingang garantiert werden. Failed bedeutet, dass ein echter Benachrichtigungsversuch zu einem bereinigten Fehler geführt hat. Skipped oder Not configured bedeutet, dass kein echter Versand stattgefunden hat. Gültige Einsendungen werden als „Zulässig“, „Quarantäne“ oder „Spam“ bewertet. Quarantäne und Spam werden zur Überprüfung aufbewahrt, wobei die Benachrichtigung unterdrückt wird. Ein ungültiger signierter Nachweis, ein ausgefülltes generiertes Prüffeld oder eine Übermittlung unterhalb der harten Mindestzeit folgt generischem Erfolg ohne Speicherung. Die fortlaufende Schutzzusammenfassung zählt nur Anfragen, die die Bewertung erreicht haben. Informationen zu Signalen, Schwellenwerten, Datenschutzgrenzen und Optimierung finden Sie unter Schutz öffentlicher Einreichungen.

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. Überprüfen Sie die 30-Tage-Schutzsummen und korrigieren Sie Fehlalarme anhand des Status.
6. Führen Sie php artisan contact:mail-diagnose --block=ID aus, wenn die Empfängerauflösung unklar ist.
7. 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
• CMS-verwaltete Uploads von storage/app/public, ausgenommen regenerierbare media/transforms/ Dateien in neuen Backups
• Öffentliche Dateien der Website von public/site
• 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

Neue Backups zeichnen excluded_upload_paths: ["media/transforms/"] in ihrem Version-1-Manifest auf. Originalbilder, Anhänge und andere Uploads bleiben im Archiv. Generierte Varianten werden neu erstellt, wenn der Renderer sie nach der Wiederherstellung benötigt; Fehlende Codecs greifen auf das Original zurück. Der vorherige Neuaufbau aller Varianten ist optional; siehe Medienbildvarianten. Ältere Archive der Version 1 und Legacy-Archive sind weiterhin wiederherstellbar, einschließlich zwischengespeicherter Varianten, sofern vorhanden. Sicherungen in derselben Sekunde haben unterschiedliche Dateinamen, sodass das Sicherheitsarchiv vor der Wiederherstellung seine Quelle nicht überschreiben kann.

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, die die installationsweite Standardeinstellung und den Fallback für alle Sites darstellt, die keine eigene Zeitzone festlegen
• 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

Visitor Reports leitet nun aus den vorhandenen Datensätzen ein Zeitdiagramm, einen Vergleich mit Vorperioden gleicher Länge, Messabdeckung und Seitendetailmodalitäten ab. Es werden keine öffentlichen Skripte, Cookies, Identifikatoren, Ereignisse oder Drittparteiübertragungen hinzugefügt. Bestehende Einwilligungsentscheidungen regeln weiterhin die Erfassung von Identifikatoren.

• Diagramme füllen fehlende Tage mit null aufgezeichneten Aufrufen. Bereiche, die länger als 90 Tage sind, verwenden gleich große Mehrtages-Buckets, die im Diagramm und in der Tabelle mit zugänglichen Werten beschriftet sind und mit der Schaltfläche „Diagrammwerte“ in einem WebBlocks UI-Modal geöffnet werden. Für Datumsangaben wird derselbe Anwendungs-/Datenbankkalender verwendet wie für vorhandene Berichte.
• Der vorherige Zeitraum endet unmittelbar vor dem ausgewählten Zeitraum. Eine vorherige Gesamtsumme von Null hat keine prozentuale Änderung. Zeiträume, die aktuelle oder zukünftige Daten umfassen, werden als vorläufig gekennzeichnet. Zählungen beschreiben aufbewahrte Aufzeichnungen und sind kein Beweis dafür, dass die Nachverfolgung kontinuierlich aktiv war oder dass ein leerer historischer Zeitraum keine Besucher hatte.
• Die Abdeckung ist der Anteil der Aufrufe mit einer verwendbaren einwilligungsbasierten Kennung in gespeicherten Detaildatensätzen. Es handelt sich um keine Zustimmungsrate. Besucher-/Sitzungsschätzungen beschreiben diese Teilmenge und stellen keine verifizierten Personenzahlen dar.
• Der Tracking-Status zeigt den letzten detaillierten Datensatz innerhalb des zugänglichen ausgewählten Site-Bereichs an, unabhängig von Datum, Gebietsschema und Verkehrsfiltern. Es wird nicht behauptet, dass der Planer läuft oder dass fehlende Datensätze einen Fehler bei der Nachverfolgung beweisen.
• Inhaltszeilen öffnen WebBlocks UI Modalitäten mit Seiten-/Site-/Gebietsschema-Gesamtzahlen und unabhängigen Geräte-/Referrer-Aufschlüsselungen. Eine vollständige Aufschlüsselung wird ausgeblendet, wenn eine Gruppe weniger als fünf Ansichten hat, wodurch eine direkte Subtraktion einer unterdrückten Zelle vermieden wird. Hierbei handelt es sich um einen Anzeigeschutz und nicht um eine Garantie für die Anonymisierung. Es werden keine Einzelfahrten hinzugefügt. Die zehn größten Gruppen werden angezeigt, wenn eine Aufschlüsselung verfügbar ist.

Der Bericht folgt dem mit WebBlocks UI gekennzeichneten Filterleistenvertrag, mit zusammenfassenden Metriken über dem Diagramm und detaillierten Berichtsregisterkarten darunter. Messabdeckung, Tracking-Status, Datenschutzkontext und Aufbewahrungsrichtlinie sind im Modal Berichtsinformationen verfügbar. Hinweise auf fehlende Migrationen, deaktivierte Bereinigungen und archivierte Datensätze bleiben im Bericht selbst sichtbar.

Das Diagramm verwendet die gebündelte Komponente WebBlocks UI 2.26.0 wb-chart und die Tabelle visitor-chart-data des Modals als Quelle. Numerische Attribute enthalten unformatierte Zählwerte; Sichtbare Zellen behalten die lokalisierte Formatierung bei. UI besitzt SVG Zeichnen, Achsen, Größenänderung und Tastaturinteraktion; CMS speichert Abfragen, Berechtigungen, Datenschutz und Aggregation. Es wird keine externe Kartenbibliothek oder zusätzliche Besuchersammlung eingeführt.

Das Paket registriert täglich visitors:cleanup im Scheduler 03:45 bis Laravel. Der Host muss seinen normalen Scheduler ausführen; Keine öffentliche Anfrage führt eine Bereinigung durch. Der geplante Befehl und der manuelle Befehl teilen sich eine atomare Cache-Sperre. Verwenden Sie bei der Planung auf mehreren Servern einen gemeinsam genutzten, sperrbaren Cache.

Hierbei handelt es sich um Produktvorgaben, nicht um gesetzliche Aufbewahrungspflichten oder eine Zertifizierung zur Einhaltung gesetzlicher Vorschriften. Websitebesitzer können für ihre Zwecke kürzere Zeiträume wählen. Vorhandene Installationen mit einem funktionierenden Planer beginnen mit der Anwendung dieser Richtlinie, nachdem die neue Migration und der neue Code installiert wurden. Innerhalb der Migration selbst erfolgt keine Löschung.

Vorschau anzeigen und lokal auf dem Host ausführen:

Die Bereinigung wird auch dann ausgeführt, wenn die Sammlung neuer Besuche deaktiviert ist. Durch das Deaktivieren der Erfassung dürfen historische Kennungen nicht auf unbestimmte Zeit gespeichert bleiben. Die Deaktivierung der Bereinigung selbst wird im Bericht angezeigt. Fehlende zusammenfassende Migrationen blockieren die Bereinigung ohne das Löschen von Datensätzen und lassen vorhandene Berichte funktionsfähig.

Abgelaufene Datensätze werden transaktional Tag für Tag durch Zeilen in wbcms_visitor_daily_totals ersetzt: Site, Gebietsschema (Null für unbekannt), Tag, Gesamtaufrufe und Bot-Aufrufe. Sie behalten keinen Seitenpfad, Referrer, Kampagne, Gerät, genaue Besuchszeit, IP Hash oder Sitzungskennung. Verspätete Datensätze werden einmalig mit vorhandenen Summen zusammengeführt. Datensätze, die älter als der gesamte Aufbewahrungshorizont sind, Datensätze ohne Datum und abgelaufene Datensätze, deren Site gelöscht wurde, werden ohne Rollup verworfen. Durch das Löschen einer Site werden auch deren Tagessummen entfernt. Vorhandene Backups haben ihren eigenen Aufbewahrungslebenszyklus; Dieser Befehl schreibt keine Sicherungsarchive neu.

Die Hauptsummen, das Diagramm und der Vergleich kombinieren gespeicherte Details mit Tagessummen und bewahren die Site-Autorisierung sowie Site-/Gebietsschema-/Verkehrsfilter. Die Bot-Gesamtwerte umfassen beide Quellen. Detaillierte Tabellen und Sitzungsmetriken verwenden nur verbleibende Detaildatensätze. Ein ausdrücklicher Hinweis erläutert den Unterschied, wenn ein Zeitraum Rollups enthält. Tägliche Einzelbesucher oder Sitzungen werden bewusst nicht über Tage hinweg summiert. Der Bericht rekonstruiert niemals die Besucherhistorie anhand der gespeicherten Zusammenfassungen.

Sowohl Neuinstallationen als auch Aktualisierungsmigrationen bestehender Installationen erstellen die Gesamttabelle. Führen Sie den normalen Paketmigrations-/Aktualisierungsablauf aus, bevor Sie die geplante Bereinigung aktivieren. Neue Insight-Strings werden auf Englisch und Türkisch ausgeliefert; Andere Admin-Gebietsschemas verwenden den normalen englischen Fallback, wenn keine Insight-Übersetzung verfügbar ist.