App Studio virket. Alle kontrollene svarte, innholdet var riktig og siden returnerte HTTP 200. Likevel var den feil. På en bred desktopskjerm lå hele arbeidsflaten klemt inne i en kolonne på omtrent 620 piksler.
Feilen ble først tydelig da jeg åpnet den ferdige produksjonssiden i en ekte nettleser og målte layouten. Den erfaringen er en god påminnelse om at «det virker» alltid trenger et subjekt og en testflate.
Problemet lå i møtet mellom komponent og tema
App Studio var bygget som en bred arbeidsflate: kontroller på den ene siden og telefonforhåndsvisning på den andre. Isolert brukte komponenten plassen den fikk. I WordPress-produksjonen arvet den en breddebegrensning fra temaets ytre innholdsstruktur.
Det var altså ikke en knapp som manglet eller JavaScript som krasjet. Den nye komponenten og den eksisterende siden var begge forståelige hver for seg. Feilen oppsto når WordPress-mal, stilark og ferdig nettleserlayout ble satt sammen.
HTTP 200 er bare begynnelsen
Jeg hadde sett samme familie av feil tidligere. WordPress satte en gang inn et tomt avsnitt i en innholdsgrid. Det usynlige elementet tok den brede kolonnen, mens artikkelteksten ble presset ned til omtrent 220 piksler. Serveren svarte, teksten var der og lenkene virket. Opplevelsen var likevel ødelagt.
Disse feilene viser hvorfor kildekontroll og funksjonstester ikke er nok alene. En nettleser må også få vise hva alle lagene faktisk produserer sammen.
Min minste produksjonsmatrise
- Innhold: riktig H1, forventede lenker, ingen test- eller kundedata i offentlig kilde.
- Funksjon: knapper, navigasjon og tilstander gir riktig resultat etter cache og ny sidelasting.
- Layout: faktisk bredde, overflyt og lesbarhet måles på mobil, nettbrett og desktop.
- Nettleserfeil: konsollfeil og mislykkede forespørsler registreres for den avgrensede reisen.
- Gjenoppretting: førtilstanden og en eksakt rollback finnes før offentlig endring.
Hvorfor sluttkontrollen må skje i produksjon
Staging er nyttig, men deler ikke alltid nøyaktig samme mal, cache, pluginrekkefølge og URL-adferd som produksjon. Derfor bruker jeg staging til å redusere risiko og produksjonsnettleseren til å kontrollere den faktiske sluttflaten.
Etter bredderettelsen ble App Studio kjørt på nytt ved 390, 768 og 1440 piksler, i tillegg til en kontroll av inngangen fra forsiden. Først da kunne jeg si noe mer presist: Den avgrensede reisen besto på de navngitte visningene uten horisontal overflyt eller nettleserfeil.
«Ferdig» er en kjede, ikke en grønn lampe
Det viktigste er ikke at en enkelt test blir grønn. Kilde, innhold, funksjon, layout, offentlig rute og tilbakeføring må henge sammen. Når de gjør det, blir det også mulig å forklare nøyaktig hva som er kontrollert – og hva som fortsatt er ukjent.
App Studio worked. Every control responded, the content was correct, and the page returned HTTP 200. It was still wrong. On a wide desktop display, the entire workspace was squeezed into a column roughly 620 pixels wide.
The defect became obvious only when I opened the finished production page in a real browser and measured the layout. The experience is a useful reminder that “it works” always needs a subject and a named test surface.
The problem existed between the component and the theme
App Studio was built as a wide workspace: controls on one side and a phone preview on the other. In isolation, the component used the space it received. In WordPress production, it inherited a width restriction from the theme’s outer content structure.
This was not a missing button or crashing JavaScript. The new component and the existing page each made sense on their own. The defect appeared when the WordPress template, style sheets, and final browser layout were assembled.
HTTP 200 is only the beginning
I had encountered the same family of defect before. WordPress once inserted an empty paragraph in a content grid. The invisible element occupied the wide column while the article text was compressed to roughly 220 pixels. The server responded, the words existed, and the links worked. The experience was still broken.
These cases demonstrate why source checks and functional tests are not sufficient by themselves. A browser must also reveal what all layers actually produce together.
My minimum production matrix
- Content: the correct H1, expected links, and no test or client data in public source.
- Function: controls, navigation, and state changes behave correctly after caching and reloads.
- Layout: actual width, overflow, and readability are measured on mobile, tablet, and desktop.
- Browser errors: console errors and failed requests are collected for the bounded journey.
- Recovery: the previous state and an exact rollback exist before the public change.
Why the final check must happen in production
Staging is useful, but it does not always share exactly the same template, cache, plugin order, and URL behaviour as production. I therefore use staging to reduce risk and the production browser to inspect the actual final surface.
After the width correction, App Studio was run again at 390, 768, and 1,440 pixels, together with a check of its homepage entry. Only then could I make a more precise claim: the bounded journey passed on the named views without horizontal overflow or browser errors.
“Done” is a chain, not a green light
The important part is not that one test turns green. Source, content, function, layout, public routing, and recovery must connect. When they do, it also becomes possible to explain exactly what was verified—and what remains unknown.