Headless WordPress – inte värt jobbet
Headless WordPress som koncept kan vara en lockande tanke. All frontend är helt separerad från backend och WordPress är begränsat till att göra vad det gör allra bäst, nämligen att vara ett CMS. Man slipper bygga ett tema med mallar som följer WordPress regler och vilja. Men som alltid saknar man kon först när båset är tomt.
I och med releasen av WordPress REST API för ett antal år sedan blev det väldigt enkelt att hämta content utan en enda ”while have_posts().” Ett anrop mot rätt endpoint och man kan loopa ut artiklar utan att behöva bry sig om skillnaden mellan the_title() och get_the_title().
Det är guld och gröna skogar att jobba med ett fräscht, scaffoldat och batteries included Reactprojekt med lyx som live reload. Gamla tråkiga WordPress ligger plikttroget där i bakgrunden, på något annat ställe, och levererar content när helst du ber om det.
Det är en bedräglig känsla av vällust.
Det första bakslaget brukar dock inte låta vänta på sig. Kanske är det menyn som tidigare varit så enkel att loopa ut i mallen, komplett med klassnamn som current eller parent.
Kanske är det breadcrumbs som sätter käppar i hjulet. Eller varför inte paginering?
För att inte tala om kallduschen du får av att inse hur enormt svårt det blivit att förhandsvisa ett inlägg eller en sida i WordPress nu!
Bildlänkar och paginering
För att krydda tillvaron – och inte bygga ännu en standardblogg med WordPress – när det var dags att återuppliva den här sajten så gjorde jag ett tappert försök med konceptet ”headless WordPress.” Frontend utgjordes av ett Reactprojekt som hämtade data från en WordPressinstallation belägen i en intilliggande mapp vid namn /api.
Det var lekande lätt att läsa in artiklar från WordPress genom API:t, i alla fall efter att ha trixat och fixat med att ändra permalänkar. Det ska ju vara en URL till själva installationen och en annan för innehållet. Detta blir du varse när alla dina bildlänkar plötsligt är brutna.
När du läst in och loopat ut artiklarna från API:t vill du kanske ha en paginering. Detta är enkelt med funktionen paginate_links() som WordPress tillhandahåller – åtminstone så länge du bygger ett traditionellt tema.
Dessbättre finns länkar för nästa och föregående sida inkluderat i API:t, så paginering är inte alltför omständigt att åstadkomma. Åtminstone så länge det räcker med ”Nästa sida” och ”Föregående sida” som lösning. Att bygga en funktion som ger en paginering i nedan stil kräver betydligt mer jobb:
« 1, 2, 3…6 »
Jag försökte. Jag gav upp
Envetet fortsatte jag dock att jobba mig igenom varje hinder som slängdes i min väg, men till slut fick jag nog. Kanske något oväntat var det SEO som fick mig att bita i gräset när det gällde projektet headless WordPress. Det är väldigt behändigt att installera plugin som All in one SEO eller Yoast och låta dom generera title- och meta-taggar för sökmotorer och sociala medier. Dessvärre kan sådan lyx enbart åtnjutas när man bygger WordPressajten på det gamla tråkiga sättet.
Yoast adderar förvisso en del metadata i API:t som man kan använda, men vid det laget var mitt tålamod slut. Att separera WordPress från min frontend innebar otroligt mycket mer jobb än vad jag först kunde ana.
Det gav inte heller några egentliga fördelar.
Det innebar snarare en rad nackdelar som exempelvis client side rendering. Visst kan man nyttja en service worker och ”installera” sajten lokalt på enheten som besöker den, men en gammal stabil server side rendering med ett lager cache är svårslaget.
Att dela på frontend och backend i form av en JAMstack-lösning kan absolut vara en god idé, men WordPress är som bäst när man följer dess regler och vilja.