ASSET-Übersicht 365CMS

Inhaltsverzeichnis#

• Aktive Runtime-Bundles
• Synchronisationsregeln
• CSS- und JavaScript-Architektur
• Build- und Update-Workflow
• Interne Bild-Assets
• Neue Kandidaten außerhalb der Runtime

Aktive Runtime-Bundles#

Führende Quelle für aktive Laufzeitpfade ist CMS/assets/ sowie der dokumentierte Sonderfall CMS/vendor/dompdf/. Das Root-Verzeichnis ASSETS/ ist Staging-/Quellmaterial, nicht die produktive Wahrheit.

Zusätzlich produktiv relevant:

• CMS/assets/autoload.php als zentraler PHP-Asset-Autoloader
• CMS/core/VendorRegistry.php als Diagnose-/Ladevertrag für gebündelte Libraries
• CMS/core/Services/PdfService.php als dokumentierter Dompdf-Einstieg

Synchronisationsregeln#

Die Synchronisation von /ASSETS nach /CMS/assets ist selektiv, nicht spiegelnd. Ein vollständiges Rekursiv-Kopieren ganzer Upstream-Repositories würde Tests, Build-Tooling, node_modules, Dokumentation oder falsche Laufzeitpfade mit in die Runtime tragen.

Wichtige Regeln im aktuellen Stand:

1. ASSETS/ ist Staging, CMS/assets/ ist Runtime.
2. Frontend-Bundles nur als Build-Artefakte übernehmen. Das gilt insbesondere für tabler, gridjs, PhotoSwipe, editor.js und suneditor.
3. editorjs bleibt kuratiert. Die Runtime orientiert sich an CMS/core/Services/EditorJs/EditorJsAssetService.php, nicht am gesamten Plugin-Baum; Zusatzartefakte wie delimiter.umd.js müssen bei neuen Plugin-Ständen gezielt gebaut oder aktualisiert werden.
4. suneditor ist ein Sonderfall. Für die Runtime werden suneditor.min.js, suneditor.min.css, suneditor-contents.min.css und src/langs/de.js aus dem gebauten Paketstand übernommen; fehlt dist/ nach einem frischen Upstream-Download, muss SunEditor zuerst lokal gebaut werden.
5. dompdf bleibt außerhalb von CMS/assets/. Der produktive Pfad ist CMS/vendor/dompdf/, geladen über CMS/vendor/dompdf/autoload.php.
6. Sicherheits- und Standard-Bibliotheken nicht umstrukturieren, solange der Autoload-Vertrag stabil bleiben muss. Das betrifft u. a. htmlpurifier, php-jwt, webauthn, twofactorauth, ldaprecord, mailer, mime und translation.

CSS- und JavaScript-Architektur#

CSS#

• Basis: Tabler plus 365CMS-spezifische Overrides in CMS/assets/css/
• Produktive Styles: admin.css, admin-tabler.css, admin-hub-*, hub-sites.css, main.css, member-dashboard.css, cms-cookie-consent.css
• Editor-Sonderfälle: SunEditor bringt eigenes CSS mit; Editor.js nutzt eigene Tool-/Block-Assets
• Theme-Trennung: Themes liefern zusätzliches Frontend-CSS in CMS/themes/<theme>/; globale Runtime-Assets bleiben davon getrennt

JavaScript#

• Zentrale Runtime-Zone: CMS/assets/js/
• Wichtige produktive Dateien: admin.js, admin-content-editor.js, admin-media-integrations.js, admin-seo-redirects.js, admin-system-cron.js, member-dashboard.js, photoswipe-init.js, cookieconsent-init.js
• Editor-Zonen:
  • Editor.js = kuratierter Block-Editor mit mehreren Plugin-Builds
  • SunEditor = Legacy-WYSIWYG für HTML-Eingabe
• Ladeverträge: Admin-/Frontend-Templates referenzieren Assets weiterhin manuell über ASSETS_URL, SITE_URL . '/assets', cms_asset_url() oder filemtime()-basierte Varianten

Build- und Update-Workflow#

Es gibt keine zentrale Repo-weite Bundling-Pipeline. Asset-Updates sind weiterhin ein dokumentierter manueller bzw. teilmanueller Pfad.

Empfohlener Ablauf pro Update:

1. Quellstand in /ASSETS prüfen
2. Nur den tatsächlich produktiven Runtime-Scope nach CMS/assets/ bzw. CMS/vendor/ übernehmen
3. CMS/assets/autoload.php sowie Core-Verträge (VendorRegistry, PdfService, Editor-Services) gegen Pfadänderungen prüfen
4. Falls ein Upstream nur Source-Dateien enthält, den Build lokal erzeugen und erst dann die Artefakte übernehmen
5. Doku synchron halten:
   • DOC/ASSET.md
   • DOC/assets/README.md
   • DOC/ASSETS_OwnAssets.md
   • DOC/ASSETS_NEW.md für neue Kandidaten außerhalb der Runtime

Interne Bild-Assets#

CMS/assets/images/ ist der produktive interne Bildbestand der Runtime. Der aktuelle Bestand umfasst 13 PNG-Dateien:

• zwei Dashboard-Icons für Admin und Member
• fünf Logos mit Text
• drei reine Schriftzüge
• drei Markenzeichen ohne Schriftzug

Die verbindliche Einzelauflistung mit Abmessungen und Verwendungszweck steht in DOC/assets/images/README.md. Neue Bilddateien sind dort und in DOC/FILELIST.md gemeinsam zu ergänzen.

Neue Kandidaten außerhalb der Runtime#

Folgende Pakete liegen unter /ASSETS, sind aber nicht produktiv in CMS/assets/ bzw. CMS/vendor/ integriert:

• symfony/cache (ASSETS/cache-8.0.8/)
• guzzlehttp/guzzle (ASSETS/guzzle-7.10.0/)
• adhocore/jwt (ASSETS/php-jwt_yuliyan_1.1.3/)
• weitere Beobachtungskandidaten wie monolog-bundle-4.0.2, msgraph-sdk-php-2.56.0

Hinweis seit 3.3.42: Tabler Icons wurden aus dem Beobachtungskandidaten-Status in die produktive Runtime übernommen. Die lokale Kopie unter CMS/assets/tabler-icons/ ersetzt externe jsDelivr-/Tabler-Icon-Webfont-Requests im Admin-Header.

Für diese Kandidaten gilt:

• nicht blind in die Runtime kopieren
• zunächst Service-/Adapter-Schnittstellen im Core definieren
• transitive Abhängigkeiten vollständig bewerten
• Betriebsrisiken, Provider-Abhängigkeiten und Secrets-/Rate-Limits vor Integration dokumentieren

Ausnahme im aktuellen Stand:

• symfony/ai-platform zählt nicht mehr als reiner Außenkandidat, weil die Basis jetzt produktiv unter CMS/assets/ai-platform/ liegt, vom zentralen Assets-Autoloader aufgelöst wird und in Diagnose -> Assets als Produktivpaket erscheint.
• Das ändert nicht den Architekturgrundsatz: weitere Provider-Bridges und Zusatzabhängigkeiten dürfen weiterhin nur kontrolliert über Core-Adapter und Feature-Gates in die Runtime wachsen.

Zusätzlich wichtig im aktuellen Stand:

• Das zuvor mitgeführte Paket stichoza/google-translate-php wurde bewusst aus /ASSETS entfernt und wird nicht weiter als aktiver Integrationskandidat geführt.
• Für Übersetzungs- und Rewrite-Funktionen ist stattdessen ein providerbasierter AI-Services-Ansatz vorgesehen; Details siehe ASSETS_NEW.md, ai/AI-SERVICES.md und den Admin-Kontext unter admin/system-settings/AI-SERVICES.md.

Die ausführliche Bewertungs- und Integrationsdoku dazu liegt in ASSETS_NEW.md.

Audit-Notiz zur Runtime-Integration#

• Die produktive PHP-Dependency-Ladung erfolgt überwiegend über CMS/assets/autoload.php.
• Die dokumentierte Ausnahme bleibt CMS/vendor/dompdf/autoload.php.
• Die produktiv eingebundenen Symfony-Bundles mailer, mime und translation deklarieren PHP >= 8.4; diese Mindestplattform ist deshalb Teil des offiziellen Runtime-Vertrags.
• Besonders update-sensibel bleiben Editor- und UI-Bundles mit Build-Artefakten (editorjs, suneditor, tabler, photoswipe, gridjs).
• Für künftige Pflege wäre eine kleine zentrale Asset-/Versionierungs-Registry sinnvoll, damit Pfadlogik, Existenzprüfung und Cache-Busting nicht über viele Dateien verstreut bleiben.