WordPress Utvikler i Bergen

WordPress-utvikling for Bergen-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 Bergen og Vestland kommer det i tillegg ofte krav fra maritim leverandørindustri, sesongstyrt turisme og flerspråklige sider rettet mot gjester, partnere og forskningsmiljøer. Det er den jobben denne siden beskriver.

Jeg leverer senior WordPress-utvikling for virksomheter i Bergen-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 Bergen

Bergen er Norges nest største by og knutepunkt for Vestland. Her møtes maritim næring, skipsfart og offshore-tjenester, turisme og hotell rundt Bryggen og cruiseanløp, og et forsknings- og utdanningsmiljø knyttet til Universitetet i Bergen (UiB). Media- og teknologimiljøer i byen binder sammen innholdsprodusenter, tjenesteselskaper og leverandører som trenger nettsteder som tåler flerspråklig innhold, booking- og henvendelsesflyter 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 Bergen er en hotell-, opplevelses- eller leverandørvirksomhet som trenger et nettsted som speiler sesongtopper, flerspråklige landinger og kontaktflater mot både forbrukere og B2B-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 Bergen kan endre forsider, sesonglandinger og tjenesteseksjoner 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

#Maritim næring og digital tilstedeværelse

Mange Bergen-virksomheter lever av å levere utstyr, tjenester eller kompetanse inn i skipsfart, offshore-støtte, havbruksnære leveranser og tilstøtende maritime verdikjeder. 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, sertifikatoversikter, 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 i Bergen sentrum, på Åsane eller ute i Vestland oppdatere innhold når markedet skifter, uten at hvert skifte blir et utviklingsoppdrag.

#Turisme, UiB og Vestland

Turisme og hotell i Bergen - rundt Bryggen, Fløibanen, fjordprodukter og cruiseanløp - har tydelige sesongmønstre. Trafikken kommer i bølger, ofte fra mobil og ofte på engelsk eller andre språk. Et nettsted som skal støtte bookinghenvisninger, opplevelseslandinger og kampanjer, trenger blokkmønstre, gjenbrukbare seksjoner og ytelse som holder seg når besøkstallene stiger. Jeg prioriterer redaksjonell autonomi og mobil ytelse, fordi mange lesere treffer siden fra hotellnett, Bybanen eller reise.

Universitetet i Bergen 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: arrangementer, prosjektsider, publikasjonsoversikter og landinger for samarbeid. Havbruksnære og kystnære tjenesteselskaper i Vestland har i tillegg behov for å vise kapasitet, sertifiseringer og referanseprosjekter uten å låse strukturen til én designer.

#Norske rammer som påvirker koden

Mye av det som skiller en Bergen-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 Bergen 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 - særlig relevant når turister og internasjonale B2B-kunder handler.

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 maritime og havbruksnære 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 Bergen-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 handels- og turismeperioder setter jeg opp full-page caching, rydder i trege databasespørringer, ekskluderer kasse og handlekurv fra cache der det trengs, og belastningstester før sesongen, 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 turisme og maritim dokumentasjon. Store bildegallerier, PDF-er 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 Bergen-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-, opplevelses- 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 turisme, maritim B2B og kunnskapsformidling

Et nettsted for en Bergen-virksomhet fungerer dårlig hvis alt ligger som fritekst i Gutenberg uten struktur. Jeg etablerer typisk:

• Egne posttyper for tjenester, prosjekter, opplevelser eller kompetanseområder, med felter som redaksjonen faktisk fyller ut
• Taksonomier som speiler hvordan markedet snakker (sektor, sesong, leveranseform, språk), ikke interne organisasjonskart
• Blokkmønstre for hero, verdiforslag, dokumentliste, bildegalleri 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 i hotell, kommunikasjon eller maritime salgsteam 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 Bergen-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 Bergen? 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, CRM eller bookingverktøy, 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 Bergen-markedet

Et godt bygget nettsted har bare verdi om målgruppen i Bergen og Vestland 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 Bergen-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 Bergen-regionen
• Innhold som speiler faktiske søkeintensjoner i regionen - maritime tjenester, turisme, B2B-kontakt, rekruttering - uten tykke tekstblokker skrevet bare for søkemotorer

#Universell utforming i praksis

Tilgjengelighet er ikke en avsluttende sjekk på et Bergen-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 UiB, turismeaktører 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 Bergen-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 maritime leverandører og på bookinghenvisninger for turismeaktø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 Bergen-prosjekter

Et WordPress-prosjekt for en virksomhet i Bergen sentrum, på Åsane eller ute i Vestland 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 maritime leverandører, hotell- og opplevelsesaktører og kunnskapsbedrifter rundt UiB er ofte flere interessenter involvert i godkjenning - salg, kommunikasjon, drift 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, sesonglandinger og nyheter bygges med mønstrene som følger med. Der turismekampanjer eller UiB-samarbeid krever midlertidige landinger, finnes et mønster for det. Der maritime prosjekter 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 Bergen-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 og sesongstyrt turisme i regionen enn å flytte alt ut av editoren.

Oslo-regionen deler samme Vipps-, frakt- og MVA-ramme: se WooCommerce-utvikler i Oslo og vedlikehold og support i Oslo.

#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 Stavanger og WordPress-utvikler i Trondheim for hvordan arbeidet tilpasses der.

#Start prosjektet ditt i Bergen

Trenger virksomheten din i Bergen, i Vestland 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 maritime dokumentasjonskrav, sesongstyrt turisme, universitetets formidlingsbehov og redaksjonell hverdag - uten fabrikerte kundecaser eller påståtte prosenttall.

For butikker og nettsteder som trenger en strukturert gjennomgang av risiko, er inngangen sikkerhetsrevisjon i Oslo.