Hva er en WordPress-utvikler? I WPPoland er det meg, Mariusz Szatkowski. Jeg bygger, tilpasser og vedlikeholder WordPress med PHP, JavaScript (React for blokkeditoren), MySQL og kjerne-API-ene, og det har jeg gjort siden 2006. Jeg jobber alene fra Gdynia: koden du får, har jeg skrevet selv. På norske oppdrag betyr det ofte Vipps i kassen og frakt med Posten og Bring. Vet du allerede hva du trenger, står omfang og tilbud lenger ned.
Nøkkelfakta (kort versjon)
En WordPress-utvikler skriver PHP 8.x og React, lager egne blokk-temaer og plugins, kobler CRM og ERP og setter opp WooCommerce etter WordPress Coding Standards. I WPPoland er det Mariusz Szatkowski.
En WordPress-spesialist tar det som allerede er i produksjon: mislykkede oppdateringer, skadevare, treg lasting eller en kasse som slutter å ta imot betalinger.
Hvem du ansetter
- Kommersiell WordPress siden 2006, før Gutenberg og REST API
- Senior-ledet: ingeniøren fra discovery er den samme i uke seks
- Ingen offshore-overlevering, ingen PM-kostnad fakturert
- WordCamp Europe-arrangør, WordPress Foundation Credits-mentor
- Shopify Academy: CRO-læringssti pluss Partner Marketing (Credly, 2025)
Shopify Academy-sertifiseringer
Hvem: Mariusz Szatkowski, senior WordPress-utvikler som har jobbet med WordPress siden 2006. Jeg sitter i Gdynia og jobber eksternt for bedrifter i Norge og resten av Europa. Ikke noe team, ingen underleverandører.
Hva: Egenutviklet WordPress og WooCommerce, headless-oppsett, arbeid med Core Web Vitals målt på ekte brukere, flerspråklige nettsteder og API-integrasjoner. Grafisk design og wireframes leverer du; jeg implementerer dem.
Pris: omfang og pris avtales individuelt i et skriftlig tilbud. Tidsplanen følger av omfanget og står i tilbudet.
Nøkkelkompetanser hos en WordPress-utvikler i 2026
En WordPress-utvikler i 2026 må kunne PHP 8.x, JavaScript med React og databasen under WordPress. Tabellen ordner stacken etter lag:
| Lag | Obligatoriske teknologier | Komplementære teknologier |
|---|---|---|
| Backend | PHP 8.x (OOP, typed properties, enums), WordPress Core API, WooCommerce REST | Laravel, Symfony, Composer |
| Frontend | React, JavaScript ES6+, Gutenberg-blokker, Full Site Editing, Tailwind | Next.js, Astro, Vue.js |
| Databaser | MySQL / MariaDB, WP_Query-optimalisering, egne tabeller | Redis, PostgreSQL, Elasticsearch |
| DevOps | Git, Composer, NPM, CI/CD, Docker, staging og produksjon | Cloudflare Workers, AWS, GCP |
| Sikkerhet | WP-herding, OWASP Top 10, beskyttelse mot SQL-injeksjon og XSS | WAF, CSP, sikkerhetshoder |
Bredere stack-arbeid utenfor WordPress (API-er, integrasjoner, nye applikasjoner) prises som programvareutvikler.
Tekniske bevis og åpen kildekode-aktivitet
Det du kan sjekke selv, uten å ta mitt ord for det:
- WordPress-kjernebidragsyter: patcher med enhetstester levert via Trac innen query-klasser, REST API og internasjonalisering (bl.a. #51811,
ssom alias forsearchiWP_Term_Query, #43502, reset av postdata i REST-kontrolleren for innlegg, #64986, gettext i forhåndsvisning), i tillegg til general translation editor for polsk (profiles.wordpress.org/motylanogha). - 30 gratis plugins på WordPress.org, blant dem “Polski for WooCommerce”, skrevet etter WordPress Coding Standards.
- Åpen kildekode på GitHub: blant annet
woocommerce-mcp, en skrivebeskyttet Model Context Protocol-server som gjør WooCommerce-data tilgjengelig for AI-agenter. - WordPress-fellesskapet: arrangør av WordCamp Gdynia, medarrangør av WordCamp Polska og WordCamp Europe, foredragsholder og WordPress Foundation Credits Mentor.
Kodeeksempler fra en WordPress-utvikler
Forskjellen mellom en utvikler og en klikker synes i koden som havner i produksjon. Her er fire mønstre som ferdige plugins og page buildere sjelden gjør riktig: sikkerhet, databasespørringer, API og cache.
1. Sikker lagring av meta: rettighet per innlegg, nonce, sanitering
Sjekk av edit_post for det konkrete innlegget i stedet for en generell rolle, nonce ved lagring og sanitering av inndata før de lagres. Escaping skjer separat, ved visning.
Hva dette betyr for deg: en redaktør kan ikke overskrive andres data, og lagringen kan ikke utløses fra en ekstern side. Uten dette holder det med én forfatterkonto for å bytte ut innhold som ingen har liggende i en egen backup.
Vis PHP-koden (44 linjer)
declare( strict_types=1 );
add_action( 'init', 'wppl_register_projekt_meta' );
add_action( 'save_post_wppl_projekt', 'wppl_save_projekt_meta', 10, 2 );
// Meta med typing, sanitering og auth_callback basert på capability.
function wppl_register_projekt_meta(): void {
register_post_meta(
'wppl_projekt',
'wppl_budzet_pln',
array(
'type' => 'integer',
'single' => true,
'show_in_rest' => true,
'sanitize_callback' => 'absint', // Heltall, ingen negative.
'auth_callback' => static function ( bool $allowed, string $meta_key, int $post_id ): bool {
return current_user_can( 'edit_post', $post_id );
},
)
);
}
// Lagring av meta med hele sikkerhetskjeden.
function wppl_save_projekt_meta( int $post_id, WP_Post $post ): void {
// 1. Nonce - beskyttelse mot CSRF.
if ( ! isset( $_POST['wppl_budzet_nonce'] )
|| ! wp_verify_nonce( sanitize_key( wp_unslash( $_POST['wppl_budzet_nonce'] ) ), 'wppl_save_budzet' )
) {
return;
}
// 2. Hopper over autosave og revisjoner.
if ( ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) || wp_is_post_revision( $post_id ) ) {
return;
}
// 3. Rettighet til det konkrete innlegget, ikke generelle 'edit_posts'.
if ( ! current_user_can( 'edit_post', $post_id ) ) {
return;
}
// 4. Sanitering av inndata før lagring.
$budzet = isset( $_POST['wppl_budzet_pln'] )
? absint( wp_unslash( $_POST['wppl_budzet_pln'] ) )
: 0;
update_post_meta( $post_id, 'wppl_budzet_pln', $budzet );
}Klikker: lagrer data i et felt fra page builderen uten egne rettigheter og nonce, så enhver forfatter (og ofte CSRF) kan overskrive verdien, og data lagres gjerne rått og skrives ut uten esc_attr().
2. Effektiv WP_Query uten N+1-problemet
Hvor N+1 oppstår i WordPress, og hvordan ett kall til update_meta_cache() etter at ID-ene er hentet eliminerer det, i stedet for N separate databaseforespørsler i en løkke.
Hva dette betyr for deg: en liste med femti innlegg spør databasen noen få ganger i stedet for titalls. Med reell trafikk er det forskjellen på en server som holder gjennom kampanjen og en som legger seg.
Vis PHP-koden (30 linjer)
function wppl_get_projekty( int $limit = 12 ): array {
$query = new WP_Query(
array(
'post_type' => 'wppl_projekt',
'post_status' => 'publish',
'posts_per_page' => $limit,
'no_found_rows' => true, // Uten SQL_CALC_FOUND_ROWS - vi teller ikke paginering.
'fields' => 'ids', // Bare ID-er, ikke hele objekter.
'update_post_term_cache' => false, // Taksonomier trengs ikke her.
)
);
$ids = $query->posts;
if ( empty( $ids ) ) {
return array();
}
// Nøkkelen til å unngå N+1: én forespørsel primer meta for alle ID-er.
update_meta_cache( 'post', $ids );
$projekty = array();
foreach ( $ids as $post_id ) {
$projekty[] = array(
'id' => (int) $post_id,
'budzet' => (int) get_post_meta( $post_id, 'wppl_budzet_pln', true ), // Treff i cache.
);
}
return $projekty;
}Klikker: page builder-widgeten løper over fulle post-objekter og kaller get_post_meta i hver iterasjon, og genererer titalls SQL-forespørsler per visning, mens standard SQL_CALC_FOUND_ROWS legger til en kostbar radtelling siden aldri bruker.
3. REST API-endepunkt med reell permission_callback og skjema
Per-objekt autorisering i permission_callback, deklarativ validering og sanitering av argumenter, samt et formelt skjema som beskriver kontrakten for API-konsumentene.
Hva dette betyr for deg: integrasjonen mot CRM eller ERP eksponerer ikke dataene dine offentlig, og den ryker ikke ved første endring hos leverandøren.
Vis PHP-koden (25 linjer)
add_action( 'rest_api_init', 'wppl_register_rest_routes' );
function wppl_register_rest_routes(): void {
register_rest_route(
'wppoland/v1',
'/projekty/(?P<id>\d+)/budzet',
array(
'methods' => WP_REST_Server::EDITABLE, // POST, PUT, PATCH.
'callback' => 'wppl_rest_update_budzet',
// Reell autorisering: rettighet til DET KONKRETE innlegget.
'permission_callback' => static function ( WP_REST_Request $request ): bool {
return current_user_can( 'edit_post', (int) $request['id'] );
},
'args' => array(
'budzet' => array(
'type' => 'integer',
'required' => true,
'minimum' => 0,
'sanitize_callback' => 'absint',
'validate_callback' => 'rest_validate_request_arg',
),
),
)
);
}Klikker: plugin-skjemaer eksponerer ofte data via admin-ajax eller en rute med permission_callback satt til __return_true, uten typevalidering og skjema, noe som åpner for uautorisert skriving og ødelegger forutsigbarheten i integrasjonen.
4. Cache med invalidering via last_changed
Kjernemønsteret last_changed fra WordPress: én lagring invaliderer hele familien av cache-nøkler, med korrekt skille mellom hookene before_delete_post og deleted_post.
Hva dette betyr for deg: etter en redigering viser siden den nye versjonen med en gang, uten at noen må be om manuell tømming av cachen.
Vis PHP-koden (18 linjer)
// Cache-nøkkel basert på last_changed-markøren - én invalidering
// ugyldiggjør alle varianter (ulike $limit) uten å slette dem enkeltvis.
function wppl_projekty_cache_key( int $limit ): string {
$last_changed = wp_cache_get_last_changed( 'wppl_projekty' );
return sprintf( 'wppl_projekty_%d_%s', $limit, $last_changed );
}
add_action( 'save_post_wppl_projekt', 'wppl_flush_projekty_cache' );
add_action( 'before_delete_post', 'wppl_flush_projekty_cache' );
// Vi bruker before_delete_post, fordi deleted_post kjører ETTER at innlegget er slettet,
// når get_post_type() allerede returnerer false og typen ikke kan sjekkes.
function wppl_flush_projekty_cache( int $post_id ): void {
if ( 'wppl_projekt' !== get_post_type( $post_id ) ) {
return;
}
wp_cache_set_last_changed( 'wppl_projekty' ); // Ny markør = nye nøkler.
}Klikker: page builderens cache-plugins holder enten på utdaterte data til de tømmes manuelt, eller de prøver å slette enkeltnøkler og mister varianter; å koble invalideringen til deleted_post i stedet for before_delete_post slutter stille å virke, fordi posttypen ikke lenger kan sjekkes.
Billig utvikling koster mest når noe skal endres
Timeprisen sier lite. Det som avgjør totalen er hvor lang tid neste endring tar, og den tiden bestemmes av valg som ble tatt før du kom inn i bildet. Send adressen og beskriv hva dere planlegger det neste året, så sier jeg skriftlig hvor det kommer til å koste og hvorfor. Omfang og pris avtales individuelt.
Fortell hva som skal endresHva skiller en WordPress-utvikler fra en implementør
En implementør stoler på ferdige plugins og temaer. En utvikler skriver det prosjektet trenger og holder resten ute. Hvem som helst kan leie billig webhotell og klikke gjennom autoinstallasjonen av WordPress, men det er administrasjon.
Implementøren (klikkeren)
Starter med et tungt ferdig tema og dekker manglene med mange plugins og en page builder som Elementor eller Divi. Hver ny plugin er mer kode å laste og mer å oppdatere, og en sårbarhet i én av dem rammer hele siden.
WordPress-utvikleren
Bruker WordPress som rammeverk gjennom kjerne-API-ene, skriver forretningslogikken i PHP og blokkene i React og holder antall plugins nede. Resultatet måles: Core Web Vitals fra ekte besøkende før og etter, ikke en enkelt Lighthouse-kjøring.
Hva gjør en WordPress-utvikler
Jeg tar hele den tekniske delen: egenutviklede temaer og plugins, API-integrasjoner mot CRM og ERP, sikkerhetsgjennomganger og Core Web Vitals. Koden følger WordPress Coding Standards, og den ligger i et Git-repository du har tilgang til.
Egenutviklede WordPress-temaer
Blokk-temaer (FSE) fra bunnen, etter designet og wireframes du leverer, responsive og bygget for WCAG 2.2 AA.
WooCommerce-butikker
Betaling med Vipps, Klarna og kort via betalingsleverandøren du allerede bruker, frakt med Posten, Bring eller DHL, B2B-priser og flere valutaer og språk.
Egne plugins og arvet kode
Når ingen eksisterende plugin dekker prosessen, skriver jeg en. Jeg leser også og rydder i kode andre har skrevet.
Ytelse og Core Web Vitals
Objektcache med Redis, CDN, bilder i AVIF og WebP, databasespørringer som ikke vokser med antall innlegg. Målt på ekte brukere før og etter.
API-integrasjoner og headless
WordPress som utveksler data med CRM (HubSpot, Salesforce), ERP og fakturering. Ved behov frontend i Next.js eller Astro, med WordPress som redaksjonsverktøy bak.
Sikkerhetsgjennomgang og herding
Gjennomgang av egne plugins og tema, beskyttelse mot XSS og SQL-injeksjon, sikkerhetshoder, tofaktorinnlogging og en backup som er testet ved gjenoppretting.
Norske nettbutikker som selger til offentlig sektor, må sende faktura i EHF-format over Peppol. WooCommerce gjør ikke det av seg selv; hvordan koblingen kan settes opp, forklarer jeg i artikkelen om e-faktura i WooCommerce med EHF og Peppol. For offentlige oppdragsgivere gjelder også språklova: § 14 krever at statlige organer gjør skjema og andre selvbetjeningstjenester tilgjengelige på bokmål og nynorsk samtidig. Det er et krav til strukturen i WordPress (to språkversjoner med egne slugs og hreflang), og det må planlegges før temaet bygges.

