Jag behövde en ny artikelsida till Din Plattform.
Inte en lista med inlägg i kronologisk ordning. En riktig sida – med en hero-sektion för de viktigaste artiklarna, ett rutnät för resten, kanske en kompakt lista längst ner. Och ett formulär någonstans i mitten för att fånga upp nyhetsbrevsprenumeranter.
Problemet var att jag visste exakt hur det brukar sluta. Samma artikel dyker upp i tre sektioner. Eller så får man lägga timmar på att manuellt plocka bort dubbletter varje gång man publicerar något nytt.
Jag ville ha block som pratade med varandra. Som visste vad de andra redan visat.
Det här är historien om hur jag byggde det – på en arbetsdag.
Förberedelsen som gjorde skillnad
Jag har lärt mig att kodprojekt sällan misslyckas på grund av koden. De misslyckas för att man inte vet vad man bygger.
Så innan vi skrev någon riktig kod förklarade jag för Claude Code vad jag ville uppnå – och att jag först ville ha en avskalad HTML-mockup. Ingen PHP, ingen WordPress, bara ren markup som visade strukturen.
Efter ett par revisioner hade vi en HTML-fil som fungerade som karta. Hur skulle hero-sektionen se ut? Vilka element behövde den? Hur skulle gridet bete sig? Var skulle formuläret sitta? Allt fanns där, och vi var överens om riktningen innan vi började bygga på riktigt.
Sedan hittade jag något som visade sig vara avgörande: Blockstudio har en fil som heter blockstudio-llm.txt. Det är en textfil som beskriver exakt hur block ska struktureras – vilka attribut som finns, hur block.json ska se ut, hur PHP-renderingen fungerar.
Filen är gjord för att delas med AI-verktyg. Tanken är att du ger den till en LLM tillsammans med din uppgift, och AI:n genererar kod som faktiskt följer rätt mönster.
Det låter som en liten sak. Men det är skillnaden mellan att få ut kod som fungerar direkt och att spendera timmar på att rätta strukturfel.
Dagen: Från mockup till färdiga block
Jag använde Claude Code som arbetspartner.
Morgonen började med Blog Featured – hero-blocket. Jag gav Claude min HTML-mockup, Blockstudios LLM-fil, och en beskrivning av vad blocket skulle göra. Handplockade artiklar om man ville. Automatiskt fyllda om man inte valde något. Tre artiklar totalt, en stor och två små.
Första versionen fungerade. Nästan. Bilderna skalade inte rätt. Kategori-etiketten hamnade på fel ställe. Små saker som tog tio minuter att fixa.
Sedan kom den första riktiga utmaningen.
WordPress renderar block två gånger genom sitt content-filter. Det är en quirk som de flesta aldrig märker. Men när du bygger block som håller reda på tillstånd – som ”vilka artiklar har redan visats” – blir det ett problem.
Första renderingen: Featured visar artikel 1, 2, 3. Markerar dem som visade. Andra renderingen: Grid ska exkludera 1, 2, 3, men listan är redan ”förbrukad”.
Lösningen var render-caching. Varje block cachar sitt resultat första gången det renderas. Andra gången returnerar det bara cachen. Inte rocket science, men det tog ett par timmar att förstå problemet och implementera lösningen.
Lunch.
Eftermiddagen var smidigare. Blog Grid fungerade på första försöket – exkluderingslogiken var redan på plats. Blog Horizontal List var en variant av samma tema. Blog CTA Minikurs var mest styling.
Mellan varje block: review. Vad händer om det inte finns tillräckligt många artiklar? Vad händer om någon handplockar en artikel som raderats? Vad händer om man blandar kategorifilter med handplockade artiklar?
Edge cases. Det är där buggar bor.
Vid fyra-tiden hade jag fyra fungerande block och en hjälpfunktionsfil som höll ihop alltihop.
Vad jag lärde mig
LLM-filen var avgörande. Utan den hade vi fastnat i strukturfrågor. Hur ska attribut definieras? Var ska renderingslogiken ligga? Med filen på plats genererade Claude kod som passade in direkt. Jag slapp översätta mellan ”hur Claude tror att Blockstudio fungerar” och ”hur det faktiskt fungerar”.
Mockup-first sparar tid. Det känns som en omväg att börja med en HTML-mockup. Men det tvingar dig att tänka igenom strukturen innan du skriver kod. Och det ger AI:n något konkret att utgå från – inte bara en vag beskrivning. Att låta Claude Code generera mockupen först gör att ni är överens om vad som ska byggas innan ni börjar.
Review mellan varje steg fångar problem tidigt. Jag hade kunnat bygga alla fyra blocken och sedan testa. Men då hade dubbelrenderingsproblemet dykt upp i slutet, när allt var ihopkopplat och svårare att debugga.
Dokumentation efteråt är värt besväret. Jag skrev en komplett dokumentation av hela systemet samma kväll. Hur varje block fungerar. Vilka hjälpfunktioner som finns. Vanliga problem och lösningar. Det tog en timme. Men nästa gång jag tittar på den här koden – om tre månader, om ett år – kommer jag tacka mig själv.
Vad jag skulle göra annorlunda
Om jag byggde det här igen skulle jag börja med hjälpfunktionerna. Exkluderingslogiken, post-trackingen, render-cachingen. Få det på plats först, sedan bygga blocken ovanpå.
Jag skulle också testa dubbelrenderingen tidigare. Det var den enda riktiga bromsen under dagen – och den hade jag kunnat upptäcka med ett enkelt test innan jag ens började på det andra blocket.
Men det är lätt att säga i efterhand.
Det här är början på något större
Fyra block är inte revolutionerande. Det är en lösning på ett specifikt problem.
Men processen – mockup först, LLM-fil som kontext, block för block med review emellan – den är återanvändbar. Nästa gång jag behöver bygga något i WordPress vet jag hur jag tar mig från idé till implementation på en dag istället för en vecka.
Blocken finns nu live på Din Plattform. Du kan se resultatet på artikelsidan.
Jag återkommer med hur det fungerar i praktiken efter att jag använt dem ett tag. Det är en sak att bygga något. En annan att leva med det.