WordPress Utvikler i Stavanger

WordPress-utvikling for Stavanger-bedrifter handler sjelden om å sette opp et ferdig tema. Den handler om å koble en WordPress-installasjon mot Vipps, mot et norsk regnskapssystem, mot Bring sine fraktsoner og mot kravene Datatilsynet stiller, uten at noe av det knekker ved neste kjerneoppdatering. I Stavanger-regionen kommer det i tillegg ofte krav fra energikjeden, leverandørportaler og flerspråklige B2B-sider rettet mot partnere langs kysten. Det er den jobben denne siden beskriver.

Jeg leverer senior WordPress-utvikling for virksomheter i Stavanger-området: egne block-temaer, plugins, integrasjoner mot norske betalings- og logistikkleverandører og refaktorering av eldre temaer som har vokst seg uoversiktlige. Arbeidet følger WordPress Coding Standards, og hver branch går gjennom kodegjennomgang før den når produksjon.

#WordPress-utvikling i Stavanger

Stavanger er Norges energihovedstad og et tett knutepunkt for olje- og gassleverandører, maritime tjenester og teknologimiljøer knyttet til energitransisjon. Næringsparken på Forus binder sammen kontorer, leverandører og tjenesteselskaper mellom Stavanger og Sandnes. Universitetet i Stavanger (UiS) tilfører kompetanse innen energi, teknologi og samfunnsfag, og kandidater og forskningsmiljøer preger hvordan lokale virksomheter snakker om digitalisering. Kystnær B2B - fra offshore-støtte og inspeksjon til logistikk, reiseliv og profesjonelle tjenester - trenger nettsteder som tåler flerspråklig innhold, dokumentbiblioteker og sikre skjemaer, ikke bare en brosjyreside.

Den vanligste situasjonen er en bedrift som driver et WordPress-nettsted bygget for noen år siden, der temaet har fått påklistret funksjonalitet bit for bit. Hver ny plugin la til litt mer gjeld, og nå er PageSpeed-tallene røde, redaktørene tør ikke røre forsiden, og ingen vet hvilken kode som faktisk er i bruk. Den andre vanlige situasjonen i Stavanger er en leverandør eller tjenestebedrift i energikjeden som trenger et nettsted som speiler HSE-krav, sertifikater, prosjektreferanser og kontaktflater mot innkjøpere, uten at redaksjonen må vente på en utvikler for hver tekstendring.

#Hva oppdraget dekker

• Egne block-temaer bygget på editor-API-ene (theme.json, blokkmønstre, stilvarianter) slik at redaktører i Stavanger kan endre forsider, landinger for Forus-besøk og prosjektseksjoner uten å ringe en utvikler
• Egne plugins for forretningslogikk, egne posttyper og integrasjoner, holdt utenfor temaet så funksjonaliteten overlever et fremtidig temabytte
• Integrasjoner mot norske tjenester: Vipps (via den offisielle vipps-woocommerce-utvidelsen), Bring/Posten for frakt, og koblinger mot regnskaps- og ordresystemer over REST
• REST- og WPGraphQL-endepunkter for headless frontender eller mobilapper, med autentisering og fornuftig hastighetsbegrensning
• WP-CLI-skript for masseoperasjoner på innhold, databasemigrasjoner og miljøkonfigurasjon når et nettsted skal flyttes eller ryddes
• Tilgjengelighet etter WCAG 2.2 AA: semantisk markup, ARIA-landemerker, tastaturnavigasjon og fokusstyring, noe som også er et reelt krav for offentlig finansierte virksomheter og leverandører som selger inn til det offentlige i Norge

#Energikjeden og digital tilstedeværelse

Mange Stavanger-virksomheter lever av å levere utstyr, tjenester eller kompetanse inn i olje- og gassverdikjeden, eller i tilstøtende områder som havvind, karbonfangst og energiinfrastruktur. Det digitale ansiktet utad er ofte det første inntrykket en innkjøper, partner eller rekrutteringskandidat får. Et WordPress-nettsted i denne konteksten må typisk håndtere:

