Stop med at genopbygge hver WordPress-side

Resumé

De fleste bureauer opbygger hver WordPress-side fra et tomt tema, selv når en fælles base ville skære uger ud af tidsplanen. Denne artikel argumenterer for, at theme.json, block patterns og dynamiske blocks giver dig mulighed for at standardisere strukturlaget, samtidig med at hver kundes karakteristiske design bevares. Den tager direkte fat på de fem indvendinger, der forhindrer teams i at ændre: 'vi har forskellige kunder', 'custom blocks er dyre', 'editoren er forvirrende', 'vi mister vores hooks og filters' og 'FSE er ikke produktionsklar'. Hver indvending får et praktisk modargument og et konkret mønster, du kan adoptere gradvist. Gevinsten er en gentagelig opbygningsproces, der stadig respekterer skræddersyet arbejde, hvor det hører hjemme. Advarsel: Der loves ingen one-click reset-knapper.

Hvor mange af dine kunders sider deler bare én linje kode? Ikke copyright-linjen – faktisk kode. Hvis svaret er 'næsten ingen', har du allerede mærket smerten: den samme hero-sektion genopbygget for niende gang, det samme team-grid-markup kopieret fra et projekt til det næste, de samme preprocess-justeringer henvist til på tværs af et halvt dusin temaer. Du har også hørt forsvaret: 'Hver kunde har forskellige behov.' Sandt. Den konklusion, alle dog drager – at hver side har brug for et skræddersyet fundament – er falsk. WordPress-økosystemet giver dig nu en måde at standardisere de strukturelle dele uden at standardisere designet: theme.json til designtokens, block patterns til gentagne layouts og dynamiske blocks til de få funktioner, der har brug for rigtig server-side-logik. Denne artikel handler om de indvendinger, der forhindrer bureauer i at tage det skridt, og hvad der faktisk virker, når du skubber tilbage.

Indvendingen "men hver kunde er forskellig"

Det underliggende princip: standardisér fundamentet, ikke overfladen. Grunden til at holde struktur i et fælles bibliotek er netop at frigøre det visuelle lag. En theme.json-fil er ikke et design – det er et sæt designtokens. Farver, afstand og typografi er værdier, ikke markup. Det er det afgørende skift: du kan dele markup, mens en theme.json pr. side får siden til at se helt anderledes ud for et andet brand.

Tag to kunder: et advokatfirma og en outdoor-forhandler. Deres designsprog er langt fra hinanden. Men begge har brug for en hero-sektion, et testimonial-grid og et call-to-action-bånd. I stedet for at genopbygge markup for hver enkelt kan du vedligeholde tre block patterns og lade hver kundes theme.json definere farver, skrifttyper og afstand. Strukturen forbliver identisk; designtokensene forvandler den fra ét brand til det andet. Når forhandleren skifter sin farvepalette til næste forår, redigerer du én fil på deres side – ikke markup i seks skabeloner.

Praktisk betyder det, at dit team opretter patterns som kode, registrerer dem i et fælles plugin og lader theme.json på hver kundeside håndtere malingen. Patternets klassenavne bliver din arkitektur; værdierne bliver variablerne. Du kan endda gå videre og udvide theme.json til at indeholde brugerdefinerede indstillinger for post types eller plugin-output, selvom du på et tidspunkt bygger en konfigurationsgrænseflade i stedet for en side – en fælde, der diskuteres i vores gennemgang af at udvide theme.json. Hold det fælles lag slankt: det skal kun indeholde det, der går igen på tværs af kunder. I det øjeblik du finder dig selv i at tilføje en indstilling 'for en sikkerheds skyld, hvis nogen en dag ønsker det', har du skabt en abstraktion, der vil koste mere at vedligeholde, end den sparer.

