Installation

WebBlocks CMS wird als Composer Paket verteilt, das in einer Laravel Hostanwendung installiert wird. Die Hostanwendung bleibt für ihren Bootstrap, ihre Umgebung, ihre Datenbank, ihre Warteschlangen, ihre E-Mails, ihren Scheduler, ihre Bereitstellung, ihre Sicherungen und ihr öffentliches Dokumentstammverzeichnis verantwortlich. Für gestapelte/tägliche E-Mail-Benachrichtigungen und tägliche E-Mail-Zusammenfassungen ist der Planer jede Minute erforderlich. Neue Websites aktivieren diese Richtlinien standardmäßig. Das Anzeigen gespeicherter Nachrichten und Panel-Benachrichtigungen erfordert keine Planung oder das Versenden von E-Mails.

Prüfen Sie vor der Einrichtung eines Produktionsservers die Hosting-Anforderungen, bewerten Sie die Last anhand der Hosting-Kapazitätsprüfung, vergleichen Sie sie mit den ausdrücklich vorläufigen Kapazitätsergebnissen und vervollständigen Sie die Hosting-Bereitschaftsliste. Diese Seiten trennen den grundlegenden Installationsvertrag von optionalen Bild-, E-Mail-, Scheduler-, Backup- und Paketupdate-Abhängigkeiten. Die bisherigen Teilmessungen sind keine Produktionszertifizierung.

Beginnen Sie mit einer neuen oder bestehenden Laravel-12.55+- oder Laravel-13-Anwendung mit konfiguriertem Anwendungsschlüssel und Datenbank. Installieren Sie das Paket mit Composer und führen Sie anschließend den CMS-Installer aus.

Eine Installation gilt als abgeschlossen, wenn die Anwendung über eine funktionierende CMS-Basis verfügt:

• ein App-Key existiert
• die Datenbank ist erreichbar
• die erforderlichen Tabellen existieren
• die Kern-Seed-Daten existieren
• der erste aktive super_admin existiert
• eine Abschlussmarkierung der Installation ist in system_settings gespeichert

Führen Sie im Stammverzeichnis der Laravel-Hostanwendung Folgendes aus:

Öffnen Sie anschließend /webadmin/login. Dies ist der primäre unterstützte Installationsweg. Das Klonen dieses Repositorys erzeugt keine eigenständige Laravel-Anwendung.

Unterstützte Optionen:

• --name= Anzeigename des ersten Super-Admins
• --email= E-Mail-Adresse des ersten Super-Admins
• --password= Passwort des ersten Super-Admins
• --site-name= Name der ersten Site; ohne Angabe wird der konfigurierte Wert WEBBLOCKS_CMS_DEFAULT_SITE_NAME, sonst der normalisierte Host aus APP_URL verwendet
• --site-handle= Handle der Standard-Site
• --repair-partial benennt leere partielle CMS-Tabellen vor den Neuinstallations-Migrationen um
• --skip-starter-content veröffentlicht eine leere Startseite statt der mitgelieferten Startseite
• --force überschreibt bei Bedarf paketeigene CMS-Assets oder veröffentlichte Konfigurationsdateien

Was webblocks:install tut:

• benennt die erste Site nach dem normalisierten Host aus APP_URL, behält intern default; www. entfällt im Namen, relevante Subdomains bleiben erhalten, lokale oder IP-Hosts verwenden Default Site
• veröffentlicht config/webblocks-cms.php, wenn die Host-App sie noch nicht hat
• entfernt die unveränderte Laravel-Willkommensroute aus routes/web.php, wenn dies sicher ist, mit einem zeitgestempelten Backup zuerst, damit öffentliche CMS-Routen / bedienen können
• patcht app/Models/User.php mit WebBlocks\Cms\Auth\Concerns\HasWebBlocksCmsAccess
• erstellt ein zeitgestempeltes Backup, bevor User.php geändert wird
• überspringt das Patchen, wenn das Trait bereits vorhanden ist
• schlägt mit einer klaren Meldung fehl, wenn User.php keine erkennbare App\Models\User extends Authenticatable-Klasse ist
• führt den Neuinstallations-Migrationspfad des Pakets für saubere Consumer-Installationen aus
• erkennt partielle CMS-Schemata vor dem Ausführen der Neuinstallations-Migrationen und meldet vorhandene CMS-Tabellen, Zeilenanzahlen, zugehörige Migrationszeilen und bekannte Fremdschlüsselkonflikte
• repariert leere partielle CMS-Schemata nur, wenn --repair-partial angegeben ist, indem leere CMS-Tabellen vor dem Fortfahren mit einem zeitgestempelten _before_cms_install_...-Suffix umbenannt werden
• verweigert die automatische Reparatur, wenn eine partielle CMS-Tabelle Zeilen enthält
• überspringt das erneute Ausführen des frischen Schemas, wenn bereits CMS-Tabellen existieren
• erstellt Laravel-Unterstützungstabellen, ohne Migrationen der Host-Anwendung auszuführen; derzeit umfasst dies CMS-Passwort-Reset-Tokens sowie sessions, cache und cache_locks, wenn diese datenbankgestützten Treiber konfiguriert sind
• führt das normale Laravel-Migrationsset der Host-Anwendung nicht als Teil der Paketinstallation aus und vermeidet so Konflikte mit der bereits erstellten CMS-kompatiblen users-Tabelle
• bereitet das Stammverzeichnis der backups-Dateisystem-Disk vor, die von Backup / Restore verwendet wird
• installiert paketeigene CMS-Assets nach public/cms
• erstellt public/storage, wenn es fehlt und die Umgebung es erlaubt
• legt Sprachvarianten, Sites, Slot-Typen, Seitenlayouts und Kernblocktypen idempotent an
• lädt den vollständigen WebBlocks-UI-Symbolkatalog aus dem Paketmanifest; Symbolfelder funktionieren ohne externe Netzwerkverbindung oder manuelle Synchronisierung
• erstellt die veröffentlichte Startseite unter / samt Layout-Slots
• füllt diese Startseite mit den mitgelieferten Startinhalten, sofern nicht deaktiviert
• speichert die installierte Version und die Abschlussmarkierung der Installation in system_settings
• erstellt den ersten aktiven super_admin nur, wenn noch keiner existiert

Die Paket-Authentifizierung ist Laravel-nativ und erfordert weder Breeze, Jetstream, Laravel UI noch Fortify. Melden Sie sich nach der Installation unter /webadmin/login an, wenn die Auth-Routen des CMS-Pakets aktiv sind. CMS-eigene Auth-Views und Admin-Gast-Weiterleitungen verwenden Paket-Routennamen wie webblocks.auth.login und webblocks.auth.logout, sodass ein Host-Produkt seine eigene globale login-Route, zum Beispiel /quiztem/login, behalten kann, ohne CMS-Formularaktionen oder /webadmin-Weiterleitungen zu übernehmen.

Im aktuellen Paketinstallationsmodell bleibt App\Models\User der Hostanwendung das Authentifizierungsmodell und Ziel der Installationsanpassung.

Wenn webblocks:install nach einem fehlgeschlagenen oder unterbrochenen vorherigen Lauf stoppt, führen Sie es zunächst ohne Reparatur erneut aus und lesen Sie die Diagnose zur partiellen Installation. Leere CMS-Tabellen können explizit beiseitegeschoben werden:

Der Reparaturmodus benennt nur leere CMS-eigene Kandidatentabellen um. Er löscht keine Tabellen, ändert nicht-leere Tabellen nicht automatisch und geht nicht davon aus, dass das CMS die Host-Anwendung besitzt.

Für Site-Betriebsmanager ist die Benachrichtigungsglocke im Admin-Header auf Dashboard → Panel-Benachrichtigungen verlinkt. Das Panel liest gespeicherte Kontaktnachrichten jedes Mal, wenn eine Panel-Seite geladen wird, auch wenn E-Mail deaktiviert ist oder der Planer nie ausgeführt wurde. Es zeigt ungelesene Nachrichten und Nachrichten, die auf eine Antwort warten, pro zugänglicher Site an, mit Links zum gefilterten Kontakt-Posteingang. Ungelesene Nachrichten werden in die Anzahl der wartenden Antworten einbezogen. Das Klingelzeichen zählt nur ungelesene Kontaktnachrichten; Gelesene Nachrichten, die auf eine Antwort warten, und Systemwarnungen bleiben im Dashboard getrennt. Wenn keine ungelesenen Nachrichten vorhanden sind, ist die Glocke ausgeblendet; Das Dashboard-Benachrichtigungsfeld bleibt verfügbar. Das Symbol „Aktionen“ öffnet den Posteingang der ausgewählten Site, um Nachrichten zu überprüfen, die auf eine Antwort warten. Hierzu können auch bereits gelesene Nachrichten gehören. Zählungen und Links umfassen niemals unzugängliche Websites und in der Zusammenfassung werden keine Besucherdetails angezeigt.

