PrestaShop: Theme-Erkennung und Stil-Overrides

Nutzen Sie gemeinsame Theme-Tokens, damit beteiligte Module Farben, Typografie und Bedienelementen Ihres Frontoffice folgen können. Prüfen Sie die erkannten Werte und die Integration jedes Moduls, bevor Sie sich auf das Ergebnis verlassen.

So würden wir vorgehen

Wir würden einer sichtbaren Abweichung nachgehen, bevor wir das Theme ändern. Das Vorgehen hängt von Ihrem bestehenden Theme und Child-Theme, Modulen, Kassenintegrationen, Katalogdaten, Märkten und dem betreuenden Team ab. Vereinbaren Sie, welche Komponenten übereinstimmen müssen und welche eigene Layoutanpassungen benötigen.

Proben Sie Änderungen am Theme oder an gemeinsamen Stilen auf einer Staging-Kopie, isoliert von Live-E-Mails, Zahlungen und Integrationsexporten. Dokumentieren Sie die bisherigen Einstellungen und Ressourcen, testen Sie die betroffenen Abläufe und planen Sie anschließend die Live-Umstellung mit einer benannten verantwortlichen Person und einem Verfahren zur Wiederherstellung der bisherigen Konfiguration und Dateien.

Wenn Sie die Kompatibilität eines vorgeschlagenen Themes vor der Auswahl bewerten lassen möchten, prüft das PrestaShop Theme Selection & Fit Assessment es anhand Ihrer Shopanforderungen.

Was die Theme-Erkennung liefern kann

Das Paket Theme Detector erfasst einen definierten Satz von Stilwerten. Dazu gehören Primär- und Sekundärfarben, Text- und Linkfarben, Seiten- und Komponentenhintergründe, Statusfarben, Rahmenfarben und -breiten, Radien, Schatten, Innenabstände von Schaltflächen und Eingabefeldern sowie Typografie. Die Typografie umfasst Fließtext, Überschriften, Einleitungstext, Beschriftungen, Bildunterschriften, kleinen Text, nichtproportionalen Text und Schaltflächen.

Dies sind ausgewählte Design-Tokens. Ein Modul benötigt weiterhin geeignetes Markup, Layouts und Komponentenstile. Prüfen Sie Modals, Kassenelemente und Drittanbieter-Widgets einzeln auf Theme-Kompatibilität.

Der Detektor liest benutzerdefinierte CSS-Eigenschaften und bekannte Selektoren. Er unterstützt außerdem einen deklarativen Theme-Vertrag und eine Browser-Abfrage berechneter Stile. Statische CSS-Analyse kann nicht jede Browser-Kaskade, jeden responsiven Zustand oder jedes dynamisch geladene Stylesheet nachbilden.

Classic und Hummingbird werden bei der Erkennung bereits unterstützt. Der Parser verarbeitet auch gängige Framework-Farben, einschließlich Warehouse/IQIT-Farben. Testen Sie die genaue Theme-Version und die von Ihrem Modul verwendeten Komponenten.

Das Ergebnis im Frontoffice prüfen

Bestätigen Sie den aktiven Shop, das Theme-Verzeichnis und das Eltern-Theme. Prüfen Sie sowohl ein Child-Theme als auch dessen Eltern-Theme.
Öffnen Sie die Darstellungseinstellungen des beteiligten Moduls. Dokumentieren Sie gespeicherte Anpassungen, die Adapterauswahl und, sofern entsprechende Bedienelemente vorhanden sind, ob benutzerdefinierte Ressourcen aktiviert sind. Bezeichnungen und Verfügbarkeit der Bedienelemente hängen von Modul und Version ab.
Prüfen Sie in einem eingebundenen Modul primäre Schaltflächen, Links, Eingabefelder, Fokuszustände, Modals, Rahmen und Typografie.
Prüfen Sie Desktop- und Mobilansichten, Tastaturfokus, Textkontrast sowie angebotene dunkle oder alternative Theme-Modi. Verwenden Sie echte Produktnamen und übersetzte Beschriftungen für die von Ihnen bedienten Märkte.
Ändern Sie auf Staging vorübergehend ein Token und prüfen Sie, dass sich nur die dafür vorgesehenen Komponenten ändern.
Entfernen Sie die Testanpassung, aktualisieren Sie gemeinsame Stile nach dem für Ihre Modulversion dokumentierten Verfahren und bestätigen Sie, dass die Erkennung oder der Theme-Standard wieder greift.
Wiederholen Sie dies nach einem Theme-Upgrade, einer Neuerstellung der Ressourcen oder einem Paketupdate. Testen Sie bei Multishop jedes Frontoffice separat.