Når du opretter en ny kunde, bør de første tredive minutter være: klon det fælles patterns-plugin, opret en ny theme.json med kundens palette og skrifttypeskala, og registrer deres logo og footer. Det er ikke en skræddersyet opbygning; det er en konfigurationsopgave. Det resterende kundespecifikke arbejde går ind i indhold, struktur og eventuelle virkelig skræddersyede funktioner. Det er forskellen på at bygge hvert hus fra bunden og at have et sæt præfabrikerede plantegninger, som du kan male om og tapetsere om. Analogien er løs, men princippet holder: jo mere du skubber ind i theme.json-værdier, jo mindre skal du røre ved markup.

En af de enkleste sejre er faktisk at se på, hvordan block patterns fungerer. Et pattern er bare en samling af blocks med foruddefineret indhold og styling. Du kan gemme enhver block-konfiguration som et pattern, og så kan en kunde indsætte det uden at vide, hvordan det er bygget. Det betyder, at patternet bliver et 'indgangspunkt' for ikke-tekniske brugere. Når dit team vedligeholder det underliggende pattern i kode, får kunden et konsistent bibliotek uden at røre en eneste PHP-tag.

Nu, den advarsel jeg bliver ved med at vende tilbage til: overcentralisér ikke. En theme.json med en indstilling for enhver tænkelig nuance er en vedligeholdelsessump. Fælles patterns bør være meningsfulde, ikke almagtige. Hvis en kunde har brug for et radikalt anderledes layout – for eksempel en magasin-forside med et stort udvalgt grid – passer de måske ikke ind i dit standard pattern-bibliotek. Det er okay. Standardisering betyder, at du vinder på de 80 % af projekterne, der ligner hinanden, ikke at du tvinger hver side ind i den samme form.

Indvendingen "custom blocks sprænger budgettet"

Her er et modprincip, der lyder kedeligt, men sparer penge: de fleste ting, du tror behøver et custom block, gør ikke. Kerneblocks plus et pattern kan dække det overvældende flertal af layouts. Custom block er den sidste udvej, ikke den første hensigt.

Det klassiske eksempel er team-gridet. Hvis det er en engangsforestilling, så brug kerneblocks som 'columns' og 'group' og lad kunden lægge et avatar ind manuelt. Hvis tre kunder beder om det samme grid med samme struktur med 'sociale links under navnet', har du nu en kandidat til et block pattern. Når det pattern begynder at samle nye muligheder – hover-effekter, sortering, stjernebedømmelser – bliver patternet en uhåndterlig rodebunke, og så er det tid til at skrive et custom block. Den budgettunge fejl er at springe direkte til custom block ved første henvendelse.

Et mere snigende scenario: kunden beder om en 'case study-karrusel.' Den første instinkt er at tænke: 'Jeg har brug for en karrusel-block.' Men har de brug for en karrusel? Måske har de brug for en vandret rullebar gruppe af indlæg, som kerneblocks kan håndtere med en 'group'-block og lidt CSS. Eller måske har de brug for en dynamisk liste over seneste case studies, hvilket er en dynamisk block, der forespørger CPT'en. Spørgsmålet er ikke 'hvilken funktion vil kunden have?' men 'hvilke data afhænger den af?' Hvis dataene er statiske og redigerbare af kunden, duer et pattern. Hvis dataene kommer fra en databaseforespørgsel, er en dynamisk block berettiget. Hvis dataene skal opdateres i realtid fra en API, kigger du måske i stedet på en REST API-integration – det krydser over i en anden slags opbygning.

Når du faktisk bygger en block, er block.json din ven. Det er den eneste kilde til sandhed for attributter, scripts og styles, hvilket gør blocken bærbar på tværs af projekter. Den lader dig også deklarere afhængigheder og oversættelser rent, hvilket er afgørende, når du distribuerer et bibliotek på tværs af mange kundesider. For indhold, der afhænger af live-data, renderer en dynamisk block på serveren, så du ikke behøver at sende en JavaScript-bundle ved hver sidevisning. Og hvis din block udvikler sig, kan du håndtere deprecations elegant, så eksisterende indhold ikke går i stykker – vores guide til block-deprecation gennemgår det præcise mønster.

