Jak zbudować portfolio programisty WordPress w 2026

#Po co programiście WordPress portfolio

Dla programisty WordPress portfolio jest dowodem, że potrafisz to, co deklarujesz, i sposobem na pokazanie, jak myślisz, czego CV nie przekaże. Freelancerów WordPress jest wielu, więc wyróżnia cię jakość tego, co pokazujesz, a nie liczba projektów.

#Czego klient szuka u freelancera WordPress

• Rozwiązań, nie technologii: zlecającego nie obchodzi, że używasz Reacta, tylko to, że rozwiązałeś problem podobny do jego.
• Metryk i wyników: konkretnych liczb ze źródłem, a nie ogólników w stylu “poprawiłem wydajność”.
• Sposobu myślenia: jak doszedłeś do rozwiązania i jakie warianty odrzuciłeś.

#Jak napisać case study do portfolio

Zamiast zrzutu ekranu i linku opisz proces. Dobre portfolio to zbiór case study, a każde odpowiada na trzy pytania.

#Wyzwanie: problem klienta

Nie pisz “zrobiłem stronę”. Napisz, na czym polegał konkretny problem. Poniższe przykłady są ilustracyjne, nie pochodzą z prawdziwych projektów:

• “Sklep z 10 000 produktów ładował się 8 sekund i po drodze tracił koszyki.”
• “Strona zużywała ogromny miesięczny transfer przez niezoptymalizowane obrazy.”
• “Klient tracił konwersje z telefonów, bo strona nie była responsywna.”

Dlaczego to działa: czytelnik rozpoznaje w tym swój problem. Jeśli ma podobny, od razu wie, że rozumiesz jego sytuację.

#Rozwiązanie: co zrobiłeś i dlaczego

Opisz nie tylko, co zrobiłeś, ale też, dlaczego wybrałeś to rozwiązanie, a nie inne:

“Zamiast standardowego WooCommerce wybrałem headless WordPress z Next.js, bo klient potrzebował:

• czasu ładowania poniżej 1 s (Core Web Vitals),
• integracji z zewnętrznym API swojego ERP,
• możliwości skalowania do 100 000 produktów.

Rozwiązanie: WordPress jako headless CMS, frontend w Next.js, cache Redis i CDN Cloudflare.”

Widać wtedy, że nie kopiujesz szablonów, tylko podejmujesz decyzje techniczne z rozmysłem. Warto dopisać też to, czego nie wybrałeś i dlaczego: zdanie w rodzaju “odrzuciłem wtyczkę cache, bo katalog zmieniał się co godzinę” mówi więcej niż lista narzędzi.

#Wynik: liczby ze źródłem

To najważniejsza część. Pokaż stan przed i po i napisz, skąd pochodzi każda liczba:

• Google Analytics: konwersje, współczynnik odrzuceń, porzucenia koszyka.
• PageSpeed Insights (Core Web Vitals): LCP, INP, CLS.
• GTmetrix: czas ładowania.
• Logi serwera: transfer danych i zapytania do bazy.

Liczba bez źródła nie przetrwa pierwszego pytania technicznego klienta. Jeśli nie możesz jej udowodnić, nie publikuj jej. Jeśli case study dotyczy przyspieszenia strony WordPress, podaj też narzędzie i warunki pomiaru, bo wynik z PageSpeed Insights na telefonie i na komputerze to dwie różne liczby.

#Przykład case study z wymyślonym klientem

Projekt: sklep internetowy producenta mebli. Liczby w tym przykładzie są wymyślone, żeby pokazać format, i nie pochodzą z prawdziwego projektu.

Wyzwanie. Klient miał sklep na WooCommerce z 8000 produktów. Strona ładowała się 6 sekund, co miało trzy skutki:

• 45% porzuceń koszyka,
• spadek konwersji z 3,2% do 1,8% w ciągu roku,
• problemy z indeksowaniem i Core Web Vitals na czerwono.

