Slutt å bygge om hvert WordPress-nettsted

Oppsummering

De fleste byråer bygger hvert WordPress-nettsted fra et tomt tema, selv når en felles grunnmur ville kuttet uker av timeplanen. Denne artikkelen argumenterer for at theme.json, blokkmønstre og dynamiske blokker lar deg standardisere strukturlaget samtidig som du bevarer hver kundes særegne design. Den tar direkte for seg de fem innvendingene som holder team tilbake fra å endre seg: «vi har forskjellige kunder», «egendefinerte blokker er dyre», «editoren er forvirrende», «vi mister hooks og filtre», og «FSE er ikke produksjonsklart». Hver innvending får et praktisk motargument og et konkret mønster du kan ta i bruk gradvis. Gevinsten er en repeterbar byggeprosess som fortsatt hedrer skreddersydd arbeid der det hører hjemme. Advarsel: ingen ett-klikks tilbakestillingsknapper er lovet.

Hvor mange av kundenettsidene dine deler så mye som én linje kode? Ikke copyright-linjen – faktisk kode. Hvis svaret er «nesten ingen», har du allerede følt smerten: den samme hero-seksjonen bygget opp igjen for niende gang, den samme team-grid-markupen kopiert fra ett prosjekt til det neste, de samme forbehandlingsjusteringene kryssreferert på tvers av et halvt dusin temaer. Du har også hørt forsvaret: «Hver kunde har forskjellige behov.» Sant. Konklusjonen alle trekker, derimot – at hvert nettsted trenger et skreddersydd fundament – er gal. WordPress-økosystemet gir deg nå en måte å standardisere strukturelle deler på uten å standardisere designet: theme.json for designtokener, blokkmønstre for gjentatt oppsett, og dynamiske blokker for de få funksjonene som trenger skikkelig server-side-logikk. Denne artikkelen handler om innvendingene som holder byråer tilbake fra å ta det steget, og hva som faktisk fungerer når du argumenterer imot dem.

Innvendingen «men hver kunde er forskjellig»

Det underliggende prinsippet: standardiser fundamentet, ikke overflaten. Grunnen til å holde strukturen i et felles bibliotek er nettopp å la det visuelle laget være fritt. En theme.json-fil er ikke et design – det er et sett med designtokener. Farger, avstand og typografi er verdier, ikke markup. Det er det kritiske skiftet: du kan dele markupen mens en per-nettsted theme.json får nettstedet til å se helt annerledes ut for et annet merke.

Ta to kunder: et advokatfirma og en utendørsforhandler. Designspråkene deres er lysår fra hverandre. Men begge trenger en hero-seksjon, et testimonial-grid, en call-to-action-stripe. I stedet for å bygge markupen på nytt for hver, vedlikeholder du tre blokkmønstre og lar hver kundes theme.json definere farger, fonter og avstand. Strukturen forblir identisk; designtokenene gjør den fra ett merke til det andre. Når forhandleren endrer fargepaletten neste vår, redigerer du én fil på nettstedet deres – ikke markupen i seks maler.

Praktisk betyr dette at teamet ditt lager mønstre som kode, registrerer dem i en delt plugin, og lar theme.json på hvert kundenettsted håndtere malingen. Mønsterets klassenavn blir arkitekturen din; verdiene blir variablene. Du kan til og med gå videre og utvide theme.json til å inkludere egendefinerte innstillinger for innholdstyper eller plugin-utdata, selv om du på et tidspunkt bygger et konfigurasjonsgrensesnitt i stedet for et nettsted – en felle diskutert i vår gjennomgang av å utvide theme.json. Hold det delte laget slankt: det skal bare inneholde det som går igjen på tvers av kunder. I det øyeblikket du legger til en innstilling «i tilfelle noen en gang vil ha den», har du laget en abstraksjon som vil koste mer å vedlikeholde enn den sparer.