• Prosjekt- og tjenestesider med strukturerte felter for sektor, geografi og kompetanseområde, slik at innholdet kan filtreres og gjenbrukes
• Nedlastbare dokumenter (brosjyrer, HSE-oversikter, produktark) bak fornuftig tilgangsstyring der det trengs, uten å blande filer inn i temakoden
• Flerspråklig oppsett når målgruppen inkluderer både norsk og engelsk B2B-kommunikasjon
• Skjemaer som fanger kvalifiserte henvendelser uten å lekke personopplysninger til tredjepartsskript før samtykke

Jeg bygger dette som egne posttyper og felter, ikke som hardkodede maler i functions.php. Da kan redaksjonen på Forus eller i Stavanger sentrum oppdatere innhold når markedet skifter, uten at hvert skifte blir et utviklingsoppdrag.

#Forus, UiS og kystnær B2B

Forus er regionens tyngste næringspark og samlingspunkt for mange selskaper i energikjeden og tilknyttede tjenester. Et nettsted som skal støtte salg og rekruttering derfra, trenger ofte tydelige kontaktflater, kart og veibeskrivelse, og landingssider som speiler konkrete tjenestespor. Universitetet i Stavanger bidrar til et miljø der forskningsformidling, studentrettet informasjon og samarbeid med næringslivet møtes på samme plattform - WordPress egner seg godt når innholdet er redaksjonelt og må kunne endres ofte.

Kystnær B2B langs Rogalandskysten - maritime tjenester, logistikk, inspeksjon, turisme og profesjonelle rådgivningstjenester - har ofte sesongvariasjoner og behov for å vise kapasitet, sertifiseringer og referanseprosjekter. Her er blokkmønstre og gjenbrukbare seksjoner mer verdifulle enn en engangsdesign. Jeg prioriterer redaksjonell autonomi og ytelse på mobil, fordi mange lesere treffer siden fra felt, kai eller reise.

#Norske rammer som påvirker koden

Mye av det som skiller en Stavanger-leveranse fra en generisk WordPress-jobb ligger i regelverket, ikke i designet. Et par konkrete eksempler fra arbeidet:

• Personvern og Datatilsynet. GDPR gjelder fullt ut i Norge, og Datatilsynet håndhever det. I praksis betyr det samtykkebanner som faktisk blokkerer skript før samtykke, en databehandleravtale med hostingleverandøren, og at analyseverktøy ikke lekker personopplysninger ut av EØS uten grunnlag. Jeg setter dette opp i koden, ikke bare i en personvernerklæring ingen leser.
• Angrerett og forbrukerkjøpsloven. For nettbutikker rettet mot forbrukere må angrerettsinformasjonen (14 dagers angrefrist) vises tydelig i kjøpsløpet, ikke gjemmes i bunnteksten. WooCommerce gir kontrollen, men oppsettet må gjøres riktig.
• MVA og VOEC. Norsk merverdiavgift er 25 prosent, og terskelen for VOEC-registrering ligger på 50 000 kroner i årlig salg til norske forbrukere. En WooCommerce-butikk som selger over landegrenser må håndtere dette i avgiftsoppsettet, ikke i et regneark etterpå.

#Betaling og frakt for norske nettbutikker

Vipps er det dominerende betalingsmiddelet i Norge og brukes av en stor del av befolkningen. For en WooCommerce-butikk i Stavanger er Vipps sjelden valgfritt; kunder som ikke finner Vipps i kassen, hopper av. Jeg integrerer betaling via den offisielle vipps-woocommerce-utvidelsen og setter den opp slik at både hurtigkasse og ordinært kjøpsløp fungerer, med korrekt håndtering av callbacks og ordrestatus. Klarna dekker delbetaling der kunden ønsker det, og Stripe brukes for internasjonale kort.

