Hvordan bygge en portefølje for WordPress-utviklere i 2026

#Hvorfor porteføljen er viktig for en WordPress-utvikler

For en WordPress-utvikler er porteføljen beviset på at du kan det du sier at du kan, og en måte å vise hvordan du tenker, noe en CV ikke får fram. Det finnes mange WordPress-frilansere, så det som skiller deg ut, er kvaliteten på det du viser, ikke antallet prosjekter.

#Hva en kunde ser etter hos en WordPress-frilanser

• Løsninger, ikke teknologier: den som ansetter, bryr seg ikke om at du bruker React, men om at du har løst den typen problem de har.
• Måltall og resultater: konkrete tall med kilde, ikke vage formuleringer som “jeg forbedret ytelsen”.
• Tankeprosess: hvordan du kom fram til løsningen, og hvilke alternativer du valgte bort.

#Hvordan skrive en kasusstudie for porteføljen

I stedet for et skjermbilde og en lenke beskriver du prosessen. En god portefølje er en samling kasusstudier, og hver av dem svarer på tre spørsmål.

#Utfordring: kundens problem

Ikke skriv “jeg bygde en nettside”. Skriv det konkrete problemet. Eksemplene nedenfor er illustrasjoner, ikke hentet fra virkelige prosjekter:

• “En nettbutikk med 10 000 produkter brukte 8 sekunder på å laste og mistet handlekurver underveis.”
• “Nettstedet brukte enorme mengder båndbredde hver måned på grunn av uoptimaliserte bilder.”
• “Kunden mistet konverteringer fra mobil fordi nettsiden ikke var responsiv.”

Hvorfor det fungerer: leseren kjenner seg igjen i problemet. Har de et lignende problem, skjønner de med en gang at du forstår situasjonen deres.

#Løsning: hva du gjorde og hvorfor

Fortell ikke bare hva du gjorde, men hvorfor du valgte akkurat den løsningen og ikke en annen:

«I stedet for standard WooCommerce valgte jeg headless WordPress med Next.js fordi kunden trengte:

• lastetid under 1 s (Core Web Vitals),
• integrasjon med det eksterne API-et i ERP-systemet sitt,
• mulighet til å skalere til 100 000 produkter.

Løsning: WordPress som headless CMS, frontend i Next.js, Redis-cache og Cloudflare som CDN.»

Slik ser leseren at du ikke kopierer maler, men tar beslutninger ut fra teknisk vurdering. Ta gjerne også med det du valgte bort, og hvorfor: en setning som “jeg droppet et cache-programtillegg fordi katalogen endret seg hver time” sier mer enn en liste over verktøy.

#Resultat: tall med kilde

Dette er den viktigste delen. Vis tilstanden før og etter, og si hvor hvert tall kommer fra:

• Google Analytics: konverteringer, fluktfrekvens, forlatte handlekurver.
• PageSpeed Insights (Core Web Vitals): LCP, INP, CLS.
• GTmetrix: lastetid.
• Serverlogger: dataoverføring og databasespørringer.

Et tall uten kilde overlever ikke det første spørsmålet fra en teknisk kunde. Kan du ikke dokumentere det, så ikke publiser det.

#Eksempel på kasusstudie med en oppdiktet kunde

Prosjekt: nettbutikk for en møbelprodusent. Tallene i dette eksemplet er oppdiktet for å illustrere formatet og hører ikke til et virkelig prosjekt.

Utfordring. Kunden hadde en WooCommerce-butikk med 8 000 produkter. Nettsiden brukte 6 sekunder på å laste, med tre konsekvenser:

• 45 prosent forlatte handlekurver,
• et fall i konverteringsraten fra 3,2 prosent til 1,8 prosent i løpet av ett år,
• indekseringsproblemer og Core Web Vitals i rødt.

Løsning.