Durch das Öffnen des Bedienfelds werden Nachrichten nicht als gelesen markiert, ausstehende E-Mails gesendet, die fehlgeschlagene Zustellung erneut versucht oder der Zustand des Zeitplaners nicht überprüft. Das Lesen einer Kontaktnachricht reduziert die ungelesene Arbeit, lässt sie jedoch auf Antwort warten; Wenn Sie es als „Beantwortet“ oder „Archiviert“ markieren, wird es aus dieser Zusammenfassung entfernt. Spam- und Quarantänenachrichten verbleiben im Moderationsposteingang und nicht in der Anzahl der ausstehenden Arbeiten. Dabei handelt es sich um den Status des freigegebenen Posteingangs, der beim Laden der Seite aktualisiert wird, nicht um einen persönlichen Benachrichtigungsverlauf. Der Live-Chat behält unabhängig von der geplanten E-Mail seinen eigenen autorisierten Panel-Indikator.

Sofortige E-Mails mit deaktivierten täglichen Zusammenfassungen funktionieren auch ohne Zeitplaner, sofern ausgehende E-Mails konfiguriert sind. Gestapelte/tägliche E-Mails und tägliche E-Mail-Erinnerungen erfordern weiterhin eine Hintergrundplanung: Durch die Anmeldung bei CMS kann die Zustellung zum ausgewählten Zeitpunkt nicht garantiert werden, wenn niemand das Panel besucht.

Den Ablauf, Backups und Kompatibilitätsanforderungen beschreibt Updates. Publisher-Installationen vor 1.89.1 müssen vor 1.89.2 oder neuer zunächst die Lizenzlayout-Brücke 1.89.1 installieren. Prüfen Sie danach erneut; neuere Clients erledigen dies automatisch. Composer-Installationen können ohne diese Publisher-Brücke direkt mit Composer aktualisiert werden.

Benutzerdokumentation liegt separat in docs/ des Repositorys webblocks-cms-docs und wird nicht mit dem CMS installiert. Das Paket behält den Laufzeit-Autorenvertrag resources/contracts/inventory.md, auch über GET /webadmin/api/inventory verfügbar. Öffentliche Dokumentation und Anleitungen sind Veröffentlichungsziele; die Trennung hat keine Synchronisierungsengine eingeführt.

Das Paketupdate fügt relationalen Speicher für Seitenlayout- und Shared-Slot-Referenzen, Stufenaktualisierungs- und Wiederherstellungsmarkierungen, Quellsynchronisierungsmetadaten und verwaltete Slots, Blockanwendungsreferenzen, API-Token-Zugriffslisten, Site-Benachrichtigungsrichtlinien und Planerzustand hinzu. Vorhandene Werte werden in begrenzten Stapeln kopiert; API Nutzlasten und Export-/Importfelder behalten ihre bestehende Struktur.

Zugeordnete Werte werden von SQL gelesen. Vorhandene JSON Felder bleiben temporäre Rollback-Kompatibilitätskopien und werden bei unterstützten Schreibvorgängen synchronisiert. Nicht zugeordnete Einstellungen und vollständige Revisions-Snapshots behalten in dieser Phase ihr bestehendes Speicherformat. Unbekannte historische Felder, fehlerhafte Werte und ungelöste Referenzen bleiben erhalten. Die Update-Migration ist wiederholbar und beim Rollback werden die neuen Daten nicht gelöscht. Wenn ein älteres Paket diese Kopien nach einem Rollback schreibt, gleichen Sie diese Abweichung aus, bevor Sie zur SQL-autorisierenden Version zurückkehren.