På frakt er Bring og Posten standard for innenlands levering. Et fornuftig oppsett henter fraktpriser etter vekt og sone, viser hentested og leveringstid i kassen, og lar lageret skrive ut etiketter uten manuell tasting. Når dette ikke virker, blir det en kostnad per ordre som først synes når volumet stiger. For B2B-butikker som selger reservedeler eller utstyr til virksomheter i regionen, kan i tillegg fakturaflyt og rollebasert tilgang være viktigere enn forbrukerkassen - da løses det med egne plugins og tydelige akseptkriterier, ikke med enda en page builder-blokk.

#Slik jobber jeg gjennom et oppdrag

1. Kartlegging og kodegjennomgang. Jeg går gjennom dagens WordPress-installasjon: temastruktur, egne plugins, integrasjoner, hostingbegrensninger og et referansepunkt for ytelse og tilgjengelighet. Resultatet er et skriftlig risikokart, ikke en magefølelse.
2. Arkitektur og omfang. Vi avgjør hva som skal bygges nytt og hva som kan refaktoreres, hvor grensen mellom tema og plugin går, hvilke integrasjoner som trengs, og hvilke akseptkriterier som gjelder. Avveininger skrives ned.
3. Bygging i feature-branches. Koden følger WordPress Coding Standards, tekst er i18n-klar, markup er tilgjengelig, og hver branch går gjennom kodegjennomgang før den slås sammen.
4. QA og utrulling. Løsningen kjøres i et testmiljø som speiler produksjon. Du tester med ekte innhold og verifiserer Vipps, frakt og MVA før lansering der det er relevant. Utrulling skjer via en dokumentert release-prosess med en sti tilbake hvis noe må reverseres.
5. Overlevering. Du får levende dokumentasjon for både redaktører og utviklere, en runbook for de ikke-opplagte valgene, og en overleveringssesjon. Deretter kan prosjektet gå til ditt eget team eller til en fast vedlikeholdsavtale.

#Typiske utfordringer jeg løser for Stavanger-bedrifter

• Et tema full av teknisk gjeld. Mange nettsteder i regionen har samlet logikk i functions.php gjennom flere utviklere. Jeg flytter forretningslogikk ut i plugins, rydder mal-hierarkiet og fjerner kode ingen lenger bruker, slik at neste oppdatering ikke blir en kveld med feilsøking.
• En WooCommerce-butikk som ikke skalerer i toppene. Før store handelsperioder setter jeg opp full-page caching, rydder i trege databasespørringer, ekskluderer kasse og handlekurv fra cache der det trengs, og belastningstester før kampanjen, ikke etter.
• Sikkerhet på sider som håndterer persondata og B2B-henvendelser. Content Security Policy-headere, deaktivert XML-RPC der det ikke brukes, tofaktor på admin, en brannmur tilpasset WordPress-spesifikke angrepsmønstre, og parametriserte spørringer som lukker SQL-injeksjon.
• Innholdstyngde fra energisektoren. Store PDF-er, bildegallerier fra felt og mange landingssider gjør det lett å ødelegge LCP. Jeg skiller mediebibliotek, lazy-loading og caching fra redaksjonell struktur, slik at tung dokumentasjon ikke bremser forsiden.

#Hva du kan måle etterpå

Jeg foretrekker resultater som lar seg etterprøve framfor påstander. Det som faktisk kan måles på et Stavanger-prosjekt:

• Core Web Vitals i grønt for LCP, INP og CLS, verifisert på mobil mot reelle besøkstall, ikke bare i en Lighthouse-kjøring på en rask maskin
• Kortere publiseringstid for redaksjonen fordi forsider og landingssider bygges med blokkmønstre i stedet for utviklerbillett
• Et kjøpsløp der Vipps, frakt mot Bring og MVA henger sammen der butikk er aktuelt, slik at avbrutte kjøp i kassen går ned
• Færre manuelle oppgaver når prosjekt- og tjenestesider oppdateres via strukturerte felter i stedet for hardkodede maler

#Ytelse i praksis