1. Migrering til headless WordPress: WordPress som CMS og Next.js som frontend.
2. Bildeoptimalisering: AVIF, utsatt lasting og responsive bilder.
3. Cache-strategi: Redis for produkter og Cloudflare for statiske ressurser.
4. Databaseoptimalisering: indekser og WP_Query-spørringer.
5. CDN med automatisk minifisering av CSS og JS.

Stabel: headless WordPress, Next.js, Redis, Cloudflare, WooCommerce REST API.

Resultat (illustrasjon):

• Lastetid: fra 6 s til 0,8 s.
• Konvertering: fra 1,8 prosent til 3,9 prosent.
• Forlatte handlekurver: fra 45 prosent til 12 prosent.
• Core Web Vitals: alt i grønt.

En god kasusstudie oppgir også hvor lenge prosjektet varte og hvem som deltok, fordi det gir kunden en idé om omfanget. Gjorde du alt selv, si det; jobbet du med en designer og en annen utvikler, nevn dem etter rolle.

#Hvilken kode du bør vise på GitHub

Søker du jobb i et programvareselskap, må porteføljen vise kodekvalitet.

#Hvordan publisere kode fra private prosjekter

Selv om prosjektet er privat, kan du lage offentlige eksempler:

1. Utdrag fra prosjekter: trekk ut de beste delene og fjern alle kundedata.
2. Bidrag til åpen kildekode: til WordPress Core eller til programtillegg.
3. Egne prosjekter: små verktøy som viser ferdighetene dine.

Før du publiserer et utdrag, sjekk at det ikke inneholder nøkler, interne stier eller kundenavn.

#Egendefinerte WordPress-hooks

Dette eksemplet begrenser og filtrerer hovedspørringen i en butikk:

/**
 * Begrense og filtrere spørringen for WooCommerce-katalogen
 *
 * @param WP_Query $query
 */
add_action('pre_get_posts', function ($query) {
    if (!is_admin() && $query->is_main_query() && is_shop()) {
        $query->set('posts_per_page', 24);
        $query->set('meta_query', [
            [
                'key'     => '_stock_status',
                'value'   => 'instock',
                'compare' => '=',
            ],
        ]);
    }
});

Det viser at du kjenner WordPress-hooks, at du tenker på ytelsen til spørringen og at du dokumenterer koden. En detalj som teller: ikke legg til no_found_rows i en liste med paginering, for det ødelegger sideberegningen.

#Moderne PHP (8.1 eller nyere)

class ProductCache
{
    public function __construct(
        private Redis $redis,
        private int $ttl = 3600
    ) {}

    public function getProductData(int $productId): ?array
    {
        $cacheKey = "product:{$productId}";

        if ($cached = $this->redis->get($cacheKey)) {
            return json_decode($cached, true);
        }

        $product = wc_get_product($productId);
        if (!$product) {
            return null;
        }

        $data = ['id' => $productId, 'name' => $product->get_name(), 'price' => $product->get_price()];
        $this->redis->setex($cacheKey, $this->ttl, json_encode($data));

        return $data;
    }
}

Eksemplet viser typede egenskaper, constructor property promotion, avhengighetsinjeksjon og et cache-mønster. Cache bare dataene du trenger, ikke hele WooCommerce-objekter.

#Utvikling av Gutenberg-blokker

import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps } from '@wordpress/block-editor';

registerBlockType('mitt-prefiks/portfolio-item', {
    edit: ({ attributes }) => {
        const blockProps = useBlockProps();
        return (
            <div {...blockProps}>
                <h3>{attributes.title}</h3>
                <p>{attributes.description}</p>
            </div>
        );
    },
    save: () => null, // Rendres på serversiden
});

Det viser kunnskap om blokk-API-et, React i WordPress og serverside-rendering. Vil du gå videre, forklarer guiden om Gutenberg-blokker, mønstre og Full Site Editing hvordan du strukturerer dem.

#Hvilken teknologistabel som er verdt å vise

Nødvendig i 2026:

• Gutenberg (FSE): Full Site Editing og blokkutvikling.
• React og Next.js: headless WordPress.
• Composer: avhengighetsstyring.
• WP-CLI: automatisering og utrulling.
• Docker: lokalt miljø; det finnes en guide til WordPress-utvikling med Docker.
• Git: versjonskontroll, og ikke bare push og pull, men en grenstrategi.

Gir pluss: TypeScript, GraphQL, tester (PHPUnit, Jest, Cypress) og CI/CD med GitHub Actions eller GitLab CI.

#Hva du ikke bør vise i en utviklerportefølje

1. Prosjekter bygget på ferdige ThemeForest-temaer, med mindre du har tilpasset dem grundig. Vis i så fall hva du endret.
2. Kode uten kommentarer, selv om den virker åpenbar for deg.
3. Utdatert praksis, som direkte SQL-spørringer i stedet for WP_Query.
4. Hardkodede verdier: vis at du bruker konstanter, filtre og innstillinger.

#Hvordan bygge porteføljen i WordPress med ACF

Du trenger ikke kompliserte programtillegg: WordPress har det som trengs.

#Hvordan registrere en custom post type for porteføljen

function mitt_tema_registrer_portfolio_cpt() {
    register_post_type('portfolio', [
        'labels' => [
            'name' => 'Portefølje',
            'singular_name' => 'Prosjekt',
        ],
        'public' => true,
        'has_archive' => true,
        'supports' => ['title', 'editor', 'thumbnail', 'excerpt'],
        'rewrite' => ['slug' => 'portfolio'],
        'show_in_rest' => true,
    ]);
}
add_action('init', 'mitt_tema_registrer_portfolio_cpt');

#ACF-felter for prosjektene i porteføljen

acf_add_local_field_group([
    'key' => 'portfolio_fields',
    'title' => 'Porteføljedetaljer',
    'fields' => [
        ['key' => 'client_name', 'name' => 'client_name', 'label' => 'Kundenavn', 'type' => 'text'],
        ['key' => 'project_year', 'name' => 'project_year', 'label' => 'Prosjektår', 'type' => 'number'],
        [
            'key' => 'tech_stack',
            'name' => 'tech_stack',
            'label' => 'Teknologistabel',
            'type' => 'checkbox',
            'choices' => [
                'wordpress' => 'WordPress',
                'react' => 'React',
                'nextjs' => 'Next.js',
                'woocommerce' => 'WooCommerce',
            ],
        ],
        [
            'key' => 'metrics',
            'name' => 'metrics',
            'label' => 'Måltall (før og etter)',
            'type' => 'repeater',
            'sub_fields' => [
                ['key' => 'metric_name', 'name' => 'metric_name', 'label' => 'Måltall', 'type' => 'text'],
                ['key' => 'before_value', 'name' => 'before_value', 'label' => 'Før', 'type' => 'text'],
                ['key' => 'after_value', 'name' => 'after_value', 'label' => 'Etter', 'type' => 'text'],
            ],
        ],
    ],
    'location' => [[[
        'param' => 'post_type',
        'operator' => '==',
        'value' => 'portfolio',
    ]]],
]);

Slik får hvert prosjekt de samme feltene, og du kan vise før- og etter-sammenligningen med samme struktur i alle kasusstudiene. Data du ikke vil skal vises på redigeringsskjermen, som interne notater eller kilden til hvert måltall, lagrer du i metafelt med understrek som prefiks (_kilde_maltall): WordPress skjuler dem fra panelet for egendefinerte felt.

#Malen single-portfolio.php for hvert prosjekt

// single-portfolio.php
get_header();
?>

<article class="portfolio-case-study">
    <header>
        <h1><?php the_title(); ?></h1>
        <p>
            <?php if ($client = get_field('client_name')) : ?>
                Kunde: <?php echo esc_html($client); ?>
            <?php endif; ?>
            År: <?php echo esc_html(get_field('project_year')); ?>
        </p>
    </header>

    <section class="solution">
        <h2>Løsning</h2>
        <?php the_content(); ?>
    </section>

    <section class="results">
        <h2>Resultater</h2>
        <?php foreach ((array) get_field('metrics') as $metric) : ?>
            <p>
                <?php echo esc_html($metric['metric_name']); ?>:
                <?php echo esc_html($metric['before_value']); ?> til
                <?php echo esc_html($metric['after_value']); ?>
            </p>
        <?php endforeach; ?>
    </section>