Hvor mye tjener en WordPress-utvikler
Det avhenger mest av ansettelsesform. En fast ansatt utvikler har lønn, en konsulent fakturerer timer eller dager og dekker selv ferie, utstyr og perioder uten oppdrag. Erfaring med e-handel, integrasjoner og headless trekker opp i begge tilfeller. Jeg oppgir ingen lønnstall her: jeg har ingen kilde som skiller WordPress-utviklere ut fra andre programvareutviklere, og tall uten kilde hjelper deg ikke.
I markedet finnes tre måter å fakturere på: timer, dager og fastpris på en avgrenset leveranse. Jeg bruker fastpris når omfanget er skrevet ned, og timer for løpende arbeid.
Totalkostnad for en WordPress-side over tre år
Når en kunde spør hva en WordPress-utvikler koster, er det egentlig spørsmål om hva siden koster over de neste årene. Det billigste tilbudet gir ofte teknisk gjeld som betales senere, gjerne midt i en kampanje.
| Område | Billigste tilbud (klikker) | Individuelt tilbud (senior) |
|---|---|---|
| Utgangspunkt | ferdig tema og Elementor eller Divi, mange plugins | eget blokk-tema (FSE), få plugins |
| Core Web Vitals | sjelden målt | målt på ekte brukere før og etter |
| Sikkerhet | avhenger av at mange plugins holdes oppdatert | færre avhengigheter, oppdateringer testet på staging |
| Norske integrasjoner | Vipps, Bring og EHF løses med tillegg som ikke henger sammen | betaling, frakt og faktura planlagt i samme løsning |
| Neste endring | ofte ombygging | utvidelse av det som finnes |
Feilsøking på et nettsted som allerede er i drift, beskriver jeg på siden om WordPress-spesialist for nedetid, skadevare og ytelse.
WordPress-frilanser eller byrå
Valget avhenger av prosjektet. En frilanser gir direkte kontakt med den som skriver koden, et byrå har flere roller i huset. Byråer som allerede selger WordPress og trenger ekstra kapasitet under eget merke, bruker utviklingskontoret for byråer.
| Kriterium | Frilanser / solo-utvikler | Byrå |
|---|---|---|
| Best egnet for | eget plugin, revisjon, refaktorering, migrering | stor utrulling med design, tekst og markedsføring |
| Kommunikasjon | direkte med personen som skriver koden | gjennom prosjektleder |
| Overhead | ingen prosjektleder eller salgsledd | prosjektledelse og salg inngår i prisen |
| Bus factor | én person, så dokumentasjon og tilgang til repository må være på plass | flere personer kan overta |
Slik jobber jeg: alene, med grafisk design og wireframes fra deg. Du får teknisk dybde uten et byrå imellom.
Hvordan bli WordPress-utvikler
Grunnleggende WordPress lærer man på noen måneder. Å bli en utvikler som tar ansvar for produksjonskode tar år med PHP, databaser og moderne frontend. Å installere et tema og konfigurere plugins er administrasjon.
En realistisk vei: først HTML, CSS, grunnleggende JavaScript og WordPress-løkken; deretter PHP 8.x, hooks og filtre, REST API og React for blokker; så applikasjonsarkitektur, headless, integrasjoner, ytelse og sikkerhet; til slutt revisjoner, større prosjekter og bidrag til WordPress-kjernen.
Det som gir mest, er ekte kundearbeid. WordPress Developer Handbook og Make WordPress Slack er et bedre utgangspunkt enn et bootcamp, og det å lese Trac-tickets og patch-diskusjoner viser hvordan erfarne utviklere feilsøker.
Ansett en WordPress-utvikler
Når KI dukker opp i rekruttering, er det ekte kode som avgjør: WordPress AI-rekruttering og ekte kode, oktober 2026.
Ser du etter en WordPress-utvikler på oppdrag? Du jobber direkte med meg: skriftlig omfang før koding, staging til gjennomgang, og ingen som overtar midt i prosjektet. Tilbudet følger det avtalte omfanget. WooCommerce-butikker bygger jeg som WooCommerce-utvikler.
Hjelp fra en utvikler gir mening når prosjektet vokser forbi en enkel firmaside, for eksempel når:
- du trenger integrasjoner med CRM, ERP, betaling eller interne systemer,
- WooCommerce-butikken er for treg eller ikke tåler mer trafikk,
- du vil bygge om en side fra Elementor, Divi eller en annen tung builder,
- feil må rettes eller arvet kode ryddes,
- du planlegger migrering, flere språk, medlemsområde eller headless.
Slik foregår samarbeidet
- Beskrivelse og avklaring: du sender en skriftlig beskrivelse, jeg stiller spørsmål på e-post og skriver ned omfang, forutsetninger og tidsplan i tilbudet.
- Oppsett: du markerer i et regneark jeg sender hvilke elementer som skal være på hver visning. Grafisk design og mockups er dine; jeg koder det responsive temaet ut fra oppsettet.
- Utvikling: koden ligger i et Git-repository. Hver endring havner på staging, med en skriftlig beskrivelse av hva som er endret.
- Lansering: etter godkjenningen din på staging går siden i produksjon. Deretter kan vi avtale løpende vedlikehold.
- Avtaler: B2B-kontrakt etter polsk rett, faktura med omvendt avgiftsplikt og EU MVA-nummer PL7393037445, og databehandleravtale etter GDPR artikkel 28 før jeg får tilgang til personopplysninger.
Vi kommuniserer skriftlig, på e-post, i dokumenter og i repositoriet. Vil du heller ta en telefon, si fra.
Typer WordPress-prosjekter
| Tjenestetype | Passer for | Typisk innhold |
|---|---|---|
| Enkel nettside | små bedrifter, portefølje | responsivt tema, grunnleggende SEO, få undersider |
| Bedriftsnettsted | voksende selskaper | egne innholdstyper, flere språk, skjema og integrasjoner |
| Nettbutikk | butikker på nett | WooCommerce, betaling, frakt, lager |
| Større løsning | organisasjoner med flere systemer | egen arkitektur, API-integrasjoner, multisite |
| Vedlikehold | alle kunder | overvåking, backup, testede oppdateringer |
Pris og tidsplan står i tilbudet for hvert prosjekt.
WordPress i tall
WordPress er et CMS med åpen kildekode skrevet i PHP med MySQL eller MariaDB som database. Det startet som bloggplattform og brukes i dag også som backend i headless-oppsett og ved AI-implementeringer i bedrifter.
Global markedsbetydning for WordPress (2025/2026)
Markedsdata viser tydelig hvorfor WordPress-utviklerferdigheter er så sterkt etterspurt globalt.
Lønner det seg å bygge WordPress med page builder
En page builder kan holde i starten. På et krevende prosjekt blir den en grense: siden blir tyngre, avhengig av flere tillegg og vanskeligere å endre. Med egen kode svarer hver del på et faktisk behov, og siden kan utvides uten at redaktørene mister oversikten. Skal WordPress være stabilt i dag og kunne bygges ut om et år eller to, lønner det seg å bygge det ordentlig fra start.
Beskriv WordPress-prosjektet ditt
Det beste startpunktet er en kort beskrivelse av kravene, dagens nettsted og problemet som skal løses. Ut fra det setter jeg opp omfang og tilbud. Hver pris er individuell.
Send prosjektbeskrivelseRelaterte tjenester
- WooCommerce-utvikling: nettbutikker i WooCommerce
- WordPress-vedlikehold: overvåking, backup og oppdateringer
- Ytelsesoptimalisering: Core Web Vitals
- GEO/LLMO-tjenester: synlighet i søkemotorer og AI-svar
Regionale sider
- WordPress-utvikler Warszawa
- WordPress-utvikler Berlin
- WordPress-utvikler Wien
- WordPress-utvikler Zürich
Om forfatteren. Mariusz Szatkowski, senior WordPress-utvikler i IT-bransjen siden 2006 og grunnlegger av WPPoland (2007). Jobber alene med WordPress-utvikling, WooCommerce, ytelse og sikkerhet for bedrifter i Europa.
Kilder. Markedsandeler for WordPress: W3Techs. Core Web Vitals: Google Search Console. Språkkrav: språklova på Lovdata.