Core Web Vitals påvirker både rangering i Google og hvor mange som faktisk fullfører et kjøp eller en henvendelse. På et WordPress-prosjekt jobber jeg mot disse målene konkret:

• LCP holdes nede med optimalisert kritisk renderingsvei, hero-bilder i WebP/AVIF, edge-caching og statisk levering der det er mulig
• INP holdes lav med minimal JavaScript-hydrering, færre og lettere tredjepartsskript, og tunge beregninger flyttet bort fra hovedtråden
• CLS holdes lav med eksplisitte bildedimensjoner, font-display: swap med matchende reservefont og reservert plass for innhold som lastes etterpå

Målingene følges over tid med Lighthouse i utrullingsløpet og data fra reelle besøkende, slik at en regresjon fanges opp før den rekker å påvirke salget eller leadflyten.

#Innholdsmodell for B2B i energiregionen

Et nettsted for en Stavanger-leverandør fungerer dårlig hvis alt ligger som fritekst i Gutenberg uten struktur. Jeg etablerer typisk:

• Egne posttyper for tjenester, prosjekter eller kompetanseområder, med felter som redaksjonen faktisk fyller ut
• Taksonomier som speiler hvordan markedet snakker (sektor, leveranseform, geografi), ikke interne organisasjonskart
• Blokkmønstre for hero, verdiforslag, dokumentliste og CTA, slik at nye sider følger samme rytme
• Skille mellom offentlig markedsføring og begrenset innhold, der siste del håndteres med roller og, om nødvendig, egen autentisering - ikke med skjulte menyer

Denne modellen er spesielt nyttig når flere personer på Forus skal publisere, eller når engelsk og norsk versjon må holdes i takt uten å duplisere hele temastrukturen.

#Spørsmål jeg ofte får fra Stavanger-bedrifter

Hva skjer hvis kravene endres underveis? Det er normalt. Den sprintbaserte arbeidsformen gjør at vi kan justere omfanget mellom iterasjoner. Konsekvensen for tid og budsjett legges åpent på bordet, og du godkjenner før vi går videre.

Hva inkluderer en vedlikeholdsavtale? Oppdatering av WordPress, plugins og temaer (testet i testmiljø først), daglige sikkerhetskopier med rimelig oppbevaringstid, oppetidsovervåking, sikkerhetsskanning og avsatte utviklertimer til mindre endringer.

Bygger du nytt tema eller utvider det jeg har? Begge deler forekommer. Et nytt prosjekt starter som regel med et eget block-tema; et arvet prosjekt trenger oftere fokusert refaktorering enn en full omskrivning. Valget tas på grunnlag av kostnad mot teknisk gjeld, og begrunnelsen skrives ned.

Hva skiller dette fra et generisk byrå i Stavanger? Du jobber direkte med en senior utvikler, ikke gjennom flere ledd. Avveiningene er skriftlige, akseptkriteriene er målbare, og omfanget bygges rundt WordPress-utvikling framfor en bred redesignpakke.

Kan dere koble WordPress mot systemene vi allerede bruker? Ofte ja, via REST, webhooks eller dokumenterte API-er. Grensen for hva som hører hjemme i WordPress versus i et ERP eller CRM, avklares skriftlig før koden skrives, slik at nettstedet ikke blir en skjult kopi av forretningssystemet.

#Priser og forutsigbarhet

Prisen settes individuelt etter omfanget i den enkelte saken, og du får en detaljert oversikt før arbeidet starter. Endringer i omfang diskuteres åpent med tydelige kostnadsfølger, slik at det ikke kommer overraskelser på fakturaen. Jeg skriver kode andre utviklere kan vedlikeholde: dokumentasjon, kodestandarder og en overleveringssesjon hører med, og det er ingen leverandørlåsing eller proprietære svarte bokser.

#Lokal SEO for synlighet i Stavanger-markedet

Et godt bygget nettsted har bare verdi om målgruppen i Stavanger og Rogaland finner det. Det grunnleggende SEO-arbeidet er en del av leveransen:

• Teknisk fundament: ryddige URL-strukturer, XML-nettkart, kanoniske tagger og riktig overskriftshierarki, med strukturerte data (LocalBusiness, Organization, Product, FAQ, HowTo) der de hører hjemme
• Lokal synlighet: kobling mot Google Business-profil, lokal schema med Stavanger-adresse, og konsistent NAP-informasjon på tvers av oppføringer
• Core Web Vitals som rangeringssignal, behandlet som en del av utviklingen og ikke en etterpåklattet optimalisering
• Flerspråklig oppsett med hreflang og uavhengige metadata per språk for bedrifter som retter seg mot markeder utenfor Norge fra Stavanger-regionen
• Innhold som speiler faktiske søkeintensjoner i regionen - energitjenester, B2B-kontakt, rekruttering - uten tykke tekstblokker skrevet bare for søkemotorer

#Universell utforming i praksis

Tilgjengelighet er ikke en avsluttende sjekk på et Stavanger-prosjekt. Det er et sett med krav som må ligge i temakoden fra første branch. Regionens blanding av private leverandører, kommunale virksomheter, forskningsmiljøer rundt UiS og selskaper som selger inn til det offentlige, gjør universell utforming til et anskaffelseskrav lenge før det er et designspørsmål. Denne delen beskriver regelverket som gjelder, hva som faktisk må rettes i et eksisterende WordPress-tema, hvordan det testes, og hvordan du unngår at neste oppdatering river ned arbeidet.

#Regelverket som faktisk gjelder

Norsk rett stiller kravet direkte. Likestillings- og diskrimineringsloven pålegger universell utforming av IKT-løsninger rettet mot allmennheten, og forskrift om universell utforming av IKT-løsninger fastsetter den tekniske normen. Forskriften peker på WCAG 2.1 nivå AA. For virksomheter i privat sektor er suksesskriteriene 1.2.3, 1.2.4 og 1.2.5 om tidsbasert media unntatt, mens offentlig sektor må dekke også disse. Tilsynet for universell utforming av ikt, som ligger i Digitaliseringsdirektoratet, fører tilsyn og kan følge opp med pålegg og tvangsmulkt. Offentlige virksomheter skal i tillegg publisere en tilgjengelighetserklæring.

EUs tilgjengelighetsdirektiv utvider omfanget. Direktiv (EU) 2019/882, ofte omtalt som European Accessibility Act, får anvendelse i EU fra 28. juni 2025 og treffer blant annet netthandel, banktjenester, e-bøker, billettsalg og elektronisk kommunikasjon. Regelverket er EØS-relevant, og en Stavanger-butikk eller tjenesteleverandør som selger til forbrukere i EU, må forholde seg til det uavhengig av hvor langt den norske gjennomføringen er kommet. Den harmoniserte europeiske standarden EN 301 549 er målestokken direktivene bruker, og den viser videre til WCAG. Praktisk konsekvens: bygg mot WCAG, så dekker du begge regelsett med samme arbeid.

#Hva som faktisk må rettes i et eksisterende tema

Kontrast. Suksesskriterium 1.4.3 krever 4,5:1 for vanlig brødtekst og 3:1 for stor tekst, mens 1.4.11 krever 3:1 for grensesnittkomponenter og meningsbærende grafikk. De typiske bruddene i et arvet tema er lysegrå hjelpetekst under skjemafelt, plassholdertekst brukt som etikett, hvit tekst på en merkevarefarge som ikke er testet, og ikoner uten nok kontrast mot bakgrunnen. Rettingen hører hjemme i paletten i theme.json, ikke i enkeltblokker, ellers kommer feilen tilbake neste gang noen bygger en landingsside.