</article>

<?php get_footer();

Escape alltid med esc_html(): porteføljen er din egen kode og blir vurdert som det.

#Eget REST API-endepunkt for porteføljedata

Bygger du en interaktiv portefølje eller henter porteføljedata inn i en separat frontend, kan du eksponere de samme feltene gjennom et eget REST API-endepunkt. Kundenavnet tas bare med når feltet har en verdi, akkurat som i malen:

add_action('rest_api_init', function (): void {
    register_rest_route('mitt-prefiks/v1', '/kasusstudier', [
        'methods'             => 'GET',
        'callback'            => 'mitt_tema_hent_kasusstudier',
        'permission_callback' => '__return_true',
    ]);
});

function mitt_tema_hent_kasusstudier(WP_REST_Request $request): WP_REST_Response {
    $query = new WP_Query([
        'post_type'      => 'portfolio',
        'posts_per_page' => 10,
        'post_status'    => 'publish',
    ]);
    $data = [];

    foreach ($query->posts as $post) {
        $item = [
            'id'      => $post->ID,
            'tittel'  => get_the_title($post),
            'url'     => get_permalink($post),
            'aar'     => (int) get_field('project_year', $post->ID),
            'maltall' => array_map(
                fn ($m) => array_map('sanitize_text_field', (array) $m),
                (array) get_field('metrics', $post->ID)
            ),
        ];

        if ($client = get_field('client_name', $post->ID)) {
            $item['kunde'] = sanitize_text_field($client);
        }

        $data[] = $item;
    }

    return new WP_REST_Response($data, 200);
}

Endepunktet er offentlig (__return_true), så det skal bare returnere felt som allerede vises på nettsiden, aldri interne notater fra metafeltene med understrek.

#Hvordan få porteføljen til å rangere i Google

Porteføljen er ikke bare for mennesker: Google leser den også.

#Schema.org JSON-LD-markering for porteføljen

function mitt_tema_portfolio_schema() {
    $schema = [
        '@context' => 'https://schema.org',
        '@type' => 'CreativeWork',
        'name' => get_the_title(),
        'description' => get_the_excerpt(),
        'creator' => [
            '@type' => 'Person',
            'name' => 'Ditt navn',
        ],
        'datePublished' => get_the_date('c'),
        'url' => get_permalink(),
    ];

    if ($client = get_field('client_name')) {
        $schema['sourceOrganization'] = [
            '@type' => 'Organization',
            'name' => $client,
        ];
    }

    return $schema;
}

Kundenavnet kommer bare med i markeringen når feltet har en verdi, så en kunde som foretrekker å være anonym, vises verken på siden eller i de strukturerte dataene.

#Hvordan optimalisere bildene i porteføljen

1. Utsatt lasting (lazy loading): for alle bilder unntatt det første synlige.
2. Moderne formater: WebP eller AVIF; guiden om bildeoptimalisering i WordPress forklarer prosessen.
3. Responsive bilder: ulike størrelser avhengig av enheten.
4. Beskrivende alt-tekst: “dashbord med måltall før og etter migreringen”, ikke “portefolje-bilde-1”.

#Hva de beste porteføljene har til felles

1. Konkrete måltall: ikke “jeg forbedret ytelsen”, men “lastetiden gikk ned fra 5 s til 0,8 s”, med kilde.
2. Tankeprosess: hvordan man kom fram til løsningen, og hva som ble valgt bort.
3. Kode i kontekst: ikke bare en lenke til GitHub, men en forklaring av beslutningene.
4. Visuelt materiale: arkitekturdiagrammer og skjermbilder før og etter.
5. Kundeuttalelser: én setning signert av kunden, med tillatelse, veier tyngre enn alle dine egne adjektiver.

