Hantering av kod
Säkerhet och uppdateringar
sakerhetWordPress har haft en del utmaningar med säkerhetshål som har kunnat utnyttjas, de brukar dock snabbt åtgärdas. Det ställer dock krav på att någon har koll på när det är dags att uppdatera för att täppa till säkerhetshål. Som ett led i säkerhetsarbetet vill vi implementera automatiska uppdateringar av patchar som WordPress släpper med jämna mellanrum. Utöver det kontrollerar vi kontinuerligt trafiken i vår brandvägg och blockerar misstänkta anrop där.
Versionshantering av kod
För att kunna följa förändringar i koden samt kunna gå tillbaka till gamla versioner så måste all källkod och media som rör layouten på webbplatsen (alltså inte innehållet i tex artiklar) läggas in i ett versionshanteringssystem. Det som skall användas är GIT, som är ett välkänt system för versionshantering. Mer specifikt så används tjänsten Azure DevOps, både för kod som skall vara publik och sådan som inte skall vara det.
Versionshantering av ramverk
Vår målsättning är att alltid befinna oss inom minst 2 versioner från den senast släppta major versionen av varje ramverk/system vi använder. Är t.ex. PHP 9 den senaste versionen så ska vi nyttja PHP 7 som sämst.
SSO
Vi har som målsättning att hantera så lite känslig data som möjligt i WordPress. Som ett led i detta är målsättningen att hantera all inloggning via SSO där autentiseringen inte sker i WordPress utan istället nyttjar Region Hallands centrala lösningar för detta.
Deployment
Vi nyttjar release pipelines och artefakter i Azure DevOps för att deploya och testa all vår kod.
Nomenklatur
- All PHP kod som skrivs ska skrivas så att det följer de regler som är definierade i PSR-2. För att enklare kunna upprätthålla dessa regler används PHP_CodeSniffer.
- All JS som skrivs valideras och type-checkas med Typescript och ESLint.
Alla namn på klasser, funktioner, variabler, etc. måste vara beskrivande. Man skall genom att läsa namnet på funktionen förstå vad funktionen gör. Går det inte att beskriva allt funktionen gör i namnet så bör man fundera på om det går att bryta ner funktionen i flera funktioner. En tydlig namngivning är betydligt viktigare än kommentarer i koden.
WordPress
Backend
För alla våra webbar använder vi PHP och WordPress för hantering av data och admingränssnitt. Målsättningen är att alltid använda senaste versionen av WordPress
Egenutvecklade plugins
egenutvecklade-plugins-10'>För att skapa ett eget plugin används
npx create-rh-plugin
.
Externa plugins
När det blir aktuellt att använda ett nytt plugin för att utöka funktionaliteten i WordPress utan att skriva all kod själv måste vissa saker beaktas.
- Välj ett plugin som gör så lite extra utöver det som behövs i projektet, detta för att minimera felkällor och attackytor.
- Försök avgöra hur ”moget” pluginet är, sker det regelbunden utveckling på det etc.
- Är det många som använder pluginet?
- Och framförallt, granska koden
Frontend
I dagsläget stödjer vi två olika lösningar för våra webbplatser där vi på sikt vill gå mot Next.js. Anledningen är att vi då tydligare kan separera presentationen av data och hanteringen av den. Genom att endast nyttja WordPress API:er kan bygga mer dynamiska frontends. Tack vare Next.js och dess förmåga att rendera webbplatsen hos både servern & klienten får vi även extremt snabba webbplatser.
Sage/Bedrock
sagebedrock-13'>Bedrock och Sage är två ramverk som är en del av Roots-stacken. Roots är relativt etablerad som alternativ för att bygga strukturerade WordPress sajter men har tyvärr tappat utvecklingsfart på senare år då skiftet mot headless tagit fart inom WP-världen.
Next.js
next.js-14'>Tack vare next.js kan vi ta fram React baserade webbplatser som, vid behov, kan generera statiska sidor på servern. Detta leder till extremt snabba webbplatser och även förhållandevis säkra då mängden requests jämfört med en traditionell webbplats minskar radikalt. Tack vare att Next.js bygger på React så får vi även samma kodbas som för vårt komponentbibliotek och vår apputveckling. En annan fördel är att separationen av presentation och data även blir tydlig och bra då vi endast, precis som för appen, nyttjar API:er för att kommunicera med WordPress.
Appar
Vi nyttjar idag det reactbaserade ramverket Expo för att bygga vår app. Expo är ett ramverk som kompilerar native kod för både android och iOS men man nyttjar React när man bygger appen. Detta gör att vi oavsett kanal nyttjar samma kodsetup och kan återanvända metoder och funktioner. Även för appen använder vi WP för att hantera data.
Komponentbiblioteket
komponentbiblioteket-16'>Alla GUI komponenter vi tar fram byggs först i verktyget Storybook som separata React komponenter. Det är även här vi genomför enhetstester såväl som automatiska tester av tillgänglighet m.m.
Testning
Testning av JS baserad kod sker med JEST. Testning av PHP baserad kod sker med PHPUnit. Testningen sker automatiskt via pipelines i Azure DevOps.