Rozwiązanie.

1. Migracja do headless WordPress: WordPress jako CMS, Next.js jako frontend.
2. Optymalizacja obrazów: AVIF, leniwe ładowanie i obrazy responsywne.
3. Strategia cache: Redis dla produktów, Cloudflare dla zasobów statycznych.
4. Optymalizacja bazy danych: indeksy i zapytania WP_Query.
5. CDN z automatyczną minifikacją CSS i JS.

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

Wynik (ilustracyjny):

• Czas ładowania: z 6 s do 0,8 s.
• Konwersja: z 1,8% do 3,9%.
• Porzucenia koszyka: z 45% do 12%.
• Core Web Vitals: wszystko na zielono.

Dobre case study podaje też, jak długo trwał projekt i kto brał w nim udział, bo to daje klientowi wyobrażenie o skali. Jeśli pracowałeś sam, napisz to. Jeśli z projektantem i drugim programistą, wymień ich według ról.

#Referencje i wideo w portfolio freelancera

Klient powierza ci swój biznes, więc oprócz kodu ocenia, czy może ci zaufać.

#Jak zebrać referencje od klientów

Nie chowaj opinii na osobnej podstronie. Umieść cytat klienta, za jego zgodą i z jego nazwiskiem albo nazwą firmy, bezpośrednio przy case study, którego dotyczy.

1. Proś w momencie sukcesu, na przykład tydzień po wdrożeniu, gdy wszystko działa.
2. Pomóż napisać: wyślij klientowi trzy pytania, “Co było problemem?”, “Jak wyglądała współpraca?”, “Jaki jest efekt?”, i pozwól mu odpowiedzieć własnymi słowami.
3. Nagranie zamiast tekstu: krótka wypowiedź nagrana telefonem pokazuje prawdziwą osobę, a nie anonimowy akapit.

#Jakie wideo nagrać do portfolio

Krótkie nagranie “o mnie” albo omówienie projektu (Loom, YouTube) pokazuje rzeczy, których tekst nie przekaże:

• twoją twarz,
• sposób komunikacji, czyli czy mówisz konkretnie i zrozumiale,
• demo panelu administracyjnego, który przygotowałeś dla klienta.

#Jaki kod pokazać na GitHubie

Jeśli szukasz pracy w software housie, portfolio musi pokazywać jakość kodu.

#Jak opublikować kod z prywatnych projektów

Nawet jeśli projekt jest prywatny, możesz przygotować publiczne próbki:

1. Fragmenty z projektów: wyciągnij najlepsze kawałki i usuń z nich wszystkie dane klienta.
2. Wkład w open source: do WordPress Core albo do wtyczek.
3. Projekty własne: małe narzędzia, które pokazują twoje umiejętności.

Zanim opublikujesz fragment, sprawdź, czy nie zawiera kluczy, ścieżek wewnętrznych ani nazwy klienta.

#Własne hooki WordPress w próbce kodu

Ten przykład ogranicza i filtruje główne zapytanie sklepu:

/**
 * Ograniczenie i filtrowanie zapytania katalogu WooCommerce
 *
 * @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' => '=',
            ],
        ]);
    }
});

Pokazuje, że znasz hooki WordPressa, myślisz o wydajności zapytania i dokumentujesz kod. Szczegół, który się liczy: nie dodawaj no_found_rows na liście ze stronicowaniem, bo psuje to wyliczanie liczby stron.

#Nowoczesny PHP (8.1 lub nowszy)

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;
    }
}

Widać tu typowane właściwości, promocję właściwości w konstruktorze, wstrzykiwanie zależności i wzorzec cache. Zapisuj w cache tylko potrzebne dane, nie całe obiekty WooCommerce.

#Tworzenie bloków Gutenberga

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

registerBlockType('moj-prefiks/portfolio-item', {
    edit: ({ attributes }) => {
        const blockProps = useBlockProps();
        return (
            <div {...blockProps}>
                <h3>{attributes.title}</h3>
                <p>{attributes.description}</p>
            </div>
        );
    },
    save: () => null, // Renderowanie po stronie serwera
});

Pokazuje znajomość API bloków, Reacta w WordPressie i renderowania po stronie serwera. Więcej o tym, jak je porządnie zorganizować, znajdziesz w przewodniku po blokach Gutenberga, wzorcach i Full Site Editing.

#Jaki stack warto pokazać

Podstawa w 2026:

• Gutenberg (FSE): Full Site Editing i tworzenie bloków.
• React i Next.js: headless WordPress.
• Composer: zarządzanie zależnościami.
• WP-CLI: automatyzacja i wdrożenia.
• Docker: środowisko lokalne, opisane w poradniku o programowaniu WordPressa w Dockerze.
• Git: kontrola wersji, w tym strategia gałęzi, a nie same push i pull.

Dodatkowe punkty: TypeScript, GraphQL, testy (PHPUnit, Jest, Cypress) i CI/CD w GitHub Actions albo GitLab CI.

#Czego nie pokazywać w portfolio programisty

1. Projektów na gotowych motywach z ThemeForest, chyba że mocno je przerobiłeś. Wtedy pokaż, co zmieniłeś.
2. Kodu bez komentarzy, nawet jeśli wydaje ci się oczywisty.
3. Przestarzałych praktyk, takich jak bezpośrednie zapytania SQL zamiast WP_Query.
4. Wartości wpisanych na sztywno: pokaż, że używasz stałych, filtrów i opcji.

#Jak zrobić portfolio w WordPressie z ACF

Nie potrzebujesz rozbudowanych wtyczek: WordPress ma wszystko, czego trzeba.

#Jak zarejestrować własny typ wpisu dla portfolio

function moj_motyw_rejestruj_portfolio_cpt() {
    register_post_type('portfolio', [
        'labels' => [
            'name' => 'Portfolio',
            'singular_name' => 'Projekt',
        ],
        'public' => true,
        'has_archive' => true,
        'supports' => ['title', 'editor', 'thumbnail', 'excerpt'],
        'rewrite' => ['slug' => 'portfolio'],
        'show_in_rest' => true,
    ]);
}
add_action('init', 'moj_motyw_rejestruj_portfolio_cpt');

#Pola ACF dla projektów w portfolio

Advanced Custom Fields (ACF) pozwala nadać każdemu projektowi tę samą strukturę danych.

acf_add_local_field_group([
    'key' => 'portfolio_fields',
    'title' => 'Szczegóły projektu',
    'fields' => [
        ['key' => 'client_name', 'name' => 'client_name', 'label' => 'Nazwa klienta', 'type' => 'text'],
        ['key' => 'project_year', 'name' => 'project_year', 'label' => 'Rok realizacji', 'type' => 'number'],
        [
            'key' => 'tech_stack',
            'name' => 'tech_stack',
            'label' => 'Stack technologiczny',
            'type' => 'checkbox',
            'choices' => [
                'wordpress' => 'WordPress',
                'react' => 'React',
                'nextjs' => 'Next.js',
                'woocommerce' => 'WooCommerce',
            ],
        ],
        [
            'key' => 'metrics',
            'name' => 'metrics',
            'label' => 'Metryki (przed i po)',
            'type' => 'repeater',
            'sub_fields' => [
                ['key' => 'metric_name', 'name' => 'metric_name', 'label' => 'Metryka', 'type' => 'text'],
                ['key' => 'before_value', 'name' => 'before_value', 'label' => 'Przed', 'type' => 'text'],
                ['key' => 'after_value', 'name' => 'after_value', 'label' => 'Po', 'type' => 'text'],
            ],
        ],
    ],
    'location' => [[[
        'param' => 'post_type',
        'operator' => '==',
        'value' => 'portfolio',
    ]]],
]);

Dzięki temu każdy projekt ma te same pola, a porównanie przed i po wygląda tak samo we wszystkich case study. Dane, których nie chcesz widzieć na ekranie edycji, na przykład notatki wewnętrzne albo źródło każdej metryki, zapisz w polach meta z prefiksem podkreślenia (_zrodlo_metryk): WordPress ukrywa je w panelu pól własnych.

#Blok Gutenberga z metrykami case study

Zamiast shortcode’u możesz wyświetlić metryki własnym blokiem renderowanym po stronie serwera:

// Blok: metryki portfolio (render callback)
register_block_type('moj-prefiks/portfolio-metrics', [
    'render_callback' => function ($attributes) {
        $metrics = get_field('metrics');
        if (!$metrics) {
            return '';
        }

        ob_start();
        ?>
        <div class="portfolio-metrics-grid">
            <?php foreach ($metrics as $metric) : ?>
                <div class="metric-card">
                    <h4 class="metric-name"><?php echo esc_html($metric['metric_name']); ?></h4>
                    <p class="metric-values">
                        <?php echo esc_html($metric['before_value']); ?> do
                        <?php echo esc_html($metric['after_value']); ?>
                    </p>
                </div>
            <?php endforeach; ?>
        </div>
        <?php
        return ob_get_clean();
    },
]);

#Szablon single-portfolio.php dla każdego projektu

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

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

    <section class="solution">
        <h2>Rozwiązanie</h2>
        <?php the_content(); ?>
    </section>

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

<?php get_footer();

Zawsze escapuj przez esc_html(): portfolio to twój kod i będzie oceniane jak twój kod.

#Jak wypozycjonować portfolio w Google

Portfolio czytają ludzie i Google.

#Znaczniki schema.org JSON-LD dla portfolio

function moj_motyw_portfolio_schema() {
    $schema = [
        '@context' => 'https://schema.org',
        '@type' => 'CreativeWork',
        'name' => get_the_title(),
        'description' => get_the_excerpt(),
        'creator' => [
            '@type' => 'Person',
            'name' => 'Twoje imię i nazwisko',
        ],
        'datePublished' => get_the_date('c'),
        'url' => get_permalink(),
    ];

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

    return $schema;
}

Nazwa klienta trafia do znaczników tylko wtedy, gdy pole ma wartość, więc klient, który woli pozostać anonimowy, nie pojawi się ani na stronie, ani w danych strukturalnych.

#Jak zoptymalizować obrazy w portfolio

1. Leniwe ładowanie (lazy loading): z wyjątkiem pierwszego widocznego obrazu.
2. Nowoczesne formaty: WebP albo AVIF; proces opisuje poradnik o optymalizacji obrazów w WordPressie.
3. Obrazy responsywne: różne rozmiary zależnie od urządzenia.
4. Opisowy tekst alternatywny: “panel metryk przed i po migracji”, a nie “portfolio-obraz-1”.

#Co łączy najlepsze portfolia programistów

1. Konkretne metryki: nie “poprawiłem wydajność”, tylko “czas ładowania spadł z 5 s do 0,8 s”, razem ze źródłem.
2. Sposób myślenia: jak doszło się do rozwiązania i co odrzucono.
3. Kod w kontekście: nie sam link do GitHuba, ale wyjaśnienie decyzji.
4. Materiał wizualny: diagramy architektury i zrzuty ekranu przed i po.
5. Opinie klientów: jedno zdanie podpisane przez klienta, za jego zgodą, waży więcej niż każdy przymiotnik, który napiszesz o sobie.

#Jak pokazać w portfolio projekty prywatne albo objęte NDA

Wielu najlepszych projektów nie da się pokazać wprost: kod należy do klienta albo umowa zabrania podawania jego nazwy. Case study nadal jest możliwe.

• Nazwa klienta: pole w ACF jest opcjonalne, a znacznik CreativeWork dodaje organizację tylko wtedy, gdy pole ma wartość. Opisz branżę, na przykład “producent mebli”, i zostaw nazwę pustą.
• Kod: wyciągnij fragmenty do publicznego repozytorium. Hook optymalizujący WP_Query albo klasa cache w PHP 8.1 pokazują twój warsztat bez ujawniania projektu.
• Metryki: jeśli nie zapisałeś ich w trakcie pracy, odtwórz je z Google Analytics, PageSpeed Insights, GTmetrix albo logów. Jeśli nie ma wiarygodnej liczby, opisz wyzwanie i decyzję techniczną i nie publikuj wartości, której nie obronisz przed klientem.
• Zgoda: zapytaj, co możesz opublikować, zanim napiszesz case study, a nie po fakcie.
• Własne archiwum: trzymaj liczby przed i po, zrzuty ekranu i opinię klienta z każdego projektu u siebie, żeby móc je pokazać, gdy ktoś je zakwestionuje.

Case study bez logo, z dobrze opisanym problemem, rozwiązaniem i uzasadnieniem, nadal odpowiada na pytanie, które się liczy: dlaczego klient ma wybrać właśnie ciebie.

#Profil WordPress.org jako publiczny dowód wkładu w projekt

Case study piszesz sam. Profil na WordPress.org (profiles.wordpress.org) generuje sama platforma, dlatego klient z technicznym zapleczem czyta go jak niezależny zapis. Podlinkuj go w portfolio obok profilu na GitHubie.

Najwięcej znaczą na tym profilu odznaki. Podręcznik zespołu Meta rozróżnia dwa rodzaje: odznaki współtwórcy (contributor), przyznawane ogólnie każdemu, kto coś wniósł do pracy zespołu, i odznaki zespołu, które dostają osoby w nim aktywne. Każdy zespół ustala własne kryteria, a kilka odznak przyznawanych jest automatycznie:

Pozostałe odznaki zespoły przyznają ręcznie. Kryteria są różne: podręcznik zespołu Openverse wymaga na przykład spełnienia co najmniej jednego z kilku warunków, wśród nich zgłoszenia pięciu lub więcej poprawnych issues, zmergowania znaczącego pull requesta albo przetłumaczenia 25 ciągów znaków. Odznaka Plugin Developer nie mówi, czy wtyczka jest dobra, ale mówi, że przeszła cudzą recenzję, a to więcej, niż udowodni zrzut ekranu.

#Czym jest Five for the Future i jak liczy się w portfolio

Five for the Future zaczął się od wpisu Matta Mullenwega z 30 września 2014 roku. Zdanie, od którego program wziął nazwę, mówi, że organizacje, które chcą powiększać cały tort WordPressa, a nie tylko swój kawałek, “powinny przeznaczyć 5% swoich ludzi na pracę nad czymś związanym z core”, czy to programowanie, dokumentację, bezpieczeństwo, fora wsparcia, recenzje motywów, szkolenia, testy czy tłumaczenia (Matt Mullenweg, wpis o Five for the Future, tłumaczenie własne).

Dziś program ma swoją stronę pod adresem wordpress.org/five-for-the-future. Zobowiązanie mogą złożyć zarówno organizacje, jak i osoby: organizacje widnieją na stronie zobowiązań (pledges), a indywidualni współtwórcy są pokazani z imieniem i nazwiskiem, zdjęciem, krótkim biogramem i organizacją, która ich sponsoruje, jeśli taka jest. Dla freelancera zobowiązanie do określonej liczby godzin tygodniowo w konkretnym zespole (Core, Polyglots, Training, Documentation) to sprawdzalna pozycja w portfolio. Dla agencji obecność na liście organizacji jest sposobem na pokazanie, że wspiera projekt, z którego żyje.

#Jak opublikować wtyczkę w katalogu WordPress.org

Wtyczka zatwierdzona w katalogu to próbka kodu zrecenzowana przez kogoś innego i używana przez prawdziwych użytkowników. Podręcznik wtyczek opisuje proces:

1. Rejestrujesz się na WordPress.org z adresem e-mail, który sprawdzasz; jeśli zgłaszasz wtyczkę w imieniu firmy, użyj oficjalnego adresu firmowego.
2. Wysyłasz krótki opis i kompletne archiwum zip wtyczki, to samo, które zainstalowałbyś ręcznie z panelu.
3. Czekasz na recenzję: zespół sprawdza kod w ciągu 14 dni roboczych, a jeśli znajdzie problemy, kontaktuje się z tobą.
4. Po zatwierdzeniu dostajesz dostęp do repozytorium Subversion; wtyczka pojawia się w katalogu, gdy wgrasz kod i plik readme przez SVN.

Dla portfolio ważne są dwa szczegóły. Adresu URL wtyczki nie da się zmienić po zgłoszeniu, choć wyświetlaną nazwę już tak. Każda wtyczka w katalogu ma też własne forum wsparcia, więc twoje odpowiedzi dla użytkowników są publiczne i stają się częścią tego, co klient może o tobie przeczytać.

Szczegółowych wytycznych katalogu jest 18. Najwięcej odrzuceń wyjaśniają te: licencja GPL lub z nią zgodna (wytyczna 1), kod w większości czytelny dla człowieka (4), żadnych funkcji blokowanych do czasu zapłaty (5), żadnego łączenia się z zewnętrznymi serwerami bez wyraźnej zgody (7) i żadnych cudzych znaków towarowych jako pierwszego członu sluga (17). Jeśli twoja wtyczka je spełnia, masz już argument techniczny do case study.

#Profil na GitHubie: README profilu i przypięte repozytoria

Dokumentacja GitHuba podaje cztery warunki, żeby README pojawiło się na twoim profilu: repozytorium o tej samej nazwie co twój login, publiczne, z plikiem README.md w katalogu głównym i z jakąkolwiek treścią. Potraktuj je jak spis treści: czym się zajmujesz, link do portfolio, link do profilu na WordPress.org i dwa lub trzy repozytoria, które najlepiej cię reprezentują.

Na profilu możesz też przypiąć łącznie do sześciu repozytoriów i gistów. Przypnij te, które odpowiadają twoim case study, na przykład wtyczkę z katalogu, repozytorium zanonimizowanych fragmentów od klientów albo motyw blokowy, a nie forki bez zmian.

#Learn WordPress do uzupełnienia braków w stacku

Jeśli przy przygotowaniu portfolio zauważysz, że brakuje ci czegoś z listy stacku, Learn WordPress dzieli swoje materiały na trzy ścieżki (używanie, programowanie i projektowanie w WordPressie), z kursami, lekcjami i warsztatami na żywo. W październiku 2026 kurs Beginner WordPress Developer ma 9 godzin i 59 lekcji, a Intermediate Theme Developer 8 godzin i 32 lekcje. Ukończony kurs nie zastąpi case study; do portfolio trafia blok albo motyw, który zbudujesz z tą wiedzą.

#Od czego zacząć budowę portfolio

1. Wybierz od 5 do 7 projektów z wynikiem, który da się zmierzyć.
2. Zbierz dane: metryki ze źródłem, zrzuty ekranu i, jeśli klient się zgodzi, jedno jego zdanie.
3. Napisz pierwsze case study w układzie wyzwanie, rozwiązanie, wynik. Licz około dwóch godzin.
4. Przygotuj próbki kodu na GitHubie, bez danych klienta i w PHP 8.1 lub nowszym.
5. Zbuduj CPT z ACF i publikuj case study w jednym formacie.
6. Przeglądaj kod na GitHubie przy każdym nowym projekcie: repozytorium ze starą składnią osłabia case study, które do niego linkuje.

Portfolio to nie CV: każdy projekt ma odpowiadać na pytanie, dlaczego klient ma wybrać ciebie. Jako wzór opublikowanego case study w tym układzie zobacz case study optymalizacji sklepu WooCommerce.