#Hvordan vise private prosjekter eller prosjekter under taushetserklæring

Mange av de beste prosjektene kan ikke vises som de er: koden tilhører kunden, eller kontrakten hindrer deg i å nevne navnet. Kasusstudien er likevel mulig.

• Kundenavn: ACF-feltet er valgfritt, og CreativeWork-markeringen legger bare til organisasjonen når feltet har en verdi. Beskriv bransjen, for eksempel “møbelprodusent”, og la navnet stå tomt.
• Kode: trekk ut utdrag til et offentlig repositorium. En hook som optimaliserer WP_Query eller en cache-klasse i PHP 8.1 viser vurderingsevne uten å eksponere prosjektet.
• Arkitektur: vis systemflyten og datamodellen i et ryddig diagram når selve koden ikke kan deles.
• Git-historikk: når du legger ut demoprosjekter, bruk lesbare commit-meldinger (feat:, fix:, refactor:) og en README.md med installasjonsinstruksjoner, slik at repositoriet kan leses som en del av kasusstudien.
• Måltall: noterte du dem ikke underveis, hent dem fra Google Analytics, PageSpeed Insights, GTmetrix eller loggene. Finnes det ingen pålitelige data, beskriv utfordringen og det tekniske valget, og ikke publiser et tall du ikke kunne forsvart overfor kunden.
• Tillatelse: spør hva du kan publisere før du skriver kasusstudien, ikke etterpå.
• Eget arkiv: ta vare på før- og etter-tallene, skjermbildene og kundens tilbakemelding fra hvert prosjekt i dine egne filer, så du kan dokumentere dem når noen stiller spørsmål ved dem.

En kasusstudie uten logo, men med problemet, løsningen og begrunnelsen godt forklart, svarer fortsatt på spørsmålet som teller: hvorfor kunden bør velge akkurat deg.

#Profil på WordPress.org som offentlig bevis på bidrag

En kasusstudie skriver du selv. Profilen på WordPress.org (profiles.wordpress.org) genereres av plattformen selv, og derfor leser en teknisk kunde den som en uavhengig oversikt. Lenk til den fra porteføljen sammen med GitHub-profilen.

Det som teller mest i profilen, er merkene. Håndboken til Meta-teamet skiller mellom to typer: bidragsytermerker, som generelt tildeles alle som har bidratt til et team, og teammerker, som de som er aktive i teamet får. Hvert team fastsetter egne kriterier, og flere merker tildeles automatisk:

De øvrige tildeler hvert team manuelt. Kriteriene varierer: håndboken til Openverse-teamet krever for eksempel at du oppfyller minst ett av flere vilkår, blant annet å åpne fem eller flere gyldige issues, få en vesentlig pull request slått sammen eller oversette 25 strenger. Et Plugin Developer-merke sier ikke om programtillegget er bra, men det viser at det har vært gjennom en ekstern gjennomgang, og det er mer enn et skjermbilde viser.

#Hva Five for the Future er og hvordan det teller i en portefølje

Five for the Future startet med et blogginnlegg av Matt Mullenweg 30. september 2014. Setningen som ga programmet navnet, sier at organisasjoner som vil gjøre WordPress-kaken større, og ikke bare sitt eget kakestykke, «bør sette av 5 prosent av folkene sine til å jobbe med noe som har med core å gjøre», enten det er utvikling, dokumentasjon, sikkerhet, supportforum, temagjennomgang, opplæring, testing eller oversettelse (Matt Mullenweg: Five for the Future, egen oversettelse).

I dag ligger programmet på wordpress.org/five-for-the-future. Både organisasjoner og enkeltpersoner kan forplikte seg: organisasjonene vises på siden med forpliktelser (pledges), og enkeltbidragsytere vises med navn, bilde, en kort biografi og organisasjonen som sponser dem, hvis det finnes en. For en frilanser er en forpliktelse om et antall timer i uken til et bestemt team (Core, Polyglots, Training, Documentation) en etterprøvbar linje i porteføljen. For et byrå er en plass på listen over organisasjoner en måte å vise at det bidrar til prosjektet det lever av.