Die nächste Paketaktualisierung verschiebt die verbleibenden Blockeinstellungen und Embedded Application Asset-/Support-/Schemalisten in relationale Datensätze. Kernblockfelder verfügen über typisierte Darstellungs-, Medien-, Navigations- und Inhaltsschemata. Bindungen, Sammlungseinstellungen und Anwendungsinstanzwerte verfügen über separate Datensätze; Typisierte Knoten bewahren die verschachtelte Struktur und historische/Plugin-Erweiterungen. Asset- und Enum-Listen behalten die Reihenfolge und Duplikate bei, und Einstellungsdefinitionen behalten ihre Typen und Standardwerte bei.

Die Migration liest jeweils eine Legacy-Nutzlast in begrenzten ID-Batches und ist wiederholbar. Vorhandene Felder API, Renderer, Gebietsschema, Export/Import und vollständige Revision behalten ihre kompatiblen Strukturen. SQL ist maßgeblich; Vorhandene JSON Spalten bleiben synchronisierte Rollback-Kopien. Bei einem Update-Rollback bleiben SQL Daten erhalten. Überprüfen Sie daher alle von einem älteren Paket vorgenommenen Schreibvorgänge, bevor Sie die neue Version erneut anwenden. Vollständiger Snapshot und andere Legacy-Inhalte/Laufzeitumgebungen JSON sind spätere Migrationsarbeiten.

Die paketnative Migration bereitet Seiten-, Slot- und Layouteinstellungen, Blockmetadaten, vollständige historische Snapshots, Übertragungsdatensätze, Importfortsetzungskarten, Wiederherstellungsdaten, Aktualisierungsbelege, Symbollisten und Moderationsgründe in SQL vor. Bestehende API Namen und Strukturen bleiben kompatibel. Plugin-Lebenszyklusstatus und Werbepläne schreiben jetzt SQL; Alte veränderbare Dateien bleiben bis zur Umstellung erhalten. Die Vorbereitung ist idempotent und ersetzt bei Wiederholungen nicht den neueren SQL Plugin-Status.

Die Brücke behält alte Spalten für einen Updater bei, der bereits das vorherige Paket ausführt. Behalten Sie die automatische Vollsicherung bei, wenn Sie die nachfolgende Umstellung installieren: Durch die Wiederherstellung von älterem Code allein können entfernte Spalten oder Datendateien nicht wiederhergestellt werden. CMS Vollständige Backups enthalten die Datenbank, öffentliche Uploads und öffentliche Site-Dateien; Bewahren Sie das passende Paket und alle erforderlichen privaten Plugins/lokalen Speicher separat auf.

Bei der Umstellung werden die temporären Felder und importierten veränderbaren Statusdateien nach der Vorbereitung/Rücklesung entfernt. SQL ist die Quelle für alle persistenten Strukturen im Besitz von CMS, einschließlich unabhängiger vollständiger Snapshots. Die bestehenden API, signierten Pakete, unveränderlichen Sicherungs- und Exportformate verwenden weiterhin ihre etablierte Serialisierung. Publisher bietet 1.98.7 zunächst für frühere In-App-Clients an; Überprüfen Sie nach dieser Brücke erneut, ob 1.98.8 angewendet werden soll. Behalten Sie die vollständige Sicherung für eine Rückkehr zu älterem Code.

Die folgenden Browser- und CLI-Verfahren gelten nur für ältere Quellcode- oder Wartungsinstallationen mit vollständiger Laravel-Hostanwendung. Sie ersetzen keine Installation des aktuellen Paketrepositorys. Neue Installationen verwenden den obigen Composer-Ablauf.

Verwenden Sie den Browser-Assistenten für eine Neuinstallation.

Sobald der Quellcode lokal vorhanden ist, starten Sie mit:

Öffnen Sie dann http://127.0.0.1:8000/install.

Der Assistent deckt ab:

• Prüfungen der Umgebungsbereitschaft
• Datenbankkonfiguration und Verbindungsvalidierung
• Kern-CMS-Installation
• Erstellung des ersten super_admin
• Sperrung der Installation nach Abschluss

Hinweise:

• der Installer ist für Neuinstallationen gedacht
• wenn die Einrichtung unvollständig ist, kann der Assistent sicher erneut geöffnet und fortgesetzt werden
• nach Abschluss werden die Installationsrouten gesperrt und der normale Auth-/Admin-Ablauf übernimmt
• der Installer schreibt die gewählte Datenbankkonfiguration in .env

