Del 3 av 12 i serien «Jeg bygde en komplett medlemskapsplattform i WordPress.»
En WordPress-side bør ikke feile fordi du oppdaterte temaet.
Det høres åpenbart ut. Men det er overraskende mange nettsider der ute som gjør akkurat det – fordi tilpasningene ligger direkte i temafilen, ikke i et child theme. Neste oppdatering overskriver alt. Noe slutter å virke. Man skjønner ikke hvorfor.
Løsningen er ikke å unngå oppdateringer. Det er å bygge arkitekturen riktig fra starten.
Hva Blocksy gir oss uten at vi gjør noe
Blocksy er basistemaet. Det gjør en del ting ekstremt bra rett ut av boksen, og det er verdt å forstå hva det er – fordi det er det du ikke trenger å bygge selv.
Header- og footer-builder. En visuell drag-and-drop-builder der du plasserer elementer – logo, navigasjon, søk, knapper – i rader. Fungerer for desktop og mobil separat. Ingen kode nødvendig.
Global fargepalett. Som vi gikk gjennom i del 2 – farger definert i Customizer flyter automatisk inn i block-editoren og brukes konsekvent gjennom hele siden.
Responsiv typografi. Blocksy håndterer skalering av tekststørrelser på tvers av skjermstørrelser. Du setter det opp én gang i Customizer, Blocksy tar seg av resten.
Eksport og import. Hele Blocksy-konfigurasjonen – fargepalett, typografi, header-layout, footer-layout, arkiv-innstillinger – kan eksporteres til én enkelt .dat-fil og importeres på en ny installasjon på sekunder. Det gjør det trivielt å flytte et oppsett fra lokal utvikling til produksjon, eller å gjenbruke konfigurasjonen på et nytt prosjekt.
Alt dette er i basistemaet. Child theme-et er ikke for å gjøre disse tingene – det er for alt det andre.
Child theme-strukturen – hva som bor hvor og hvorfor
Child theme-et er der alle tilpasninger lever. Prinsippet er enkelt: ingenting tilpasset skal røre Blocksy-kjernen. Oppdateres Blocksy, påvirker det ikke child theme-et.
Strukturen ser slik ut:
themes/nordtheme/
├── theme.json ← Overstyrer Blocksys defaults der nødvendig
├── functions.php ← Boot: fonter, stiler, auto-load av moduler
├── style.css ← Theme header (påkrevd av WordPress)
├── inc/extend/ ← PHP-moduler (auto-lastes)
│ ├── template-helpers.php
│ ├── blog-archive-helpers.php
│ └── ...
├── assets/styles/
│ ├── styles.scss ← Importerer partials
│ └── partials/ ← SCSS-kildefiler
├── dist/styles/
│ └── styles.css ← Kompilert CSS
└── template-parts/ ← Maler for arkiv, relaterte poster
Hvert element har én tydelig rolle. functions.php starter ingenting selv – den laster inn moduler. Modulene bor i inc/extend/ og er ansvarlige for sin egen funksjonalitet. assets/ inneholder kildekoden. dist/ inneholder det kompilerte resultatet som WordPress faktisk laster inn.
Auto-loading av PHP-moduler
Det vanlige opplegget i WordPress er å legge alt i functions.php. Det funker til det ikke funker lenger – én lang fil med hundrevis av linjer der alt er blandet sammen.
Her brukes en annen tilnærming. functions.php inneholder én enkelt mekanisme: auto-loading.
// Auto-load alle PHP-filer i inc/extend/
foreach ( glob( get_stylesheet_directory() . '/inc/extend/*.php' ) as $file ) {
require_once $file;
}Det betyr at du legger til en ny PHP-fil i inc/extend/, og den lastes automatisk. Du trenger ikke å registrere den noe sted. Du trenger ikke å huske å inkludere den i functions.php. Den er bare der og gjør jobben sin.
Det gjør kodebasen enkel å navigere og enkel å vedlikeholde. Vil du fjerne funksjonalitet? Slett filen. Vil du legge til? Opprett en ny.
Blocksy-eksporten – hele konfigurasjonen i én fil
.dat-filen er en av de mest undervurderte funksjonene i Blocksy. Den er en serialisert eksport av hele Customizer-konfigurasjonen: fargepalett, typografi per element, header-layout, footer-layout, arkiv-innstillinger, bakgrunnsfarger og custom CSS.
I praksis betyr det at du kan sette opp en ny WordPress-installasjon, installere Blocksy, importere .dat-filen – og ha hele det visuelle oppsettet på plass på under et minutt.
Det er også det som gjør rebranding håndterbart. Endrer du merkevaren, oppdaterer du Customizer, eksporterer en ny .dat-fil, og versjonshåndterer den i git. Hele historikken er sporbar.
Google Fonts og ytelse
Fonter lastet inn feil er en vanlig kilde til treg sidelasting. Strategien her er enkel: fontene lastes inn via wp_enqueue_style i functions.php med display=swap som parameter.
display=swap betyr at nettleseren viser en fallback-font umiddelbart mens Google Fonts lastes – siden ser ikke tom ut mens fonten hentes. Brukeren opplever ingen forsinkelse.
I tillegg brukes cache-busting på lokale stilark: stilene lastes med filens modifieringstid som versjonsnummer. Oppdaterer du CSS-en, får brukeren alltid fersk versjon – ikke en cachet gammel fil.
wp_enqueue_style(
'nordtheme-styles',
get_stylesheet_directory_uri() . '/dist/styles/styles.css',
[],
filemtime( get_stylesheet_directory() . '/dist/styles/styles.css' )
);Ingen plugins. Ingen kompliserte oppsett. To enkle grep som gjør en merkbar forskjell.
Hva dette betyr i praksis
Et child theme satt opp på denne måten er portabelt, oppdateringssikkert og enkelt å navigere. Du kan oppdatere Blocksy når som helst uten å bekymre deg for hva som går i stykker. Du kan flytte hele oppsettet til en ny server ved å kopiere child theme-mappen og importere .dat-filen. Du kan gi noen andre tilgang til kodebasen og de finner ut av strukturen på egenhånd.
Det er ikke ekstra arbeid å bygge det slik. Det er riktig arbeid gjort én gang.
Neste del: Innholdsarkitektur – posttyper, taksonomier og metadata som gjør navigasjon, søk og tilgangskontroll til løste problemer.