Før du bygger noget, så kør beslutningen gennem dette grid:

Tilgang	Bedst til	Undgå når
Core block	Engangsindhold, enkle sider	Layoutet gentages på tværs af mange kunder og har brug for rige muligheder
Block pattern	Gentagelige layouts uden logik	Layoutet har brug for betingelser, dynamiske data eller komplekse interaktioner
Custom block	Gentaget, datadrevet eller meget specifik adfærd	Den eneste grund er en engangssektion, der kan klares med en klasse

Du bør også tænke på block-navngivning fra dag ét. Et block-navn er i bund og grund en kontrakt med dit indhold. Hvis du kalder det wagent/team-grid og senere omdøber det til wagent/team-carousel, vil du ødelægge eksisterende indhold, medmindre du sørger for en deprecation-sti. Vælg generiske, formålsbaserede navne, der ikke bliver falsk reklame, når blocken udvikler sig. Dette er en variant af den navngivningsdisciplin, vi alle har lært fra plugin-præfikser, og det gælder i lige så høj grad for block-navne.

Den kontrære pointe her er det mest nyttige, jeg kan sige: det custom block, du bygger, fordi en kunde bad om 'bare ét stykke', er næsten altid en fejl. Sig nej høfligt, lever et core block med en klasse, og bank timerne. Du vil få mere respekt fra kunden – og en mindre linje i vedligeholdelsesbudgettet.

Indvendingen "kunderne ødelægger editoren"

Denne indvending er halvt rigtig. Block-editoren selv er ikke problemet; problemet er at give kunderne for meget tov. theme.json kan låse ned, hvad der kan redigeres: deaktivér skabeloneditoren, begræns tilladte blocks, og sæt standardstyles, så en forkert placeret kolonne gør mindre skade. Nogle kunder vil stadig formå at ødelægge ting, men du kan nulstille en side til et gemt pattern med ét klik – noget den klassiske editor ikke kunne tilbyde.

Lad mig skitsere et scenario. En kunde ringer og siger: 'Jeg flyttede en sektion, og nu ser hele siden forkert ud.' Med et klassisk tema ville du logge ind, inspicere CSS'en og sandsynligvis bruge en time på at fikse layoutet. Med en block-opsætning kan du åbne siden, vælge indholdsområdet og nulstille det til det gemte pattern. Patternet er baseline; kundens ændringer er overlayet. Når overlayet går galt, fjerner du det. Det er ikke bare en bedre arbejdsgang; det er en fundamentalt mere tilgivende editor.

Nu nuancen: de fleste kunder ønsker slet ikke at redigere ret meget. De vil ændre tekst, skifte billeder og måske omarrangere en sektion. Block-patternet giver dig præcis det uden at eksponere hele sidestrukturen. I den forstand er editoren ikke et legetøj; det er en søger. Din opgave er at kalibrere, hvad kunderne kan se. Det betyder, at du måske deaktiverer 'Skabeloner'-indstillingerne, begrænser block-indsætteren til en kurateret liste og endda forudfylder tomme patterns med placeholder-arbejde. Editoren bliver en indtastningsformular til indhold snarere end et webdesign-lærred.

På tilgængelighedssiden er block-editorens fokusstyring og tastaturunderstøttelse generelt bedre end en klassisk editors skabelonfelter. Men du skal stadig sikre, at patterns har korrekt overskriftshierarki og tilgængelige navne. Da patternet er delt på tværs af kunder, løser du kun disse problemer én gang, hvilket er endnu en skjult gevinst ved standardisering.