Verwenden Sie den CLI-Ablauf, wenn Sie für eine Neuinstallation einen standardmäßigen Laravel-Einrichtungsweg bevorzugen.

Hinweise:

• php artisan db:seed lädt die CMS-Kernkataloge, erstellt die Startseite mit Startinhalten und speichert bei Neuinstallationen die aktuelle Anwendungsversion als installierte Version
• php artisan storage:link ist erforderlich, wenn die öffentliche Dateiauslieferung storage/app/public verwenden soll
• Laufzeitverzeichnisse unter storage/framework, storage/logs und bootstrap/cache werden beim ersten Start automatisch erstellt
• Backup / Restore speichert Archive auf der backups-Dateisystem-Disk, standardmäßig unter storage/app/backups. Der PHP-Laufzeitbenutzer sollte Eigentümer dieses Verzeichnisses sein oder eine Deployment-Gruppe mit Lese-/Schreibzugriff teilen; vermeiden Sie pauschale 777-Modi.

Für ein frisches Laravel-Projekt, das mit lokal installiertem PHP und Composer läuft:

Öffnen Sie dann:

• öffentliche Site: /
• Admin-Anmeldung: /webadmin/login
• Admin: /webadmin

Sobald der Quellcode lokal vorhanden ist:

Hinweise:

• vertrauenswürdige lokale Entwicklung sollte .test-Domains und HTTPS verwenden, mit https://webblocks-cms.test als kanonischer CMS-Entwicklungs-URL
• php artisan serve bleibt für schnelle, rein CLI-basierte Prüfungen nützlich, aber vertrauenswürdige Browser-Workflows sollten das in docs/native-local-development.md dokumentierte native Nginx/PHP-FPM-Setup verwenden
• lokale Kontaktformular-E-Mail-Benachrichtigungen sollten einen lokalen SMTP-Catcher oder ein vertrauenswürdiges SMTP-Testkonto verwenden; die üblichen lokalen SMTP-Werte hängen vom installierten Tool ab
• Empfänger von Kontaktformular-Benachrichtigungen werden in dieser Reihenfolge aufgelöst: recipient_email auf Blockebene, Standard-Kontaktempfänger der aktuellen Site, CONTACT_RECIPIENT_EMAIL, dann MAIL_FROM_ADDRESS als letzter sicherer Fallback
• Kontaktübermittlungen werden unabhängig von der Benachrichtigungszustellung gespeichert; eine öffentliche Message sent-Antwort bestätigt also den Speichererfolg, selbst wenn der Admin-Bereich die Benachrichtigung später als Failed, Skipped oder Not configured anzeigt
• MAIL_MAILER=log, MAIL_MAILER=array und MAIL_MAILER=null sind keine echte ausgehende Zustellung und werden für die Kontaktnachrichten-Benachrichtigung als nicht konfiguriert angezeigt
• Kontaktformularblöcke erzeugen einen versteckten Wrapper mit wb-sr-only, inert, aria-hidden="true", generiertem Feld form_check_{token}, tabindex="-1", autocomplete="off" und formulargebundenem signiertem Zeitstempel. Ungültiger Nachweis oder ausgefülltes Prüffeld bewirken dieselbe allgemeine Erfolgsweiterleitung, ohne Nachrichtenspeicherung oder Benachrichtigung.
• Einsendungen mit gültigem Nachweis und Prüffeld werden lokal anhand von Inhalt, exakten und ähnlichen Wiederholungen, IP, Absenderadresse, /24- oder /64-Netz, Formularhäufung und gelernter Site-Reputation bewertet. Erlaubt, Quarantäne und Spam sind dauerhafte Admin-Kategorien, unabhängig vom Benachrichtigungsstatus.
• Der Schutz benötigt weder CAPTCHA noch externen Dienst. Cache-Schlüssel verwenden schlüsselbasierte Hashes; die 30-Tage-Metriken enthalten aggregierte Entscheidungen statt übermittelter Inhalte.
• wenn die Benachrichtigungszustellung fehlschlägt, können Admins die gespeicherte Nachricht unter Admin -> Contact Messages einsehen, um den kompakten Fehlerstatus in der Liste und die gespeicherten Fehlerdetails auf dem Nachrichtendetailbildschirm zu sehen

