This chapter collects the most common failure patterns from earlier chapters in one place - as a reference for when a Hyvä page behaves unexpectedly.

Error 1: Alpine interactivity doesn't react at all

Symptom: buttons/filters (like the team page's category buttons from chapter 21) look normal but don't respond to clicks.

• Open the browser console (F12 > Console) - a CSP violation message like "Refused to execute inline script..." points to a missing $hyvaCsp->registerInlineScript() (chapters 9 and 22).
• Check whether x-data actually contains valid JavaScript - a syntax error in the expression (e.g. a missing comma) makes Alpine silently skip the entire component.
• Check whether Alpine itself even loaded - a look at the Network tab for the Hyvä JS file is usually enough.

Error 2: CSS changes don't show up

Symptom: a new Tailwind class in a template visibly has no effect, even though the class is written correctly.

1. Is the Tailwind watcher even still running? (bin/cli ps aux | grep tailwind, see chapter 5)
2. Was the full deploy sequence run in the correct order, if this is a deployable environment (chapter 27)?
3. Rule out browser caching: hard reload with Ctrl/Cmd + Shift + R.
4. Does the class even exist in the built CSS file? Tailwind only generates CSS for classes it actually finds in the source code - a class dynamically assembled from PHP variables (e.g. "text-" . $color) isn't detected by Tailwind's scanner.

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

Symptom: Magento throws an error directly instead of rendering the page at all (as briefly mentioned in chapter 18).

• Does the template path in the Layout XML exactly match the actual file path (case sensitivity matters)?
• Is the referenced module even enabled (bin/magento module:status Mironsoft_TeamPage)?
• Was bin/magento setup:upgrade and a cache clean run after creating new files?

Error 4: ViewModel data doesn't reach the template

Symptom: $block->getData('team_view_model') returns null instead of the ViewModel.

• Does the argument name="..." value in the Layout XML exactly match the name retrieved in the template (chapter 19)?
• Was the layout cache cleared after a Layout XML change (bin/magento cache:clean layout or bin/cache-clean)?
• Is the <argument> entry really inside the right <block> element, not accidentally in a sibling block?

A systematic approach instead of guessing

The same basic pattern applies to all four failure types: check the browser console first (JavaScript/CSP errors), then Magento's own error output or bin/log exception.log, then cache status, and only search the code itself last. Most wasted debugging time comes from searching directly in the code for an error that's actually a cache or registration problem.