Typische Fehler und wie man sie debuggt (fehlendes registerInlineScript, CSP-Verletzungen, hartnäckige Caches)

~9 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026

Dieses Kapitel sammelt die häufigsten Fehlerbilder aus den vorherigen Kapiteln an einer Stelle - als Nachschlagewerk für den Fall, dass eine Hyvä-Seite sich unerwartet verhält.

Fehler 1: Alpine-Interaktivität reagiert gar nicht

Symptom: Buttons/Filter (wie die Kategorie-Buttons der Team-Seite aus Kapitel 21) sehen normal aus, reagieren aber nicht auf Klicks.

Browser-Konsole öffnen (F12 > Konsole) - eine CSP-Verletzungsmeldung wie "Refused to execute inline script..." deutet auf fehlendes $hyvaCsp->registerInlineScript() hin (Kapitel 9 und 22).
Prüfen, ob x-data überhaupt gültiges JavaScript enthält - ein Syntaxfehler im Ausdruck (z. B. ein fehlendes Komma) lässt Alpine die gesamte Komponente stillschweigend überspringen.
Prüfen, ob Alpine selbst überhaupt geladen wurde - ein Blick in den Netzwerk-Tab auf die Hyvä-JS-Datei genügt meist.

Fehler 2: CSS-Änderungen werden nicht angezeigt

Symptom: Eine neue Tailwind-Klasse im Template hat sichtbar keinen Effekt, obwohl die Klasse korrekt geschrieben ist.

Läuft der Tailwind-Watcher überhaupt noch? (bin/cli ps aux | grep tailwind, siehe Kapitel 5)
Wurde die volle Deploy-Sequenz in korrekter Reihenfolge ausgeführt, falls es sich um eine deploybare Umgebung handelt (Kapitel 27)?
Browser-Cache ausschließen: harter Reload mit Strg/Cmd + Shift + R.
Existiert die Klasse überhaupt in der gebauten CSS-Datei? Tailwind erzeugt nur CSS für Klassen, die es im Quellcode tatsächlich findet - eine dynamisch aus PHP-Variablen zusammengesetzte Klasse (z. B. "text-" . $color) wird von Tailwinds Scanner nicht erkannt.

Achtung: Der letzte Punkt ist ein häufiger, unerwarteter Stolperstein: Tailwind analysiert Quellcode statisch nach vollständigen Klassennamen. Eine Klasse, die erst zur Laufzeit aus mehreren Teilen zusammengesetzt wird, taucht in der gebauten CSS-Datei schlicht nicht auf. Lösung: vollständige Klassennamen im Quellcode verwenden (z. B. über eine Lookup-Tabelle mit fest ausgeschriebenen Klassen statt String-Konkatenation).

Fehler 3: "Template file ... does not exist"

Symptom: Magento wirft direkt einen Fehler, statt die Seite überhaupt zu rendern (wie in Kapitel 18 kurz erwähnt).

Stimmt der Template-Pfad im Layout-XML exakt mit dem tatsächlichen Dateipfad überein (Groß-/Kleinschreibung zählt)?
Ist das referenzierte Modul überhaupt aktiviert (bin/magento module:status Mironsoft_TeamPage)?
Wurde nach dem Anlegen neuer Dateien bin/magento setup:upgrade und ein Cache-Clean ausgeführt?

Fehler 4: ViewModel-Daten kommen nicht im Template an

Symptom: $block->getData('team_view_model') liefert null statt des ViewModels.

Stimmt der argument name="..."-Wert im Layout-XML exakt mit dem Namen überein, der im Template abgerufen wird (Kapitel 19)?
Wurde nach einer Layout-XML-Änderung der Layout-Cache geleert (bin/magento cache:clean layout oder bin/cache-clean)?
Steht der <argument>-Eintrag wirklich innerhalb des richtigen <block>-Elements, nicht versehentlich in einem Geschwister-Block?

Systematisches Vorgehen statt Rätselraten

Bei allen vier Fehlerbildern gilt dasselbe Grundmuster: zuerst die Browser-Konsole prüfen (JavaScript-/CSP-Fehler), dann Magentos eigene Fehlerausgabe bzw. bin/log exception.log, dann Cache-Status, erst zuletzt am Code selbst suchen. Die meiste verlorene Debugging-Zeit entsteht dadurch, direkt im Code nach einem Fehler zu suchen, der eigentlich ein Cache- oder Registrierungsproblem ist.

Vorheriges Kapitel Die korrekte Deploy-Sequenz im Detail und warum die Reihenfolge zählt Nächstes Kapitel Zusammenfassung: Spickzettel aller wichtigsten Hyvä-Patterns aus dieser Serie