Öffnen Sie dann:

• öffentliche Site: https://webblocks-cms.test
• Admin: https://webblocks-cms.test/webadmin
• Installer bei einer Neuinstallation: https://webblocks-cms.test/install

Schließen Sie die Neuinstallation im Browser-Assistenten ab, nachdem diese Einrichtungsschritte erledigt sind.

Das Klonen des Repositorys ist nicht der normale Installationsweg für Anwendungsnutzer.

Klonen Sie das Repository nur für die Entwicklung von WebBlocks CMS oder Beiträge dazu:

Das Repository enthält Paketquellen, keine bereitstellbare Laravel-Anwendung. Den Entwicklungsablauf erläutern die Beitragsregeln des Produkts und die Paketteststrategie.

• Neuinstallationen leiten automatisch zu /install weiter
• Sie können den Assistenten auch manuell unter /install öffnen
• Sie können /install/core öffnen, um direkt zum Kern-Installationsschritt zu springen, wenn frühere Anforderungen bereits erfüllt sind
• der Assistent kann Schritte automatisch weiterschalten, sobald Anforderungen erfüllt sind
• das Öffnen von / und /install in mehreren Browser-Tabs kann unterschiedliche Assistentenschritte anzeigen; das ist zu erwarten, weil der Installer den Fortschritt verfolgt und entsprechend weiterleitet

Der erste super_admin ist für eine abgeschlossene Installation erforderlich.

• erstellen Sie im Browser-Assistenten den ersten Admin im letzten Einrichtungsschritt
• geben Sie im Paket-Consumer-CLI-Ablauf --name, --email und --password an webblocks:install weiter
• stellen Sie bei einer manuellen Installation sicher, dass mindestens ein aktives super_admin-Konto existiert, bevor das CMS als vollständig installiert gilt

super_admin ist die Rolle auf Installationsebene, die auf Benutzer, Sites, Sprachen (Locales), Einstellungen, Updates, Backups, Export/Import und alle Site-Inhalte zugreifen kann.

Eine Neuinstallation veröffentlicht unter / eine Startseite mit Produktzeichen neben der Überschrift, kurzem Funktionsraster und abschließender Handlungsaufforderung. Dies sind normale Blöcke, kein fest codierter Willkommensbildschirm. Neue Admins erhalten eine funktionsfähige Seite, die sie umschreiben, umordnen oder löschen können.

Das Logo wird bei der Installation in die eigene Medienbibliothek importiert und wie jedes Bild an den Block gebunden. Es wird vom eigenen Ursprung ausgeliefert und kann ersetzt oder gelöscht werden. Externe Hotlinks würden jeden Besucher zu Drittanfragen zwingen und die Startseite von fremder Verfügbarkeit abhängig machen. Ist der Import wegen schreibgeschützter Datenträger oder fehlender Dateien unmöglich, bleibt der Block ohne Medium; die Installation scheitert nicht.

Regeln für eine sichere Bereitstellung auf allen Installationswegen:

• Startinhalte werden nur auf Seiten ohne jegliche Blöcke geschrieben und überschreiben niemals vorhandene Inhalte
• nur zur Installationszeit; Systemupdates ergänzen oder restaurieren diese Inhalte niemals
• fehlende oder unlesbare Vorlagen werden gemeldet und übersprungen, ohne die Installation abzubrechen
• unbekannte Blocktypen werden samt Kindern übersprungen, statt die Installation scheitern zu lassen

Steuerungsmöglichkeiten:

• WEBBLOCKS_CMS_STARTER_CONTENT=false installiert eine leere veröffentlichte Startseite. php artisan webblocks:install --skip-starter-content tut dasselbe für einen einzelnen Lauf.
• WEBBLOCKS_CMS_STARTER_CONTENT_PATH verweist auf Ihr Vorlagenverzeichnis, wenn ein Produkt eine eigene Startseite mitliefern soll.
• WEBBLOCKS_CMS_SEND_POWERED_BY_HEADER=true ergänzt öffentliche CMS-Antworten um X-Powered-By: WebBlocks CMS, damit Technologiekataloge das Produkt ohne Versionsoffenlegung erkennen. Setzen Sie den Wert auf false, wenn die Richtlinie Produktkennzeichnung untersagt.