Tastaturfokus. Alt som kan klikkes, må nås med Tab og betjenes med Enter eller mellomrom, fokusmarkeringen må være synlig etter 2.4.7, og WCAG 2.2 la til 2.4.11, som krever at det fokuserte elementet ikke skjules helt av for eksempel en fast topplinje. Vanlige feil: temaets CSS slår av outline uten å erstatte den, mobilmeny og undermenyer som bare åpner på hover, modaler uten fokusfelle og uten Esc, og karuseller der fokus forsvinner inn i skjulte visningsflater. Rett det med en tydelig :focus-visible-markering, scroll-margin-top som kompenserer for sticky header, inert på bakgrunnsinnhold når en dialog er åpen, og fokus tilbake til utløserknappen når dialogen lukkes.

Skjemaetiketter. Hvert felt trenger en label koblet til feltets id, ikke bare en plassholder som forsvinner ved utfylling. Feilmeldinger knyttes til feltet med aria-describedby slik at skjermleseren leser dem, og autocomplete settes på navn, e-post, telefon og adresse etter 1.3.5. Obligatoriske felt merkes i tekst, ikke bare med rød farge, siden 1.4.1 forbyr farge som eneste bærer av informasjon. På en WooCommerce-kasse er det som regel egne felter lagt til av plugins eller av forrige utvikler som bryter mønsteret, ikke kjernen selv. På B2B-kontaktskjemaer for energileverandører er det samme mønsteret: uten riktige etiketter faller både tilgjengelighet og datakvalitet.

Tilgjengelige navn. Suksesskriterium 4.1.2 krever navn, rolle og verdi for hver komponent. I praksis betyr det slutt på lenker som bare heter Les mer, ikonknapper uten tekst, og aria-label som sier noe annet enn den synlige teksten, som bryter 2.5.3. WordPress-temaer har allerede klassen screen-reader-text for skjult, lesbar tekst, og dekorative SVG-ikoner skal ha aria-hidden når det står tekst ved siden av.

Overskriftsrekkefølge og landemerker. Én h1 per side, ingen hopp fra h2 til h4. Blokkeditoren gjør dette lett å bryte fordi redaktører velger overskriftsnivå etter hvordan det ser ut på skjermen. Begrens derfor tilgjengelige nivåer på overskriftsblokken i mønstrene, og la mønsteret sette riktig nivå på forhånd. Landemerkene header, nav, main og footer skal være på plass, og en hopp-til-innhold-lenke skal være det første fokuserbare elementet på siden. Alt-tekst settes per bruk av bildet, ikke per fil, fordi samme bilde kan være meningsbærende på én side og rent dekorativt på en annen.

#Hvordan det testes

Automatiske skann fanger bare den delen av kravene som lar seg maskinlese, og resten må gjøres manuelt. Et fungerende oppsett kombinerer begge deler: @axe-core/cli eller pa11y-ci kjørt mot en fast URL-liste i utrullingsløpet, Lighthouse-kategorien for tilgjengelighet som grov indikator, og deretter en manuell runde. Den manuelle runden er en tastaturgjennomgang fra topp til bunn uten mus, en skjermleserkontroll med NVDA i Firefox på Windows og VoiceOver i Safari på macOS og iOS, zoom til 400 prosent, som tilsvarer en bredde på 320 CSS-piksler etter 1.4.10, kontroll av tekstavstand etter 1.4.12, og en sjekk i forced-colors-modus i Windows. WCAG 2.2 la i tillegg til 2.5.8 med minste målestørrelse på 24x24 CSS-piksler, som ofte treffer små ikonknapper i topplinjen og i kassen. Funnene skrives ned med suksesskriterium, side og skjermbilde, slik at listen kan brukes som grunnlag for en tilgjengelighetserklæring.

#Hvordan du unngår å ødelegge det ved neste oppdatering

Legg kontrollen i utrullingsløpet. En tilgjengelighetstest som bare kjøres ved lansering, holder til lansering. Kjør pa11y-ci eller axe som et steg i CI som blokkerer sammenslåing ved nye brudd, og kjør samme skann i testmiljøet etter hver plugin- og kjerneoppdatering, siden en oppdatert plugin kan endre markup i kassen eller i skjemaene uten at noe annet ser annerledes ut.