Wenn ein Modul die Tokens ignoriert, benötigt es eine Integrationsänderung. Kein Detektor kann eine Komponente umgestalten, die seine Ausgabe nicht nutzt. Verwenden Sie für deren eigene Darstellungseinstellungen die Hilfeseite des jeweiligen Moduls.

Die nächste Prüfung nach dem Symptom wählen

Was Sie sehen	Nächste Prüfung	Was über die Korrektur entscheidet
Ein Modul behält die alte Markenfarbe bei.	Vergleichen Sie den erkannten Wert, die gespeicherte Anpassung und das geladene Stylesheet.	Korrigieren Sie die verantwortliche Einstellung oder veraltete Ressource, bevor Sie CSS ergänzen.
Die Farbe stimmt, aber ein Modal oder Kassenelement ist falsch positioniert.	Prüfen Sie Markup, Layoutregeln und den gewählten Adapter.	Ein Layoutfehler erfordert Arbeiten an Komponente oder Adapter.
Der gespeicherte Wert stimmt, aber der Browser zeigt eine andere Farbe.	Prüfen Sie die maßgebliche Regel und die Stylesheet-Antwort.	Unterscheiden Sie einen Kaskadenkonflikt von einer älteren zwischengespeicherten Datei.

Beispiel: Eine Modulschaltfläche behält die bisherige Farbe

Angenommen, Ihr neues Theme verwendet grüne primäre Schaltflächen, ein beteiligtes Modul zeigt aber weiterhin Blau. Auf Staging wird Grün als Primärfarbe erkannt und im Modul ist eine blaue Anpassung gespeichert. Dokumentieren und entfernen Sie diese Anpassung und aktualisieren Sie die gemeinsamen Stile. Wird die Schaltfläche grün, erklärt die gespeicherte Einstellung die Abweichung.

Bleibt sie blau, bitten Sie den Entwickler, die genaue Variable und die maßgebliche CSS-Deklaration dieser Schaltfläche zu bestimmen. Prüfen Sie vor einer weiteren Einstellungsänderung, ob ein vom Theme vorgegebener Token-Standard, eine verbleibende gemeinsame Anpassung, eine private Einstellung oder eine fest codierte Komponentenregel den blauen Wert liefert.

Wie Erkennung, Speicherung und Aktualisierung funktionieren

Die Erkennung beginnt mit Fallback-Werten, liest verfügbares Theme-CSS und ermittelt die unterstützten Eigenschaften. Das Paket ermittelt das aktive Theme-Verzeichnis und dessen deklariertes Eltern-Theme. Wenn kein geeignetes Theme-Stylesheet gefunden wird, kann die CSS-Suche auf ein verfügbares Hummingbird- oder Classic-Stylesheet zurückgreifen, oder die Erkennung behält die Paketvorgaben bei. Ein Fallback-Wert beweist nicht, dass das aktive Theme ihn verwendet. Ergebnisse werden innerhalb einer PHP-Anfrage wiederverwendet und für spätere Nutzung gespeichert. Erzeugte CSS-Dateien liefern gemeinsame Variablen und die von eingebundenen Modulen registrierten Aliase.

Eine Browser-Bestätigung ist dem Shop und dessen aktuellem Theme-Fingerabdruck zugeordnet. Eine Browser-Bestätigung veraltet nach sieben Tagen. Auch ein Theme-Wechsel oder eine erzwungene Aktualisierung kann eine erneute Erkennung erfordern. Dies ist eine interne Aktualitätsregel, kein vom Händler konfigurierbarer Aktualisierungsplan.

Der Live-Endpunkt akzeptiert eine Abfrage nur, solange die Erkennung aussteht. Er validiert die Werte vor dem Speichern. Eine abgelehnte Abfrage kann eine Wartezeit von sechs Stunden auslösen. Wenn keine Bestätigung erfolgt, prüfen Sie das Frontoffice-Skript, die Netzwerkanfrage und die Antwort, statt anzunehmen, dass das Öffnen einer Admin-Seite die Erkennung abschließt.

Aktualisieren Sie nach Änderungen an Theme-Ressourcen die gemeinsamen Stile über die vom eingebundenen Modul angebotenen Bedienelemente. Prüfen Sie das erzeugte Stylesheet und das Frontoffice. Ein CDN oder ein Cache für zusammengefasste Ressourcen kann weiterhin eine ältere Datei ausliefern, nachdem die gespeicherten Werte geändert wurden.

Gespeicherte Anpassungen und Fallback-Reihenfolge

Bei einem gemeinsamen Token hat eine vom Händler gespeicherte Anpassung Vorrang vor dem erkannten Wert. Für fehlende erkannte Werte werden unterstützte ältere Werte oder Paketvorgaben verwendet. Abhängige Tokens können einen anderen Wert übernehmen, etwa die Hintergrundfarbe eines Modals von der primären Komponentenfläche. Ungültige CSS-Werte werden abgelehnt oder durch eine sichere Vorgabe ersetzt.