Installationen von vor dieser Funktion behalten ihre leere Startseite; Systemupdates fügen keine Inhalte hinzu. Zum einmaligen Befüllen:

Bei Multisite wählt --site=handle die Site; ohne Angabe wird die primäre Site verwendet.

Erstellt die Seite unter /, falls sie fehlt, und schreibt Startblöcke nur bei vollständig blockfreier Seite. Bestehende Inhalte bleiben unangetastet; der Grund wird gemeldet. Andere Seiten werden nie verändert. Zweimaliges Ausführen ist sicher.

Der Befehl verlangt weder Klassennamen noch Produktionsbestätigung, da diese die vorgesehenen Runner stören. Artisan-Panels können die Produktionsabfrage von db:seed nicht beantworten; ein Panel entfernte Backslashes aus --class, sodass Laravel Database\Seeders\WebBlocksCmsDatabaseSeedersStarterContentSeeder auflösen sollte. Die Sicherheitsgarantie ist stattdessen strukturell: Startinhalte werden ausschließlich auf blockfreie Seiten geschrieben.

Dieselbe Funktion ist über einen Seeder verfügbar, den db:seed bei Neuinstallationen ausführt:

Vorlagen sind JSON-Dateien in database/content/starter, mit Schema webblocks.cms.starter-content.v1 und dem Blockvokabular des KI-Seitenerstellungsleitfadens. Standard ist home.json; die benachbarte sprachspezifische Datei home.{locale}.json hat bei passender Standardsprache Vorrang. README.md beschreibt das Dateiformat.

• der Installer wird nach Abschluss gesperrt
• /webadmin ist der kanonische Einstiegspunkt in den CMS-Admin-Bereich
• Paket-Consumer-Installationen können sich über /webadmin/login anmelden; co-installierte Apps können ihr host-eigenes /login behalten
• /webadmin/dashboard leitet zu /webadmin weiter
• CMS-Assets bleiben unter /cms, zum Beispiel /cms/css, /cms/js und /cms/brand
• das paketeigene /webadmin/login verwendet Paket-Blade-Views, die Gast-Auth-Shell der WebBlocks UI, gepinnte WebBlocks-UI-Assets, /cms/css/guest.css und CMS-Produkt-Markenassets aus /cms/brand, einschließlich der Favicon-/Browser-Tab-Varianten normal, dunkle Oberfläche, auf Akzentfarbe/invers und hoher Kontrast
• /cms ist für CMS-eigene statische öffentliche Assets reserviert und darf nicht als Präfix, Alias oder Weiterleitung für CMS-Admin-Routen verwendet werden
• /admin gehört nicht dem CMS und darf nicht als CMS-Admin-Route wiederhergestellt werden
• neue Seiten beginnen als draft
• wenn Funktionen auf Installationsebene wie Revisionen, Backups oder Updates fehlende Tabellen melden, führen Sie php artisan migrate aus

Die Trennung von /webadmin und /cms vermeidet die Nginx-try_files-Kollision, bei der /cms/ als physisches public/cms/-Asset-Verzeichnis aufgelöst werden kann, bevor Laravel eine Route verarbeitet. Lösen Sie den Admin-Zugriff nicht durch Hinzufügen einer public/cms/index.php-Übergabe; diese Front-Controller-Brücke muss in den öffentlichen Assets von Root und Paket abwesend bleiben.

Konfigurieren Sie den Laravel-Mailversand, bevor Sie eine öffentliche Kontaktseite veröffentlichen. Ein typisches SMTP-.env-Setup sieht so aus:

MAIL_* steuert den Laravel-Mailversand für Benachrichtigungsversuche des Kontaktformulars. MAIL_FROM_ADDRESS ist die sichere Fallback-Absenderadresse und zugleich der letzte sichere Empfänger-Fallback des Kontaktformulars, wenn kein spezifischerer Empfänger konfiguriert ist. CONTACT_RECIPIENT_EMAIL ist optional und dient als Fallback-Empfänger auf Umgebungsebene. Bevorzugen Sie, wenn verfügbar, die Konfiguration des Kontakt-Empfängers auf Site-Ebene unter Site -> Edit -> Contact, damit das Kontakt-Routing bei der Site liegt und nicht nur in .env.