Den virkelig svære del er intern. For dit team kræver det at lære at prototype med blocks at aflære 'gør det i PHP'-vanen. Det er en reel omkostning, men det er en engangsomkostning per person. Det er ikke en grund til at undgå tilgangen; det er en grund til at starte med ét pattern-bibliotek og én tilgivende kunde, før du ruller ud alle steder. Lad ikke refrænet 'mine kunder kan ikke håndtere blocks' skjule det faktum, at du endnu ikke har konfigureret en block-opsætning, der møder dem på halvvejen.

Indvendingen "vi har allerede hooks og filters"

Princippet her er: du kasserer ikke hooks; du tilføjer et lag ovenpå. Blocks er præsentationsgrænsen; hooks er stadig sådan, du injicerer logik. En dynamisk blocks render callback kører i PHP, hvilket betyder, at du kan kalde de samme funktioner og anvende de samme filters, som du allerede stoler på.

Forestil dig et plugin, der lader dig tilføje et 'featured product'-felt til ethvert indlæg ved hjælp af en filter. Med en dynamisk block kan du inkludere en server-rendered block, der kører den filter og udskriver outputtet inde i blockens wrapper. Kunden indsætter blocken; den eksisterende PHP-logik gør det tunge arbejde. Intet bliver smidt væk. For et endnu mere konkret eksempel kan du overveje en custom block, der viser en liste over seneste projektindlæg. I dens render callback kalder du get_posts(), looper derefter og anvender the_title() og the_permalink() – de samme template-tags, du har brugt i årevis.

Dette er også stedet at være ærlig om, hvad der ikke oversætter godt. Nogle smarte gamle temaer bruger template-parts med indviklede betingelser, der tager argumenter baseret på sidekonteksten. At genskabe det som en block kan være rodet. Men du behøver ikke genskabe det hele på én gang. Den inkrementelle vej er at beholde PHP-logikken, pakke den ind i en dynamisk block og flytte markup ind i block-skabelonen. Du vil ofte opdage, at dine eksisterende filter-mønstre kan håndtere det nye output. Og hvis logikken er tæt koblet til et skabelonhierarki (f.eks. 'på søgeresultater, vis dette anderledes'), kan du stadig bruge den klassiske skabelon til de specifikke visninger, mens du bruger blocks til almindelige sider.

REST API'et åbner også en anden dør: du kan bygge blocks, der trækker data fra andre WordPress-sider eller tredjepartstjenester. En dynamisk block kan kalde wp_remote_get() for at hente JSON og rendere det på frontenden. Det er et stærkt mønster til bureau-opbygninger, hvor kunder vil vise sociale feeds, produktlister eller interne data uden at administrere en separat integration. Afvejningen er caching og fejlhåndtering – hvis den eksterne API er langsom, er din side langsom. Hold API-baserede blocks ude af kritisk above-the-fold-indhold, eller brug client-side rendering med en ordentlig loading-state.

Actions og filters kører stadig omkring lagring og rendering; hook-arkitekturen forsvinder ikke, når du tager blocks i brug, den flytter blot til en ny kontekst. Hvis du har brug for at genopfriske din forståelse af, hvor actions og filters møder denne nye block-verden, er vores hooks-dyk en nyttig genopfriskning.

Indvendingen "FSE er ikke produktionsklar"

Fair nok, men spørg, hvad 'risikabelt' faktisk betyder. Full Site Editing har været igennem flere udgivelser, og theme.json har lagt sig fast i et stabilt skema. Risikoen er ikke, at editoren 'pludselig går i stykker' – risikoen er, at dit teams brugerdefinerede kode kan være afhængig af gammeldags PHP-skabeloner, der sameksisterer akavet med block-skabeloner. Desuden antager nogle tredjepartsplugins stadig den klassiske editor eller customizer. Det er en kompatibilitetsbeslutning, ikke en grund til at kassere hele modellen.