Når du setter opp en ny kunde, bør de første tretti minuttene være: klon den delte mønster-pluginen, opprett en ny theme.json med kundens palett og skriftstørrelsesskala, og registrer logoen og bunnteksten deres. Det er ikke en egendefinert bygging; det er en konfigurasjonsoppgave. Det gjenværende kundespesifikke arbeidet går til innhold, struktur og eventuelle virkelig skreddersydde funksjoner. Dette er forskjellen mellom å bygge hvert hus fra bunnen av og å ha et sett prefabrikkerte plantegninger som du kan male om og tapetsere på nytt. Analogien er løs, men prinsippet holder: jo mer du dytter inn i theme.json-verdier, desto mindre må du røre markup.

En av de enkleste gevinstene er å faktisk se på hvordan blokkmønstre fungerer. Et mønster er bare en samling blokker med forhåndsdefinert innhold og styling. Du kan lagre hvilken som helst blokkkonfigurasjon som et mønster, og deretter kan en kunde sette det inn uten å måtte vite hvordan det er bygget. Det betyr at mønsteret blir et «inngangspunkt» for ikke-tekniske brukere. Når teamet ditt vedlikeholder det underliggende mønsteret i kode, får kunden et konsistent bibliotek uten å røre en eneste PHP-tagg.

Nå, forbeholdet jeg stadig vender tilbake til: ikke oversentraliser. En theme.json med en innstilling for hver tenkelig nyanse er et vedlikeholdssump. Delte mønstre bør være meningsfulle, ikke allmektige. Hvis en kunde trenger et radikalt annerledes oppsett – for eksempel en magasinforside med et stort utvalgsgrid – passer de kanskje ikke inn i standardmønsterbiblioteket ditt. Det er greit. Standardisering betyr at du vinner på de 80 % av prosjektene som er like, ikke at du tvinger hvert nettsted inn i samme form.

Innvendingen «egendefinerte blokker sprenger budsjettet»

Her er et motprinsipp som høres kjedelig ut, men som sparer penger: de fleste tingene du tror trenger en egendefinert blokk, trenger det ikke. Kjernblokker pluss et mønster kan dekke det overveldende flertallet av oppsett. Den egendefinerte blokken er siste utvei, ikke første tanke.

Det klassiske eksemplet er team-gridet. Hvis det er en engangsting, bruk kjernblokkene «kolonner» og «gruppe» og la kunden slippe inn en avatar manuelt. Hvis tre kunder ber om det samme gridet med samme «sosiale lenker under navnet»-struktur, har du nå en kandidat for et blokkmønster. Når det mønsteret begynner å samle nye alternativer – hovereffekter, sortering, vurderingsstjerner – blir mønsteret en uhåndterlig samling, og da er tiden inne for å skrive en egendefinert blokk. Feilen som skader budsjettet, er å hoppe rett til den egendefinerte blokken ved første forespørsel.

Et mer lumske scenario: kunden ber om en «case study-karusell». Den første instinkten er å tenke: «Jeg trenger en karusellblokk.» Men trenger de en karusell? Kanskje de trenger en horisontalt rullbar gruppe med innlegg, som kjernblokker kan håndtere med en «gruppe»-blokk og litt CSS. Eller kanskje de trenger en dynamisk liste over nylige case studies, som er en dynamisk blokk som spør CPT-en. Spørsmålet er ikke «hvilken funksjon vil kunden ha?» men «hvilke data avhenger den av?» Hvis dataene er statiske og redigerbare av kunden, vil et mønster holde. Hvis dataene kommer fra en databasespørring, er en dynamisk blokk berettiget. Hvis dataene må oppdateres i sanntid fra en API, ser du kanskje på en REST API-integrasjon i stedet – det krysser over i en annen type bygging.

Når du først bygger en blokk, er block.json din venn. Det er den eneste sannhetskilden for attributter, skript og stiler, noe som gjør blokken bærbar på tvers av prosjekter. Det lar deg også deklarere avhengigheter og oversettelser på en ren måte, noe som er avgjørende når du distribuerer et bibliotek på tvers av mange kundenettsteder. For innhold som avhenger av live data, gjengir en dynamisk blokk på serveren, så du trenger ikke å sende en JavaScript-pakke på hver sidevisning. Og hvis blokken din utvikler seg, kan du håndtere avskrivninger elegant slik at eksisterende innhold ikke går i stykker – guiden vår om blokkavskrivning går gjennom nøyaktig det mønsteret.