Das erzeugte Stylesheet nutzt drei Spezifitätsebenen: erkannte Werte und Vorgaben auf html, vom Theme definierte Vorgaben auf :root oder html:root und ausdrücklich gespeicherte Einstellungen auf html:root:root. Innerhalb dieses Vertrags überschreiben Theme-Vorgaben die Erkennung und gespeicherte Einstellungen die Theme-Vorgaben. Lokales Komponenten-CSS folgt weiterhin der normalen Kaskade.

Sie können gemeinsame Shop-Anpassungen und modulspezifische Aliase oder eigene Einstellungen haben. Ein Modul muss einen Alias registrieren und nutzen, bevor dieser seine Oberfläche beeinflussen kann. Das Löschen einer Moduleinstellung kann eine darunterliegende gemeinsame Anpassung sichtbar machen.

Prüfen Sie den unveränderten erkannten Wert und den wirksamen gespeicherten Wert.
Prüfen Sie, ob eine gemeinsame oder modulspezifische Einstellung den Unterschied erklärt.
Löschen Sie die betreffende Anpassung, wenn Sie zur Erkennung zurückkehren möchten.
Aktualisieren Sie das Stylesheet und prüfen Sie anschließend den berechneten Stil der betroffenen Komponente.

Versuchen Sie nicht, eine falsch erkannte Farbe durch Änderungen an unbeteiligten Theme-Einstellungen zu korrigieren. Bestimmen Sie das tatsächliche Token und die maßgebliche CSS-Regel.

Theme-Adapter und eigene Ressourcen

Theme-Erkennung und Theme-Adapter lösen unterschiedliche Probleme. Tokens liefern Stilwerte. Ein Adapter liefert Modul-CSS oder -JavaScript für ein bestimmtes Theme. Das Front-Paket wählt Adapter aus und registriert sie; das Admin-Paket stellt die gemeinsame Einstellungsoberfläche bereit, wenn ein Modul sie einbindet.

Die automatische Adapterauswahl prüft das aktive Theme und anschließend dessen Eltern-Theme. Ein bestimmter mitgelieferter Adapter kann ausdrücklich gewählt werden, und none deaktiviert Adapter. Ein einzelnes Modul unterstützt ein Theme nur in dem Umfang, den sein mitgelieferter Adapter und das tatsächliche Verhalten im Frontoffice ermöglichen.

Eigene Ressourcen des Händlers sind optional und standardmäßig deaktiviert. Sie gehören in die Modul-Override-Verzeichnisse des Shop-Themes. Ein Modulupdate sollte diese Theme-Dateien erhalten, doch Sie müssen sie nach einem Theme- oder Modulupgrade erneut testen.

Halten Sie Detektor-, Front- und Admin-Pakete in bereitgestellten Modulen aufeinander abgestimmt. Prüfen Sie bei der Fehlersuche zu Unterschieden zwischen Installationen, welche Paketversion der Shop lädt.

Fragen an Ihren Entwickler oder Ihre Agentur

Senden Sie die betroffene Seiten-URL, den Shop-Kontext, die Versionen von Theme und Eltern-Theme, die Modulversion, Screenshots bei der fehlerhaften Ansichtsgröße und Schritte zur Reproduktion. Fügen Sie die relevanten gespeicherten Einstellungen und, falls verfügbar, den erkannten Wert, die geladene CSS-URL und die maßgebliche Deklaration bei.

Verwendet diese Komponente ein gemeinsames Token, einen registrierten Alias oder einen privaten Stil?
Welche geladenen Paket- und Adapterversionen wurden geprüft?
Welche Einstellung oder Datei wird geändert, und wie stellen wir sie wieder her?

Häufige Fragen von Shopbetreibern

Lädt eine Schrifteinstellung die Schriftart?

Ein font-family-Wert allein lädt keine Schriftdatei. Prüfen Sie bei abweichender Typografie neben der erkannten Schriftfamilie auch die Schriftanfragen und die tatsächlich vom Browser dargestellte Schriftart.

Beweist eine optisch passende Kasse, dass sie funktioniert?

Nehmen Sie einen abgeschlossenen Testkauf und die erwarteten Übergaben an Integrationen in die Abnahme auf. Eine übereinstimmende Optik bestätigt weder Bestellerstellung noch Zahlungs- oder Lieferverhalten.

Kann ich ein Theme anhand seiner Demo freigeben?

Nutzen Sie die Demo für eine Vorauswahl. Für die Freigabe brauchen Sie Nachweise mit Ihrem Katalog, Ihren Anpassungen und wesentlichen Modulabläufen auf der Shopkopie.

PrestaShop-Theme-Anpassung: Erkennung, Overrides und Fallbacks