En nyttig måde at tænke på det: enkle, gentagelige sider med indhold skrevet i blocks er mindst risikable. Højrisikokunder er dem med dybt tilpassede klassiske temaer eller proprietære plugins, der renderer deres egen frontend. Det er en legitim grund til at blive ved med klassiske temaer i den lille niche. Fejlen er at lade som om, 'produktionsklar' er en enkelt kontakt, der enten er tændt eller slukket.

Før du foreslår et block-tema til en kunde, så kør hurtigt en tjekliste igennem:

• Har kunden et stærkt tilpasset tema, der ville kræve migrering?
• Understøtter de uundværlige plugins Site Editor og REST API?
• Tillader hostingmiljøet den filadgang, som block-temaet forventer?
• Har du afsat tid til pattern-design, ikke kun block-registrering?
• Vil kundens team tolerere editorændringerne, eller har de brug for en låst skabelon?

Hvis svaret er nej på noget, så juster omfanget eller brug en hybrid tilgang. Det er ikke et kompromis; det er ingeniørfaglig vurdering. Og hvis du bygger en hybrid, så husk historien om hooks og filters ovenfor – du kan stadig pakke gammel logik ind i dynamiske blocks, mens theme.json håndterer det globale udseende.

Versionering af din theme.json er ikke kun en teoretisk bekymring. Jeg har set et bureaus custom block-bibliotek gå i stykker, da kunden opdaterede WordPress, og blockens style-fil registreret med wp_register_style() under et ændret handle. Løsningen var let, men panikken var ægte. En simpel testproces – kør opdateringen på en staging-kopi af siden, klik igennem de vigtigste sider, og udgiv derefter – løser de fleste af disse overraskelser.

Indvendingen, du ikke har rejst over for dig selv

Her er meta-indvendingen, der forhindrer bureauer i at standardisere: 'Det er en stor ændring, og der er ingen tid til at gøre det under kundearbejde.' Det er sandt – så gør det ikke under kundearbejde. Vælg et internt projekt eller en lille kunde og byg ét pattern-bibliotek. Brug theme.json som designtoken-system. Tilføj et custom block kun, når det er berettiget. Pak de gamle hooks ind, hvor de hjælper. Iterér.

Her er en grov skitse til de første 30 dage:

1. Gennemgå dine sidste fem kundeopbygninger og lav en liste over de ti mest gentagne layout-dele.
2. Gør de ti dele til block patterns med et lille sæt CSS-klasser.
3. Byg et fælles plugin (eller mu-plugin), der registrerer disse patterns. Hvis du ikke har tænkt over plugin-organisering til dette, så skim denne guide til at bygge robuste plugins først.
4. Opret én theme.json, der matcher dit baseline-design; tilføj kundespecifikke værdier, når du opretter projekter.
5. Vælg et lille internt projekt eller en venlig kunde, og migrér det til stakken.
6. Dokumentér én heltehistorie om en kunde, der redigerede deres forside uden at ringe til dig.

Ved slutningen af det eksperiment har du ikke et 'block-first'-badge at hænge på væggen. Du vil have et team, der kan spinne en ny kundeside op fra en fælles baseline uden at undskylde for tidsplanen. Du vil også være bedre stillet til at sige nej til kundens anmodning om det 42. custom block – fordi du ved præcis, hvad kerneblocks kan gøre, eller fordi du kan vise, hvorfor en dynamisk block faktisk ville være hurtigere.

Vil du stadig bygge nogle skræddersyede sider? Ja. Nogle kunder vil altid have brug for en brugerdefineret skabelon, en skræddersyet side eller en proprietær integration, der ikke er værd at tvinge ind i den fælles model. Målet er ikke at eliminere skræddersyet arbejde – det er at gøre det til undtagelsen snarere end standarden.

Gentageligheden kommer fra de kedelige dele: et solidt theme.json-skema, et klart pattern-bibliotek og disciplinen til at holde det fælles lag slankt. Det er ikke den skinnende version, du hører i webinarer. Det er den, der slår mandag-morgen-bluesen med det tomme tema.