#Hvordan publisere et programtillegg i katalogen på WordPress.org

Et godkjent programtillegg i katalogen er et kodeeksempel som andre har gjennomgått, og som har ekte brukere. Håndboken for programtillegg beskriver prosessen:

1. Registrer deg på WordPress.org med en e-postadresse du faktisk leser; sender du inn på vegne av et firma, bruk en offisiell e-postadresse i firmaet.
2. Send inn en kort beskrivelse og en komplett zip-fil av programtillegget, den samme du ville installert manuelt fra kontrollpanelet.
3. Vent på gjennomgangen: teamet går gjennom koden innen 14 virkedager og tar kontakt hvis de finner problemer.
4. Etter godkjenning får du tilgang til et Subversion-repositorium; programtillegget vises i katalogen når du laster opp koden og readme-filen via SVN.

To detaljer er viktige for porteføljen. URL-en til programtillegget kan ikke endres etter innsending, men det synlige navnet kan. Og hvert programtillegg i katalogen har sitt eget supportforum, så svarene dine til brukere blir offentlige og en del av det en kunde kan lese om deg.

De detaljerte retningslinjene for katalogen er 18 i tallet. De som forklarer flest avslag: GPL eller kompatibel lisens (retningslinje 1), kode som i hovedsak er lesbar for mennesker (4), ingen funksjoner som er låst til du betaler (5), ingen kontakt med eksterne servere uten uttrykkelig samtykke (7) og ikke bruke andres varemerker som første ledd i slugen (17). Oppfyller programtillegget ditt dem, har du allerede et teknisk argument til kasusstudien.

#GitHub-profil: README på profilen og festede repositorier

Dokumentasjonen til GitHub stiller fire vilkår for at en README skal vises på profilen din: et repositorium med samme navn som brukernavnet ditt, offentlig, med en README.md-fil i roten og med noe innhold. Bruk den som en innholdsfortegnelse: hva du gjør, lenke til porteføljen, lenke til profilen på WordPress.org og de to eller tre repositoriene som representerer deg best.

I tillegg kan du feste på profilen opptil seks repositorier og gists til sammen. Fest dem som hører til kasusstudiene dine, som programtillegget i katalogen, repositoriet med anonymiserte kundeutdrag eller blokktemaet, og ikke forker uten endringer.

#Learn WordPress for å tette hull i teknologistabelen

Ser du mens du forbereder porteføljen at du mangler noe fra stabellisten, organiserer Learn WordPress innholdet sitt i tre læringsløp (bruke, utvikle og designe med WordPress), med kurs, leksjoner og direktesendte workshops. I oktober 2026 er kurset Beginner WordPress Developer oppført med 9 timer og 59 leksjoner, og Intermediate Theme Developer med 8 timer og 32 leksjoner. Et fullført kurs erstatter ikke en kasusstudie; det som hører hjemme i porteføljen, er blokken eller temaet du bygger med det du har lært.

#Hvor du bør begynne når du lager porteføljen

1. Velg 5 til 7 prosjekter med et resultat du kan måle.
2. Samle inn dataene: måltall med kilde, skjermbilder og, hvis kunden tillater det, en setning fra dem.
3. Skriv den første kasusstudien med strukturen utfordring, løsning og resultat. Regn med rundt to timer.
4. Forbered kodeeksemplene på GitHub, uten kundedata og med PHP 8.1 eller nyere.
5. Sett opp CPT-en med ACF og publiser kasusstudiene i samme format.
6. Gå gjennom GitHub-koden hver gang du legger til et prosjekt: et repositorium med utdatert syntaks svekker kasusstudien som lenker til det.

Porteføljen er ikke en CV: hvert prosjekt skal svare på hvorfor de bør velge akkurat deg. Som referanse for en publisert kasusstudie med denne strukturen kan du se kasusstudien om WooCommerce-optimalisering.