490e9adbd8
- Introduced custom branding CSS styles in `custom-branding.css`. - Created example JSON configuration for custom branding in `custom-branding.example.json`. - Implemented branding configuration logic in `BrandingConfig.ts` to normalize and validate branding settings. - Developed CSS loader to manage loading and unloading of custom stylesheets in `BrandingCssLoader.ts`. - Added DOM rendering capabilities for branding elements in `BrandingDomRenderer.ts`. - Defined types and interfaces for branding elements and configurations in `BrandingTypes.ts`. - Included localization support for German in `de-de.js`. - Added unit tests for branding configuration, CSS loader, and DOM renderer. - Validated project structure and static assets with new validation scripts.
121 lines
7.0 KiB
Markdown
121 lines
7.0 KiB
Markdown
# CustomBranding – Umsetzungsstand
|
||
|
||
Analysestand: 20.07.2026
|
||
Umgesetzt: 20.07.2026
|
||
Ausgangsversion: 1.0.4
|
||
Zielversion: 3.0.0
|
||
Status: Implementierung und lokale Qualitätssicherung abgeschlossen
|
||
|
||
## Zielbild
|
||
|
||
CustomBranding wird pro Site Collection genau einmal über eine `SPSite.UserCustomAction` registriert und konfiguriert. Moderne und klassische Seiten lesen dieselben versionierten `ClientSideComponentProperties`. Es werden weder eine versteckte Liste noch ein Property Bag eingesetzt. PortalSettings bleibt in diesem Durchlauf unverändert; der Vertrag für das spätere PortalSettings-v3-Webpart ist in der README dokumentiert.
|
||
|
||
## Sicherheit und Konfigurationsmodell
|
||
|
||
- [x] Stringbasiertes HTML und `innerHTML` durch einen DOM-Renderer ersetzt.
|
||
- [x] Laufzeit-Whitelist für Elementtypen umgesetzt.
|
||
- [x] Globale und elementspezifische Attribut-Allowlisten umgesetzt.
|
||
- [x] Alle Ereignisattribute `on*` gesperrt.
|
||
- [x] Relative URLs, HTTP/HTTPS und `mailto` kontrolliert; `javascript:` und `data:` gesperrt.
|
||
- [x] `target="_blank"` automatisch mit `noopener noreferrer` abgesichert.
|
||
- [x] Style-Property-Allowlist und Prüfung gefährlicher CSS-Werte umgesetzt.
|
||
- [x] Externe Stylesheets nur per HTTPS und expliziter Host-Allowlist ermöglicht.
|
||
- [x] Limits für Konfigurationsgröße, Rekursion, Elemente und Stylesheets umgesetzt.
|
||
- [x] Versioniertes Schema 2 eingeführt.
|
||
- [x] Bestehende 1.x-Konfigurationen mit Root-Property `elements` weiter unterstützt.
|
||
- [x] `enabled`, `debug`, `allowedCssHosts`, `cssfiles`, Top und Bottom konsistent typisiert.
|
||
- [x] Unbekannte Properties werden ignoriert; Warnungen erscheinen nur im Debug-Modus.
|
||
- [x] Keine feste Abhängigkeit oder Verlinkung zu PortalSettings mehr vorhanden.
|
||
|
||
## Lifecycle und Stylesheet-Management
|
||
|
||
- [x] Top- und Bottom-Placeholder werden unabhängig angefordert und gerendert.
|
||
- [x] Nach dem Dispose eines einzelnen Placeholders kann dieser später erneut erworben werden.
|
||
- [x] `changedEvent` wird beim Extension-Dispose deregistriert.
|
||
- [x] Dispose ist idempotent und setzt alle eigenen Referenzen zurück.
|
||
- [x] Eigene Hosts werden entfernt, fremde Knoten bleiben erhalten.
|
||
- [x] CSS-URLs werden absolut normalisiert und instanzübergreifend dedupliziert.
|
||
- [x] Reihenfolge und optionale `media`-Angabe bleiben erhalten.
|
||
- [x] Ladefehler und Timeouts werden debug-gesteuert protokolliert.
|
||
- [x] Fremde vorhandene Stylesheets werden wiederverwendet und nie entfernt.
|
||
- [x] Nur Stylesheets der letzten eigenen Referenz werden beim Dispose entfernt.
|
||
|
||
## Barrierefreiheit und Mehrsprachigkeit
|
||
|
||
- [x] Bilder ohne `alt` werden verworfen; dekorative Bilder mit leerem `alt` sind möglich.
|
||
- [x] Buttons erhalten immer `type="button"`; leere Links und Buttons werden verworfen.
|
||
- [x] ARIA-Attribute sind auf eine feste Allowlist begrenzt.
|
||
- [x] Fehlermeldungen verwenden `role="status"`.
|
||
- [x] Deutsches und englisches Localized Resource Bundle ergänzt und verwendet.
|
||
- [x] Debug-gesteuerter Logger mit einheitlichem Präfix umgesetzt.
|
||
- [x] Beispiel-CSS mit sichtbaren Fokuszuständen, responsivem Layout und Forced-Colors-Regel ergänzt.
|
||
- [ ] Tastaturbedienung, 200-Prozent-Zoom und Windows-Hochkontrast in der Zielumgebung manuell abnehmen.
|
||
|
||
## Bereitstellung und Scope
|
||
|
||
- [x] Paket auf `skipFeatureDeployment` und zentrale `SPSite.UserCustomAction` umgestellt.
|
||
- [x] Alte web-scoped Feature-Registrierung und `sharepoint/assets/elements.xml` entfernt.
|
||
- [x] Nicht verwendete Azure-Storage-Konfiguration entfernt.
|
||
- [x] SharePoint-SE-Deploymentskript verwendet zuerst das PowerShell-Modul und nur als Fallback das Snap-in.
|
||
- [x] Doppelte Site- und alte Web-Actions werden idempotent bereinigt.
|
||
- [x] Vorhandene Properties bleiben standardmäßig erhalten.
|
||
- [x] Bewusste Optionen für Reset, Debug, Disable und externe CSS-Hosts ergänzt.
|
||
- [ ] Root Web, vorhandenes Subweb und anschließend neu angelegtes Subweb auf dem Zielserver abnehmen.
|
||
|
||
## MegaMenu-Integration
|
||
|
||
- [x] Stabile Hosts `CustomHeader`, `CustomBrandingTopHost`, `MegaMenuHost`, `CustomFooter` und `CustomBrandingBottomHost` definiert.
|
||
- [x] Renderer verändert ausschließlich eigene Host-Inhalte.
|
||
- [x] Wiederholtes Rendern löscht den `MegaMenuHost` oder fremde DOM-Knoten nicht.
|
||
- [x] Gemeinsamer Betrieb und Ownership in der README dokumentiert.
|
||
- [ ] Beide realen Lade-Reihenfolgen mit installiertem MegaMenu auf dem Zielserver abnehmen.
|
||
|
||
## Classic SharePoint
|
||
|
||
- [x] Classic-Unterstützung als fachliches Ziel bestätigt.
|
||
- [x] Separate ES5-Runtime ohne SPFx-Abhängigkeit erstellt.
|
||
- [x] Classic-Runtime verwendet dasselbe zentrale Schema und dieselben Sicherheitsgrenzen.
|
||
- [x] Automatischer Classic-Build über `npm run build:classic` umgesetzt.
|
||
- [x] Optionaler site-scoped ScriptLink im Deploymentskript ergänzt.
|
||
- [x] Bereitstellung, Entfernung und Browserdiagnose dokumentiert.
|
||
- [ ] Classic-Listen-, Bibliotheks- und Publishing-Seite auf dem Zielserver visuell abnehmen.
|
||
|
||
## Projektbereinigung und Dokumentation
|
||
|
||
- [x] Node-Engine auf `>=6.9.0 <9.0.0` gesetzt und Node.js 8.17.0 dokumentiert.
|
||
- [x] Package und Solution konsistent auf Version 3.0.0 angehoben.
|
||
- [x] Nicht verwendete Abhängigkeit `@microsoft/sp-dialog` entfernt.
|
||
- [x] Localized Resources aktiviert und ergänzt.
|
||
- [x] `serve.json` auf das echte, sichere Schema korrigiert.
|
||
- [x] Nicht verwendete Dateien entfernt.
|
||
- [x] README mit Architektur, Schema, Sicherheitsgrenzen, Deployment, Classic, Upgrade und Diagnose neu erstellt.
|
||
- [x] Sichere JSON- und CSS-Beispiele ergänzt.
|
||
|
||
## Automatisierte Qualitätssicherung
|
||
|
||
- [x] Testbare Module für Normalisierung, URLs, Attribute, Styles, DOM und CSS-Loading ausgelagert.
|
||
- [x] Positivtests für alle erlaubten Elementtypen ergänzt.
|
||
- [x] Negativtests für Tags, Event-Attribute, URLs, Styles und fehlendes `alt` ergänzt.
|
||
- [x] Tests für Legacy-Schema, Schema 2, Tiefen- und Größenlimit ergänzt.
|
||
- [x] DOM-Test für sichere Elementerzeugung und Cleanup ergänzt.
|
||
- [x] CSS-Tests für Deduplizierung, Reihenfolge, Referenzen und fremde Stylesheets ergänzt.
|
||
- [x] Statische Prüfungen für JSON, Konfiguration, Lifecycle-Regeln, Classic-JavaScript und PowerShell ergänzt.
|
||
- [x] `npm test` als zwingendes Gate vor `npm run package` eingebaut.
|
||
- [x] Classic-Build als Teil der Paketierung automatisiert.
|
||
- [x] Ship-Build mit Node.js 8.17.0 als abschließender Zielserver-Schritt dokumentiert.
|
||
|
||
## Lokale Prüfergebnisse
|
||
|
||
- [x] Hauptprojekt kompiliert mit TypeScript ohne Ausgabe.
|
||
- [x] `npm test`: 32 Config-, 6 DOM-, 8 CSS- und 20 statische Prüfungen erfolgreich.
|
||
- [x] PowerShell-Syntax für Deployment und Classic-Build erfolgreich geprüft.
|
||
- [x] Classic-Build erzeugt beide Distributionsdateien erfolgreich.
|
||
|
||
## Noch offene Abnahme auf SharePoint SE
|
||
|
||
1. Ship-Paket mit Node.js 8.17.0 bauen und im App Catalog aktualisieren.
|
||
2. Zentrale Registrierung mit `deployment/add-custombranding.ps1` herstellen.
|
||
3. Moderne Seiten in Root Web, bestehendem und neuem Subweb prüfen.
|
||
4. MegaMenu-Ladereihenfolgen sowie Tastatur, Zoom und Hochkontrast prüfen.
|
||
5. Optional Classic-Runtime bereitstellen und klassische Seitentypen prüfen.
|