Leeren Sie nach dem Ändern der .env-Maileinstellungen in Produktions- oder Paketinstallationen die zwischengespeicherte Konfiguration, wenn die Installation Config-Caching verwendet:

Kontaktformular-Benachrichtigungen lösen Empfänger in dieser Reihenfolge auf:

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

Angenommene echte Kontaktformular-Übermittlungen werden gespeichert, bevor eine E-Mail-Benachrichtigung versucht wird. Ein Benachrichtigungsfehler bedeutet nicht, dass die öffentliche Formularübermittlung fehlgeschlagen ist. Admins sollten /webadmin/contact-messages auf gespeicherte Nachrichten, den Benachrichtigungsstatus und sichere Fehlerdetails prüfen. Öffentliche Besucher sollten nur normales Erfolgs- oder Validierungsfeedback sehen, keine Mail-Diagnosen.

Sent bedeutet, dass das CMS die Benachrichtigung ohne Exception an den konfigurierten Mail-Transport übergeben hat; es garantiert keine Zustellung in den Posteingang. Skipped oder Not configured bedeutet, dass kein echter Benachrichtigungsversand versucht wurde.

Verwenden Sie für Kontaktseiten den nativen contact_form-Block. Ersetzen Sie ihn nicht durch Trusted HTML, rohes <form>-Markup oder mailto:-Fallbacks. Der CMS-Renderer generiert das versteckte Anti-Spam-Prüffeld automatisch; legen Sie es nicht manuell an. Das alte website-Honeypot-Feld ist nicht mehr Teil des öffentlichen Vertrags.

Praktischer Kontaktformular-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 mit Name, E-Mail, Betreff und Nachricht.
3. Öffnen Sie /webadmin/contact-messages.
4. Bestätigen Sie, dass die Nachricht gespeichert wurde.
5. Prüfen Sie den Benachrichtigungsstatus.
6. Wenn die E-Mail nicht angekommen ist, sehen Sie sich die sicheren Fehlerdetails an und führen Sie die Mail-Diagnose aus.

Diagnosebefehle:

Der Diagnosebefehl darf keine Passwörter, Tokens oder Mail-Geheimnisse ausgeben. Verwenden Sie --block=ID, um die Empfänger-Fallback-Kette für einen einzelnen Kontaktformular-Block zu untersuchen. Verwenden Sie --send-test= nur für eine kontrollierte SMTP-Sendeprüfung an eine bewusst gewählte Testadresse.

1. Melden Sie sich unter /webadmin an.
2. Überprüfen Sie Ihre Site- und Sprachkonfiguration (Locale).
3. Konfigurieren Sie die Site-Identität und die Domains.
4. Konfigurieren Sie die Laravel-Maileinstellungen oder freigegebene System-Maileinstellungen.
5. Konfigurieren Sie einen Kontaktformular-Empfänger, vorzugsweise unter Site -> Edit -> Contact.
6. Führen Sie php artisan contact:mail-diagnose aus.
7. Senden Sie ein natives Test-Kontaktformular und bestätigen Sie, dass es eine Kontaktnachricht speichert.
8. Überprüfen Sie den E-Mail-Benachrichtigungsstatus für diese Testnachricht.
9. Öffnen Sie die Startseite im Editor und passen Sie sie an.
10. Erstellen Sie Ihre erste Seite.
11. Fügen Sie Medien, Navigation und Blöcke hinzu.
12. Veröffentlichen Sie Inhalte über den redaktionellen Workflow.

Der integrierte Standardmodus bewahrt öffentliche Root-URLs. Für den Betrieb neben einem Laravel-Produkt konfigurieren Sie vor Installation/Bereitstellung WEBBLOCKS_CMS_PUBLIC_MOUNT=wb: Inhalte, Suche und Sitemap verwenden dann /wb; Admin/API/Assets/Formulare behalten eigene Bereiche. Die Host-Willkommensroute bleibt erhalten. Dies ist eine installationsweite Konfiguration, keine Panel- oder Site-Einstellung. Lesen Sie vor Änderungen Öffentliches Routing, insbesondere zu Cache-Neuaufbau, Host-Catch-alls, robots-Zuständigkeit und URL-Migration.