Før du bygger noe, kjør avgjørelsen gjennom dette rutenettet:

Tilnærming	Best for	Unngå når
Kjernblokk	Engangsting, enkle sider	Oppsettet gjentas på tvers av mange kunder og trenger rike alternativer
Blokkmønster	Gjentakbare oppsett uten logikk	Oppsettet trenger betingelser, dynamiske data eller komplekse interaksjoner
Egendefinert blokk	Gjentatt, datadrevet eller svært spesifikk atferd	Den eneste grunnen er en engangsseksjon som kan håndteres med en klasse

Du vil også tenke på blokknavn fra dag én. Et blokknavn er i hovedsak en kontrakt med innholdet ditt. Hvis du kaller den wagent/team-grid og senere omdøper den til wagent/team-carousel, vil du bryte eksisterende innhold med mindre du gir en avskrivningsbane. Velg generiske, formålsbaserte navn som ikke blir falsk reklame når blokken utvikler seg. Dette er en variant av navnedisiplinen vi alle har lært fra plugin-prefikser, og det gjelder like mye for blokknavn.

Den kontrare tolkningen her er det mest nyttige jeg kan si: den egendefinerte blokken du bygger fordi en kunde ba om «bare en liten greie» er nesten alltid en feil. Si nei høflig, lever en kjernblokk med en klasse, og spar timene. Du vil få mer respekt fra kunden – og en mindre linje i vedlikeholdsbudsjettet.

Innvendingen «kundene vil ødelegge editoren»

Denne innvendingen er halvveis riktig. Blokkeditoren i seg selv er ikke problemet; problemet er å gi kundene for langt tau. theme.json kan låse ned hva som er redigerbart: deaktivere maleditoren, begrense tillatte blokker, og sette standardstiler slik at en feilplassert kolonne gjør mindre skade. Noen kunder vil fortsatt klare å ødelegge ting, men du kan tørke en side tilbake til et lagret mønster med ett klikk – noe den klassiske editoren ikke kunne tilby.

La meg skissere et scenario. En kunde ringer og sier: «Jeg flyttet en seksjon, og nå ser hele siden feil ut.» Med et klassisk tema ville du logget inn, inspisert CSS-en, og sannsynligvis brukt en time på å fikse oppsettet. Med et blokkoppsett kan du åpne siden, velge innholdsområdet, og tilbakestille det til det lagrede mønsteret. Mønsteret er grunnlinjen; kundens endringer er overlegget. Når overlegget blir feil, fjerner du det. Det er ikke bare en bedre arbeidsflyt; det er en fundamentalt mer tilgivende editor.

Nå nyansen: de fleste kunder vil ikke redigere så mye i det hele tatt. De vil endre tekst, bytte bilder, og kanskje omorganisere en seksjon. Blokkmønsteret gir deg akkurat det uten å eksponere hele nettstedstrukturen. I den forstand er editoren ikke en leke; det er et vindu. Jobben din er å kalibrere hva kunder kan se. Det betyr at du kanskje deaktiverer «Maler»-innstillingene, begrenser blokksetteren til en kuratert liste, og til og med forhåndsutfyller tomme mønstre med plassholderarbeid. Editoren blir et innholdsregistreringsskjema i stedet for et webdesign-lerret.

På tilgjengelighetssiden er blokkredigererens fokusbehandling og tastaturstøtte generelt bedre enn klassiske redaktørers malfelt. Men du må fortsatt sørge for at mønstre har riktig overskriftshierarki og tilgjengelige navn. Siden mønsteret er delt på tvers av kunder, fikser du bare disse problemene én gang, som er en annen skjult gevinst ved standardisering.

