# The layout broke after an edit

> A page whose blocks have all stacked vertically, with no colours or spacing, has not lost its content: it has lost its stylesheet. That specific symptom has few possible causes, and the browser names them itself in a tab few people open.

- Source canonique : [https://allaux.fr/en/problemes/affichage-casse-apres-modification-du-theme](https://allaux.fr/en/problemes/affichage-casse-apres-modification-du-theme)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open the Network tab of the browser developer tools (F12), reload and filter on CSS: the file returning 404 or blocked names the cause. On PrestaShop, regenerate from Advanced Parameters > Performance and empty var/cache; on WordPress, switch off minification in the optimisation plugin before touching the theme.

## The browser tells you what is missing

The developer tools built into every browser include a network tab listing each requested file and the response code received. A failing stylesheet shows there in red, with its full address. That is the decisive information: it says whether the file is absent, refused, or served empty.

A second tab, the console, shows script errors. A single error stops execution of everything that follows in the same file — which is why a menu, a carousel and a button can all stop working together because of one faulty line. Those two tabs usually answer "where did this break" in under a minute.

## What I find behind this symptom

- The assembled stylesheet was not regenerated after the edit: it still refers to the old structure.
- Automatic file compression failed on a syntax error, producing a file truncated from that line onwards.
- An edit made in the parent theme while the child theme is active: the edited file is never loaded.
- A theme update overwrote customised files, because the changes had been made directly inside them.
- A module added its own stylesheet after the theme’s, and its rules override the intended ones.

## Getting back to a healthy state

1. **Identify the scope** — One page, one page type, or the whole site? A fault on every page points to a global file; a fault on one page points to content or a module specific to it.
2. **Look at the network tab** — Spot the failing files. A failing address means a path that has become wrong, often after a site move or an address change.
3. **Temporarily disable compression** — If the layout is correct without compression, the problem is in the assembly, not in your style rules. A quick and reversible test.
4. **Compare with the default theme** — Switching to a standard theme for a few seconds says whether the breakage comes from the theme or elsewhere. Do it outside busy periods.

## Never edit a purchased theme’s files directly

> Any theme update will overwrite those files, and the change will vanish without warning. Customisation belongs in a child theme, or in the slots the theme provides. That is what makes an update safe instead of dreaded.

## Carry on with the right page

- **Creating a WordPress child theme** — How to customise without losing changes at the next update. ([/guides/creer-theme-enfant-wordpress](/guides/creer-theme-enfant-wordpress))
- **CSS bugs after a PrestaShop theme change** — The PrestaShop case, with file compression and overrides. ([/prestashop/problemes/bugs-css-responsive-apres-theme](/prestashop/problemes/bugs-css-responsive-apres-theme))
- **Broken navigation menu** — If the fault mainly affects the menu, often script-related. ([/wordpress-woocommerce/problemes/menu-navigation-casse](/wordpress-woocommerce/problemes/menu-navigation-casse))
- **The child theme explained** — Why it exists, and exactly what it protects. ([/glossaire/theme-enfant](/glossaire/theme-enfant))

## FAQ

### The layout is fine for me and broken for customers. Why?

Your browser still holds the old, valid stylesheet, while new visitors get the broken version. A forced reload or private browsing reveals what your customers see.

### Can I just reinstall the theme?

Reinstalling overwrites customisations made inside its files. If they were not isolated in a child theme, they will be lost. Check what was changed and where first.

### Can a single script error break several features?

Yes, and it is very common. Execution stops at the error: everything defined after it, in the same assembled file, never runs.

### The problem appeared with nobody touching the theme. Possible?

Yes: a module update adding its own stylesheet, a site address change, or enabling a delivery network can all be enough.

### Should I rebuild the theme?

Almost never for this kind of failure. Rebuilding a theme is a project; here it is one file or one rule to correct. I always start by identifying which.