Wie man ein WordPress-Entwickler-Portfolio im Jahr 2026 aufbaut

#Warum das Portfolio eines WordPress-Entwicklers zählt

Für einen WordPress-Entwickler ist das Portfolio der Beweis, dass Sie können, was Sie behaupten, und der Weg zu zeigen, wie Sie denken. Das leistet kein Lebenslauf. Das Angebot an WordPress-Freelancern ist groß, deshalb unterscheidet Sie die Qualität dessen, was Sie zeigen, nicht die Zahl der Projekte.

#Was Kunden von einem WordPress-Freelancer erwarten

• Lösungen, keine Technologien: Wer Sie beauftragt, interessiert sich nicht dafür, dass Sie React verwenden, sondern dafür, dass Sie seine Art von Problem schon gelöst haben.
• Metriken und Ergebnisse: konkrete Zahlen mit Quelle, keine vagen Sätze wie “Ich habe die Performance verbessert”.
• Denkprozess: wie Sie zur Lösung gekommen sind und welche Alternativen Sie verworfen haben.

#Wie man eine Case Study für das Portfolio schreibt

Statt eines Screenshots und eines Links beschreiben Sie den Prozess. Ein gutes Portfolio ist eine Sammlung von Case Studies, und jede beantwortet drei Fragen.

#Herausforderung: das Problem des Kunden

Schreiben Sie nicht “Ich habe eine Website gebaut”. Beschreiben Sie das konkrete Problem. Die folgenden Beispiele dienen der Veranschaulichung und stammen nicht aus echten Projekten:

• “Ein Shop mit 10.000 Produkten brauchte 8 Sekunden zum Laden und verlor unterwegs Warenkörbe.”
• “Die Website verbrauchte durch nicht optimierte Bilder monatlich eine enorme Bandbreite.”
• “Der Kunde verlor mobile Conversions, weil die Website nicht responsiv war.”

Warum das funktioniert: Wer liest, erkennt sich im Problem wieder. Hat er ein ähnliches, weiß er sofort, dass Sie seine Lage verstehen.

#Lösung: was Sie getan haben und warum

Erzählen Sie nicht nur, was Sie getan haben, sondern auch, warum Sie diese Lösung gewählt haben und keine andere:

“Statt Standard-WooCommerce habe ich Headless WordPress mit Next.js gewählt, weil der Kunde Folgendes brauchte:

• eine Ladezeit unter 1 s (Core Web Vitals),
• eine Anbindung an die externe API seines ERP-Systems,
• Skalierbarkeit auf 100.000 Produkte.

Lösung: WordPress als Headless-CMS, Frontend in Next.js, Redis-Cache und Cloudflare-CDN.”

So sieht man, dass Sie keine Templates kopieren, sondern mit technischem Urteil entscheiden. Ergänzen Sie auch, was Sie nicht gewählt haben und warum: Ein Satz wie “Ich habe auf ein Cache-Plugin verzichtet, weil sich der Katalog stündlich änderte” sagt mehr als die Liste der Werkzeuge.

#Ergebnis: Zahlen mit Quelle

Das ist der wichtigste Teil. Zeigen Sie den Zustand vorher und nachher, und nennen Sie, woher jede Zahl stammt:

• Google Analytics: Conversions, Absprungrate, Warenkorbabbrüche.
• PageSpeed Insights (Core Web Vitals): LCP, INP, CLS.
• GTmetrix: Ladezeit.
• Server-Logs: Datenübertragung und Datenbankabfragen.

Eine Zahl ohne Quelle übersteht die erste Frage eines technischen Kunden nicht. Wenn Sie sie nicht belegen können, veröffentlichen Sie sie nicht.

#Beispiel einer Case Study mit erfundenem Kunden

Projekt: Onlineshop eines Möbelherstellers. Die Zahlen in diesem Beispiel sind erfunden, um das Format zu veranschaulichen, und gehören zu keinem echten Projekt.

Herausforderung. Der Kunde betrieb einen WooCommerce-Shop mit 8.000 Produkten. Die Website lud in 6 Sekunden, mit drei Folgen:

• 45 % Warenkorbabbrüche,
• ein Rückgang der Conversion von 3,2 % auf 1,8 % innerhalb eines Jahres,
• Probleme bei der Indexierung und rote Core Web Vitals.

Lösung.

1. Migration zu Headless WordPress: WordPress als CMS und Next.js als Frontend.
2. Bildoptimierung: AVIF, Lazy Loading und responsive Bilder.
3. Cache-Strategie: Redis für Produkte und Cloudflare für statische Ressourcen.
4. Datenbankoptimierung: Indizes und WP_Query-Abfragen.
5. CDN mit automatischer Minifizierung von CSS und JS.

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

Ergebnis (zur Veranschaulichung):

• Ladezeit: von 6 s auf 0,8 s.
• Conversion: von 1,8 % auf 3,9 %.
• Warenkorbabbrüche: von 45 % auf 12 %.
• Core Web Vitals: alles grün.

Eine gute Case Study nennt auch, wie lange das Projekt gedauert hat und wer beteiligt war, denn das gibt dem Kunden ein Gefühl für die Größenordnung. Haben Sie allein gearbeitet, sagen Sie es; haben Sie mit Design und einem weiteren Entwickler gearbeitet, nennen Sie diese nach ihrer Rolle.

#Welchen Code man auf GitHub zeigen sollte

Wenn Sie eine Stelle in einem Softwareunternehmen suchen, muss das Portfolio Codequalität zeigen.

#Wie man Code aus privaten Projekten veröffentlicht

Auch wenn das Projekt privat ist, können Sie öffentliche Beispiele erstellen:

1. Fragmente aus Projekten: Ziehen Sie die besten Stücke heraus und entfernen Sie alle Kundendaten.
2. Open-Source-Beiträge: zu WordPress Core oder zu Plugins.
3. Eigene Projekte: kleine Werkzeuge, die Ihre Fähigkeiten zeigen.

Prüfen Sie vor der Veröffentlichung eines Fragments, dass es keine Schlüssel, internen Pfade oder Kundennamen enthält.

#Eigene WordPress-Hooks

Dieses Beispiel begrenzt und filtert die Hauptabfrage eines Shops:

/**
 * Abfrage des WooCommerce-Katalogs begrenzen und filtern
 *
 * @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' => '=',
            ],
        ]);
    }
});

Das zeigt, dass Sie WordPress-Hooks kennen, an die Performance der Abfrage denken und Ihren Code dokumentieren. Ein Detail, das zählt: Setzen Sie no_found_rows nicht in einer Liste mit Paginierung, weil es die Seitenberechnung zerstört.

#Modernes PHP (8.1 oder neuer)

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

Hier sieht man typisierte Eigenschaften, Constructor Property Promotion, Dependency Injection und ein Cache-Muster. Cachen Sie nur die Daten, die Sie brauchen, keine vollständigen WooCommerce-Objekte.

#Entwicklung von Gutenberg-Blöcken

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

registerBlockType('mein-praefix/portfolio-item', {
    edit: ({ attributes }) => {
        const blockProps = useBlockProps();
        return (
            <div {...blockProps}>
                <h3>{attributes.title}</h3>
                <p>{attributes.description}</p>
            </div>
        );
    },
    save: () => null, // Serverseitiges Rendering
});

Das zeigt Kenntnis der Block-API, React innerhalb von WordPress und serverseitiges Rendering. Wer tiefer einsteigen will, findet im Leitfaden zu Gutenberg-Blöcken, Mustern und Full Site Editing die Details zur Struktur.

#Welchen Stack es sich zu zeigen lohnt

Unverzichtbar im Jahr 2026:

• Gutenberg (FSE): Full Site Editing und Block-Entwicklung.
• React und Next.js: Headless WordPress.
• Composer: Verwaltung von Abhängigkeiten.
• WP-CLI: Automatisierung und Deployment.
• Docker: lokale Umgebung; dazu gibt es einen Leitfaden zur WordPress-Entwicklung mit Docker.
• Git: Versionskontrolle, und zwar nicht nur push und pull, sondern eine Branching-Strategie.

Pluspunkte: TypeScript, GraphQL, Tests (PHPUnit, Jest, Cypress) und CI/CD mit GitHub Actions oder GitLab CI.

#Was nicht in ein Entwickler-Portfolio gehört

1. Projekte auf fertigen ThemeForest-Themes, es sei denn, Sie haben sie gründlich angepasst. Dann zeigen Sie, was Sie geändert haben.
2. Code ohne Kommentare, auch wenn er Ihnen offensichtlich erscheint.
3. Veraltete Praktiken, etwa direkte SQL-Abfragen statt WP_Query.
4. Fest eingetragene Werte im Code: Zeigen Sie, dass Sie Konstanten, Filter und Optionen verwenden.

#Wie man das Portfolio in WordPress mit ACF aufbaut

Sie brauchen keine komplexen Plugins: WordPress bringt das Nötige mit.

#Wie man einen Custom Post Type für das Portfolio registriert

function mein_theme_portfolio_cpt_registrieren() {
    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', 'mein_theme_portfolio_cpt_registrieren');

#ACF-Felder für Portfolio-Projekte

acf_add_local_field_group([
    'key' => 'portfolio_fields',
    'title' => 'Portfolio-Details',
    'fields' => [
        ['key' => 'client_name', 'name' => 'client_name', 'label' => 'Kundenname', 'type' => 'text'],
        ['key' => 'project_year', 'name' => 'project_year', 'label' => 'Projektjahr', 'type' => 'number'],
        [
            'key' => 'tech_stack',
            'name' => 'tech_stack',
            'label' => 'Tech Stack',
            'type' => 'checkbox',
            'choices' => [
                'wordpress' => 'WordPress',
                'react' => 'React',
                'nextjs' => 'Next.js',
                'woocommerce' => 'WooCommerce',
            ],
        ],
        [
            'key' => 'metrics',
            'name' => 'metrics',
            'label' => 'Metriken (vorher und nachher)',
            'type' => 'repeater',
            'sub_fields' => [
                ['key' => 'metric_name', 'name' => 'metric_name', 'label' => 'Metrik', 'type' => 'text'],
                ['key' => 'before_value', 'name' => 'before_value', 'label' => 'Vorher', 'type' => 'text'],
                ['key' => 'after_value', 'name' => 'after_value', 'label' => 'Nachher', 'type' => 'text'],
            ],
        ],
    ],
    'location' => [[[
        'param' => 'post_type',
        'operator' => '==',
        'value' => 'portfolio',
    ]]],
]);

Damit hat jedes Projekt dieselben Felder, und Sie können den Vorher-Nachher-Vergleich in allen Case Studies mit derselben Struktur zeigen. Daten, die nicht im Bearbeitungsbildschirm erscheinen sollen, etwa interne Notizen oder die Quelle jeder Metrik, speichern Sie in Metafeldern mit Unterstrich-Präfix (_metrik_quelle): WordPress blendet sie im Bereich für benutzerdefinierte Felder aus.

#Gutenberg-Block für die Metriken einer Case Study

Statt eines Page Builders können Sie die Metriken in einem eigenen, serverseitig gerenderten Block ausgeben:

// Block: Portfolio-Metriken
register_block_type('mein-praefix/portfolio-metrics', [
    'render_callback' => function ($attributes) {
        $metrics = get_field('metrics');
        if (!$metrics) {
            return '';
        }

        ob_start();
        ?>
        <div class="portfolio-metrics">
            <?php foreach ($metrics as $metric) : ?>
                <div class="metric-item">
                    <span class="metric-name"><?php echo esc_html($metric['metric_name']); ?></span>
                    <span class="metric-before"><?php echo esc_html($metric['before_value']); ?></span>
                    <span class="metric-separator">bis</span>
                    <span class="metric-after"><?php echo esc_html($metric['after_value']); ?></span>
                </div>
            <?php endforeach; ?>
        </div>
        <?php
        return ob_get_clean();
    },
]);

So lässt sich der Block in jede Case Study einsetzen, und das Markup der Metriken bleibt überall gleich.

#Template single-portfolio.php für jedes Projekt

// 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; ?>
            Jahr: <?php echo esc_html(get_field('project_year')); ?>
        </p>
    </header>

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

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

<?php get_footer();

Escapen Sie immer mit esc_html(): Das Portfolio ist Ihr eigener Code und wird auch so beurteilt.

#Wie man das Portfolio bei Google positioniert

Das Portfolio ist nicht nur für Menschen da: Google liest es ebenfalls.

#Schema.org-Markup in JSON-LD für das Portfolio

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

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

    return $schema;
}

Der Kundenname landet nur dann im Markup, wenn das Feld einen Wert hat. Ein Kunde, der anonym bleiben möchte, erscheint also weder auf der Seite noch in den strukturierten Daten.

#Wie man die Bilder im Portfolio optimiert

1. Lazy Loading: außer beim ersten sichtbaren Bild.
2. Moderne Formate: WebP oder AVIF; der Leitfaden zur Bildoptimierung in WordPress erklärt das Vorgehen.
3. Responsive Bilder: unterschiedliche Größen je nach Gerät.
4. Beschreibender Alt-Text: “Dashboard mit Metriken vor und nach der Migration”, nicht “portfolio-bild-1”.

#Was die besten Entwickler-Portfolios gemeinsam haben

1. Konkrete Metriken: nicht “Ich habe die Performance verbessert”, sondern “Die Ladezeit sank von 5 s auf 0,8 s”, mit Quelle.
2. Denkprozess: wie die Lösung entstanden ist und was verworfen wurde.
3. Code im Kontext: nicht nur ein Link zu GitHub, sondern die Erklärung der Entscheidungen.
4. Visuelles Material: Architekturdiagramme und Screenshots von vorher und nachher.
5. Kundenstimmen: Ein vom Kunden unterzeichneter Satz, mit seiner Erlaubnis, wiegt mehr als jedes Adjektiv, das Sie selbst wählen.

#Wie man private Projekte oder Projekte unter NDA zeigt

Viele der besten Projekte lassen sich nicht einfach so zeigen: Der Code gehört dem Kunden, oder der Vertrag verbietet die Nennung. Eine Case Study ist trotzdem möglich.

• Kundenname: Das ACF-Feld ist optional, und das CreativeWork-Markup fügt die Organisation nur hinzu, wenn es einen Wert hat. Beschreiben Sie die Branche, etwa “Möbelhersteller”, und lassen Sie den Namen leer.
• Code: Ziehen Sie Fragmente in ein öffentliches Repository. Ein Hook, der WP_Query optimiert, oder eine Cache-Klasse mit PHP 8.1 zeigen Urteilsvermögen, ohne das Projekt offenzulegen.
• Metriken: Haben Sie sie während der Arbeit nicht notiert, holen Sie sie aus Google Analytics, PageSpeed Insights, GTmetrix oder den Logs. Gibt es keinen verlässlichen Wert, beschreiben Sie die Herausforderung und die technische Entscheidung und veröffentlichen keine Zahl, die Sie vor dem Kunden nicht verteidigen könnten.
• Erlaubnis: Fragen Sie, was Sie veröffentlichen dürfen, bevor Sie die Case Study schreiben, nicht danach.
• Eigenes Archiv: Bewahren Sie die Vorher-Nachher-Zahlen, die Screenshots und die Kundenstimme jedes Projekts in Ihren Unterlagen auf, damit Sie sie belegen können, wenn jemand nachfragt.

Eine Case Study ohne Logo, in der Problem, Lösung und Begründung gut erklärt sind, beantwortet weiterhin die entscheidende Frage: warum der Kunde gerade Sie wählen sollte.

#Welche Freigaben man vor der Veröffentlichung eines Projekts braucht

Eine Case Study mit Ladezeiten, Conversion-Raten und Warenkorbabbrüchen verrät viel über das Geschäft eines Kunden. Bevor ein Projekt online geht, sollte deshalb geklärt sein, was davon öffentlich werden darf. Darf der Kundenname erscheinen, oder bleibt es bei einer Beschreibung wie “WooCommerce-Shop eines Möbelherstellers”? Dürfen absolute Zahlen genannt werden, oder nur die Veränderung zwischen vorher und nachher? Manche Kunden erlauben Screenshots, aber keine Daten aus Google Analytics. Am einfachsten lassen sich diese Fragen beim Projektabschluss stellen, zusammen mit der Bitte um eine Kundenstimme.

Für Code auf GitHub gilt dieselbe Vorsicht. Öffentliche Repositories sollten eigene Beispiele enthalten, etwa Hooks oder Gutenberg-Blöcke, die für das Portfolio neu geschrieben wurden, und keinen Code, der dem Kunden gehört.

#WordPress.org-Profil als öffentlicher Nachweis von Beiträgen

Eine Case Study schreiben Sie selbst. Das WordPress.org-Profil (profiles.wordpress.org) erzeugt die Plattform, und deshalb liest ein technischer Kunde es als unabhängigen Nachweis. Verlinken Sie es im Portfolio neben dem GitHub-Profil.

Am meisten Gewicht haben in diesem Profil die Abzeichen. Das Handbuch des Meta-Teams unterscheidet zwei Arten: Contributor-Abzeichen, die allgemein an alle vergeben werden, die zu einem Team beigetragen haben, und Team-Abzeichen für diejenigen, die darin aktiv sind. Jedes Team legt eigene Kriterien fest, und einige werden automatisch vergeben:

Die übrigen vergibt jedes Team von Hand. Die Kriterien unterscheiden sich: Das Handbuch des Openverse-Teams verlangt zum Beispiel, mindestens eine von mehreren Bedingungen zu erfüllen, darunter fünf oder mehr gültige Issues zu eröffnen, einen substanziellen Pull Request gemergt zu bekommen oder 25 Strings zu übersetzen. Ein Plugin-Developer-Abzeichen sagt nicht, ob das Plugin gut ist, aber es zeigt, dass es eine fremde Prüfung bestanden hat, und das ist mehr, als ein Screenshot belegt.

#Was Five for the Future ist und wie es im Portfolio zählt

Five for the Future geht auf einen Beitrag von Matt Mullenweg vom 30. September 2014 zurück. Der Satz, der dem Programm den Namen gibt, besagt, dass Organisationen, die den WordPress-Kuchen wachsen lassen wollen und nicht nur ihr eigenes Stück, “5 % ihrer Leute dafür einsetzen sollten, an etwas zu arbeiten, das mit Core zu tun hat”, sei es Entwicklung, Dokumentation, Sicherheit, Support-Foren, Theme-Review, Schulung, Tests oder Übersetzung (Matt Mullenweg: Five for the Future, eigene Übersetzung).

Heute ist das Programm unter wordpress.org/five-for-the-future zu finden. Zusagen können sowohl Organisationen als auch Einzelpersonen geben: Organisationen erscheinen auf der Seite der Zusagen (Pledges), und einzelne Mitwirkende werden mit Namen, Foto, einer kurzen Biografie und gegebenenfalls der Organisation angezeigt, die sie unterstützt. Für einen Freelancer ist eine Zusage von Wochenstunden für ein bestimmtes Team (Core, Polyglots, Training, Documentation) eine überprüfbare Zeile im Portfolio. Für eine Agentur ist der Eintrag in der Liste der Organisationen ein Weg zu zeigen, dass sie zu dem Projekt beiträgt, von dem sie lebt.

#Wie man ein Plugin im WordPress.org-Verzeichnis veröffentlicht

Ein im Verzeichnis freigegebenes Plugin ist ein von Dritten geprüftes Code-Beispiel mit echten Nutzern. Das Plugin-Handbuch beschreibt den Ablauf:

1. Registrieren Sie sich auf WordPress.org mit einer E-Mail-Adresse, die Sie lesen; wenn Sie im Namen eines Unternehmens einreichen, verwenden Sie eine offizielle Firmenadresse.
2. Reichen Sie eine kurze Beschreibung und ein vollständiges Zip des Plugins ein, dasselbe, das Sie von Hand über das Dashboard installieren würden.
3. Warten Sie auf die Prüfung: Das Team prüft den Code innerhalb von 14 Werktagen und meldet sich bei Ihnen, wenn es Probleme findet.
4. Nach der Freigabe erhalten Sie Zugang zu einem Subversion-Repository; das Plugin erscheint im Verzeichnis, sobald Sie Code und Readme per SVN hochladen.

Zwei Details sind für das Portfolio wichtig. Die URL des Plugins lässt sich nach der Einreichung nicht mehr ändern, der angezeigte Name schon. Und jedes Plugin im Verzeichnis hat ein eigenes Support-Forum, Ihre Antworten an Nutzer sind also öffentlich und gehören zu dem, was ein Kunde über Sie lesen kann.

Die ausführlichen Richtlinien des Verzeichnisses umfassen 18 Punkte. Die, die die meisten Ablehnungen erklären: GPL oder eine kompatible Lizenz (Richtlinie 1), überwiegend für Menschen lesbarer Code (4), keine Funktionen, die erst nach Bezahlung freigeschaltet werden (5), keine Verbindungen zu externen Servern ohne ausdrückliche Zustimmung (7) und keine fremden Marken als ersten Begriff im Slug (17). Erfüllt Ihr Plugin sie, haben Sie bereits ein technisches Argument für die Case Study.

#GitHub-Profil: Profil-README und angeheftete Repositories

Die GitHub-Dokumentation nennt vier Bedingungen, damit ein README in Ihrem Profil erscheint: ein Repository mit demselben Namen wie Ihr Benutzername, öffentlich, mit einer Datei README.md im Stammverzeichnis und mit Inhalt. Nutzen Sie es als Inhaltsverzeichnis: was Sie tun, Link zum Portfolio, Link zum WordPress.org-Profil und die zwei oder drei Repositories, die Sie am besten repräsentieren.

Außerdem können Sie insgesamt bis zu sechs Repositories und Gists im Profil anheften. Heften Sie die an, die zu Ihren Case Studies passen, etwa das Plugin aus dem Verzeichnis, das Repository mit anonymisierten Kundenfragmenten oder das Block-Theme, und keine unveränderten Forks.

#Learn WordPress, um Lücken im Stack zu schließen

Wenn Sie bei der Vorbereitung des Portfolios merken, dass Ihnen etwas aus der Stack-Liste fehlt: Learn WordPress gliedert seine Inhalte in drei Lernpfade (WordPress nutzen, entwickeln und gestalten), mit Kursen, Lektionen und Live-Workshops. Im Oktober 2026 ist der Kurs Beginner WordPress Developer mit 9 Stunden und 59 Lektionen angegeben, Intermediate Theme Developer mit 8 Stunden und 32 Lektionen. Ein abgeschlossener Kurs ersetzt keine Case Study; ins Portfolio gehört der Block oder das Theme, das Sie mit dem Gelernten bauen.

#Womit man beim eigenen Portfolio anfängt

1. Wählen Sie 5 bis 7 Projekte mit einem Ergebnis, das Sie messen können.
2. Sammeln Sie die Daten: Metriken mit Quelle, Screenshots und, wenn der Kunde es erlaubt, einen Satz von ihm.
3. Schreiben Sie die erste Case Study mit der Struktur Herausforderung, Lösung und Ergebnis. Rechnen Sie mit etwa zwei Stunden.
4. Bereiten Sie die Code-Beispiele auf GitHub vor, ohne Kundendaten und mit PHP 8.1 oder neuer.
5. Richten Sie den CPT mit ACF ein und veröffentlichen Sie die Case Studies im selben Format.
6. Prüfen Sie den GitHub-Code jedes Mal, wenn Sie ein Projekt hinzufügen: Ein Repository mit veralteter Syntax schwächt die Case Study, die darauf verlinkt.

Das Portfolio ist kein Lebenslauf: Jedes Projekt sollte beantworten, warum man gerade Sie wählen sollte. Als Referenz für eine veröffentlichte Case Study mit dieser Struktur sehen Sie sich die Case Study zur WooCommerce-Optimierung an.