Den virkelig vanskelige delen er intern. For teamet ditt krever det å lære å prototype med blokker at du avlærer «gjør det i PHP»-vanen. Det er en reell kostnad, men det er en engangskostnad per person. Det er ikke en grunn til å unngå tilnærmingen; det er en grunn til å starte med ett mønsterbibliotek og en tilgivende kunde før du ruller ut overalt. Ikke la «mine kunder kan ikke håndtere blokker»-refrenget skjule det faktum at du ennå ikke har konfigurert et blokkoppsett for å møte dem på halvveien.

Innvendingen «vi har allerede hooks og filtre»

Prinsippet her er: du kaster ikke ut hooks; du legger til et lag oppå. Blokker er presentasjonsgrensen; hooks er fortsatt hvordan du injiserer logikk. En dynamisk blokks render-callback kjører i PHP, noe som betyr at du kan kalle de samme funksjonene og bruke de samme filtrene du allerede stoler på.

Tenk deg en plugin som lar deg legge til et «utvalgt produkt»-felt på ethvert innlegg ved hjelp av et filter. Med en dynamisk blokk kan du inkludere en server-gjengitt blokk som kjører det filteret og skriver ut utdataene inne i blokkens wrapper. Kunden setter inn blokken; den eksisterende PHP-logikken gjør det tunge løftet. Ingenting kastes. For et enda mer konkret eksempel, se for deg en egendefinert blokk som lister opp nylige prosjektinnlegg. I render-callbacken kaller du get_posts(), deretter løkker og bruker the_title() og the_permalink() – de samme mal-taggene du har brukt i årevis.

Dette er også stedet for å være ærlig om hva som ikke oversettes. Noen lure gamle temaer bruker template-parts med intrikate betingelser som tar argumenter basert på sidekonteksten. Å gjenskape det som en blokk kan være rotete. Men du trenger ikke å gjenskape det på en gang. Den inkrementelle veien er å beholde PHP-logikken, pakke den inn i en dynamisk blokk, og flytte markupen inn i blokkmalen. Du vil ofte oppdage at dine eksisterende filtermønstre kan håndtere de nye utdataene. Og hvis logikken er tett knyttet til et malhierarki (f.eks. «på søkeresultater, vis dette annerledes»), kan du fortsatt bruke den klassiske malen for de spesifikke visningene mens du bruker blokker for vanlige sider.

REST API-en åpner også en annen dør: du kan bygge blokker som henter data fra andre WordPress-nettsteder eller tredjepartstjenester. En dynamisk blokk kan kalle wp_remote_get() for å hente JSON og gjengi det på frontend. Det er et kraftig mønster for byråutbygginger der kunder vil vise sosiale strømmer, produktlister eller interne data uten å administrere en separat integrasjon. Avveiningen er caching og feilhåndtering – hvis den eksterne API-en er treg, er siden din treg. Hold API-baserte blokker unna kritisk over-fold-innhold, eller bruk klientsidegjengivelse med en skikkelig lasteindikator.

Handlinger (actions) og filtre kjører fortsatt rundt lagring og gjengivelse; hook-arkitekturen forsvinner ikke når du tar i bruk blokker, den flytter bare til en ny kontekst. Hvis du trenger å friske opp forståelsen av hvor actions og filtre møter denne nye blokkverdenen, er hook-dypdykket vårt en nyttig oppfriskning.

Innvendingen «FSE er ikke produksjonsklart»

Det er greit, men spør hva «risikabelt» faktisk betyr. Full Site Editing har vært gjennom flere utgivelser, og theme.json har funnet seg til rette i et stabilt skjema. Risikoen er ikke at editoren «plutselig går i stykker» – risikoen er at teamets egendefinerte kode kan stole på gamle PHP-maler som eksisterer vanskelig sammen med blokkmaler. Dessuten antar noen tredjepartsplugins fortsatt den klassiske editoren eller customizeren. Det er en kompatibilitetsbeslutning, ikke en grunn til å kaste hele modellen.