Lås det redaktøren ikke skal kunne bryte. Slå av egendefinerte farger i theme.json og la paletten være den eneste kilden til farge, begrens overskriftsnivåene i mønstrene, og bruk blokklåsing der strukturen er en del av kravet. Da blir riktig valg standardvalget i stedet for noe som må huskes.

Skriv det ned og hold det oppdatert. Redaksjonell dokumentasjon med en kort sjekkliste for alt-tekst, lenketekst og overskriftsnivå gjør mer for tilgjengeligheten over tid enn en engangsrapport. Tilgjengelighetserklæringen oppdateres ved vesentlige endringer på nettstedet, og kjente avvik føres opp der med en plan for retting i stedet for å skjules. Frekvensen på skann og oppfølging avtales i vedlikeholdsavtalen sammen med resten av responstidene.

#Hosting, miljøer og overlevering i Stavanger-prosjekter

Et WordPress-prosjekt for en virksomhet på Forus eller i Stavanger sentrum trenger mer enn produksjonsmiljøet. Jeg setter opp minst tre miljøer der det er praktisk: utvikling, test og produksjon, med samme PHP-versjon og samme pluginsett. Deploy skjer via en dokumentert sti, ikke via FTP midt i arbeidsdagen. Sikkerhetskopier og tilbakeføringsplan avtales før første utrulling.

For energileverandører og kystnære tjenesteselskaper er ofte flere interessenter involvert i godkjenning - salg, kommunikasjon, HSE og IT. Derfor er akseptkriteriene skriftlige: hvilke sider som skal fungere, hvilke skjemaer som skal sende, hvilke språk som skal være synlige, og hvilke ytelsesmål som skal være grønne før lansering. Overleveringen inkluderer runbook for de ikke-opplagte valgene, slik at neste utvikler - internt eller ekstern - kan fortsette uten å gjette.

#Redaksjonell hverdag etter lansering

Et block-tema er bare verdifullt hvis redaksjonen faktisk bruker det. Jeg leverer korte, konkrete instruksjoner for hvordan forsider, tjenestesider og nyheter bygges med mønstrene som følger med. Der UiS-samarbeid eller kampanjer krever midlertidige landinger, finnes et mønster for det. Der energiprosjekter trenger dokumentlister, finnes felter og blokker for det. Målet er at publisering ikke skal kreve en utviklerbillett for hver tekstendring.

#Når headless eller hybrid er aktuelt

De fleste Stavanger-nettsteder trenger ikke en full headless-arkitektur. Når en mobilapp, en egen portal eller en eksisterende frontend allerede lever sitt eget liv, kan WordPress likevel fungere som innholdskilde via REST eller WPGraphQL. Jeg anbefaler headless bare når det finnes et konkret behov, ikke som standard. Hybrid - WordPress for markedsføringssider og egen app for innloggede funksjoner - er ofte mer realistisk for B2B i regionen enn å flytte alt ut av editoren.

#Andre norske byer

Trenger du WordPress-utvikling i en annen norsk by, gjelder de samme norske rammene rundt betaling, frakt, MVA og personvern, men med lokal kontekst. Se også WordPress-utvikler i Bergen og WordPress-utvikler i Trondheim for hvordan arbeidet tilpasses der.

#Start prosjektet ditt i Stavanger

Trenger virksomheten din i Stavanger, på Forus eller langs kysten en utvikler som kjenner både WordPress og de norske rammene rundt betaling, frakt, MVA og personvern, så ta kontakt for en uforpliktende samtale. Jeg går gjennom situasjonen, ser på dagens installasjon og gir en ærlig vurdering av hva som faktisk trengs, før vi blir enige om omfang og forventninger. Arbeidet tilpasses energikjedens dokumentasjonskrav, kystnær B2B-kommunikasjon og redaksjonell hverdag - uten fabrikerte kundecaser eller påståtte prosenttall.