Wie WebBlocks CMS Frontend-Assets verwaltet

WebBlocks CMS liefert das für seinen Admin-Arbeitsbereich und seine öffentlichen Renderer erforderliche CSS und JavaScript als einsatzbereite Paketressourcen.

Die CMS-Version enthält ihre Browserdateien. Das Installationsprogramm veröffentlicht sie im öffentlichen Verzeichnis der Host-Laravel-Anwendung, wo der Webserver sie als statische Dateien bereitstellt.

WebBlocks CMS beinhaltet und verwaltet seine JavaScript-Laufzeit als Teil der Paketveröffentlichung.

WebBlocks CMS unterteilt seine Browser-Assets in drei explizite Eigentumsebenen:

1. CMS-Kernressourcen laufen unter public/cms und ändern sich mit der CMS-Version.
2. Überschreibungen auf Site-Ebene sind unter public/site/{site_handle}/css/site.css und public/site/{site_handle}/js/site.js verfügbar.
3. Assets auf Seitenebene können für einen engeren seitenspezifischen Bedarf auf genehmigtes lokales /site/... CSS oder JavaScript verweisen.

Die Pfade machen Eigentum sichtbar. Eine Datei unter /cms gehört zur Produktversion. Eine Datei unter /site/{site_handle} gehört zu dieser Installation und Site.

WebBlocks CMS speichert CMS-eigene Laufzeitressourcen unter dem Namespace public/cms. Das Paketinstallationsprogramm und das Veröffentlichungs-Tag webblocks-cms-assets kopieren die verfolgten Assets des Pakets in das öffentliche Dokumentstammverzeichnis des Hosts.

Admin-Stile, öffentliche Rendering-Stile, Produktmarken-Assets und gezielte JavaScript-Verhaltensweisen gehören zu der CMS-Version, die sie verwendet. Sie werden mit dem PHP-Code freigegeben und getestet.

Die öffentlichen URLs bleiben normale statische URLs. Laravel muss nicht jedes Stylesheet oder Skript über einen Controller streamen. Der Webserver kann vorhandene Dateien direkt bereitstellen, während Laravel Anwendungsrouten verwaltet.

Dies erklärt auch, warum /cms ein Asset-Namespace und keine Admin-Route ist. Die Bedienoberfläche befindet sich unter /webadmin; Durch die Trennung von Routenbesitz und Dateisystembesitz werden try_files-Kollisionen in gängigen Nginx-Bereitstellungen vermieden.

WebBlocks CMS bietet eine separate Erweiterungsgrenze für installationseigene visuelle Anpassungen.

Native Blockeinstellungen und WebBlocks UI-Tokens handhaben die normale Präsentation. Site-Überschreibungen sind für die installationsspezifische Komposition reserviert, die zu dieser Site gehört.

Durch die erneute Veröffentlichung von CMS-Assets werden paketeigene Dateien ersetzt, während die Website-eigenen Überschreibungen erhalten bleiben. Korrekturen am CMS-Kern werden über CMS-Releases bereitgestellt.

WebBlocks CMS liefert JavaScript für seine Admin-Workflows und die öffentliche progressive Erweiterung.

Vom Server gerendertes HTML bleibt die Basis. Fokussierte Skripte verbessern Navigation, Medienanzeige, Suche, Modaldialoge und Bearbeitungsworkflows. Benannte JavaScript-Dateien werden mit defer geladen; Öffentliche Renderer verbergen das Anwendungs-Bootstrapping nicht in beliebigen Inline-Skripten.

Der Release-Prozess WebBlocks CMS umfasst Browserkompatibilität, Zugänglichkeit, Asset-Reihenfolge, Cache-Invalidierung und Interaktionen zwischen diesen Skripten.

WebBlocks CMS versioniert browserbasierte Assets, sodass zwischengespeicherte Dateien aktuell bleiben.

CMS-Layouts hängen einen Versionswert an paketeigene Asset-URLs an, üblicherweise basierend auf der Änderungszeit der installierten Datei. Außerkraftsetzungs-Assets auf Site-Ebene verwenden einen Inhalts-Hash. Wenn sich eine Datei ändert, ändert sich auch ihre URL, sodass der Browser die neue Darstellung anfordert, anstatt eine veraltete zwischengespeicherte Kopie wiederzuverwenden.

Das Paket fixiert außerdem seine WebBlocks UI-Laufzeitumgebung an einen versionierten lokalen Pfad. Der Browser benötigt kein Live-CDN eines Drittanbieters, um die CMS-Schnittstelle darzustellen, und die CMS-Version identifiziert die UI-Version, mit der er getestet wurde.

Ein Shipped-Asset-Modell gibt dem CMS-Release konkrete Verantwortlichkeiten:

• Quelländerungen müssen als überprüfbare Laufzeitdateien festgeschrieben werden.
• Der Freigabeprozess muss sicherstellen, dass alle erforderlichen Dateien vorhanden sind.
• Paketaktualisierungen müssen Laufzeitkopien sicher synchronisieren;
• Eine umfassende Frontend-Anpassung erfordert explizite Override- oder Plugin-Verträge.

Für den WebBlocks CMS-Kern gehören Browserkompatibilität und Asset-Vollständigkeit zur Paketversion. Die standortspezifische Darstellung bleibt Installationseigentum und vom CMS-Kern getrennt.

Welchen Teil dieser Asset-Grenze möchten Sie zuerst überprüfen: Veröffentlichung, Cache-Invalidierung oder Site-Überschreibungen?