En nyttig måte å tenke på det: enkle, repeterbare nettsteder med innhold skrevet i blokker er minst risikable. Høyrisikokunder er de med dypt tilpassede klassiske temaer eller proprietære plugins som gjengir sin egen frontend. Det er en legitim grunn til å holde seg til klassiske temaer for den lille nisjen. Feilen er å late som om «produksjonsklart» er en enkelt bryter som enten er på eller av.

Før du foreslår et blokktema til en kunde, gå gjennom en rask sjekkliste:

• Har kunden et sterkt tilpasset tema som vil kreve migrering?
• Støtter de nødvendige pluginene Site Editor og REST API?
• Tillater hostingmiljøet filtilgangen som blokktemaet forventer?
• Har du satt av tid til mønsterdesign, ikke bare blokkregistrering?
• Vil kundens team tolerere editor-endringene, eller trenger de en låst mal?

Hvis svaret på noe er nei, juster omfanget eller bruk en hybrid tilnærming. Det er ikke et kompromiss; det er ingeniørmessig vurdering. Og hvis du bygger en hybrid, husk historien om hooks og filtre ovenfor – du kan fortsatt pakke gammel logikk inn i dynamiske blokker mens theme.json håndterer det globale utseendet.

Versjonering av theme.json er ikke bare en teoretisk bekymring. Jeg har sett et byrås egendefinerte blokkbibliotek gå i stykker når kunden oppdaterte WordPress og blokkens style-fil registrert med wp_register_style() under et endret håndtak. Fiksen var enkel, men panikken var reell. En enkel testprosess – kjør oppdateringen på en staging-kopi av nettstedet, klikk gjennom nøkkelsidene, og slipp deretter – løser de fleste av disse overraskelsene.

Innvendingen du ikke har rettet mot deg selv

Her er meta-innvendingen som holder byråer fra å standardisere: «Det er en stor endring, og det er ingen tid til å gjøre det under kundearbeid.» Det er sant – så ikke gjør det under kundearbeid. Velg et internt prosjekt eller en liten kunde og bygg ett mønsterbibliotek. Bruk theme.json som designtokensystem. Legg til en egendefinert blokk bare når den er berettiget. Pakk de gamle hookene der de hjelper. Iterer.

Her er en grov første 30 dager:

1. Gjennomgå de siste fem kundebyggene dine og list de ti mest gjentatte oppsettsdelene.
2. Gjør disse ti delene til blokkmønstre, med et lite sett CSS-klasser.
3. Bygg en delt plugin (eller mu-plugin) som registrerer disse mønstrene. Hvis du ikke har tenkt på plugin-organisering for dette, skumles denne guiden om å bygge robuste WordPress-plugins først.
4. Lag én theme.json som matcher grunndesignet ditt; legg til kundespesifikke verdier når du starter opp prosjekter.
5. Velg ett lite internt prosjekt eller en vennlig kunde og migrer det til stabelen.
6. Dokumenter én heltehistorie om en kunde som redigerte forsiden sin uten å ringe deg.

På slutten av det eksperimentet vil du ikke ha et «blokk-først»-merke å henge på veggen. Du vil ha et team som kan spinne opp et nytt kundenettsted fra en felles grunnlinje uten å beklage tidslinjen. Du vil også være i en bedre posisjon til å si nei til kundens forespørsel om den 42. egendefinerte blokken – fordi du vet nøyaktig hva kjernblokkene kan, eller fordi du kan vise hvorfor en dynamisk blokk faktisk ville vært raskere.

Vil du fortsatt bygge noen skreddersydde nettsteder? Ja. Noen kunder vil alltid trenge en egendefinert mal, en skreddersydd side, eller en proprietær integrasjon som ikke er verdt å tvinge inn i den delte modellen. Målet er ikke å eliminere skreddersydd arbeid – det er å gjøre det til unntaket snarere enn standarden.

Repeterbarheten kommer fra de kjedelige delene: et solid theme.json-skjema, et tydelig mønsterbibliotek, og disiplinen til å holde det delte laget slankt. Det er ikke den blanke versjonen du hører om i webinarer. Det er den som slår mandagsmorgen-blankt-tema-bluesen.